From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id EA90343255 for ; Tue, 31 Oct 2023 18:06:32 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C310440284; Tue, 31 Oct 2023 18:06:32 +0100 (CET) Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) by mails.dpdk.org (Postfix) with ESMTP id 72F06400EF; Tue, 31 Oct 2023 18:06:31 +0100 (CET) Received: by mail-ot1-f50.google.com with SMTP id 46e09a7af769-6d2fedd836fso1273300a34.1; Tue, 31 Oct 2023 10:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698771990; x=1699376790; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=VfSEd6WnR9qpg2WRZq4IcYy3W6tTqSMn1DwQbb7IVx8=; b=SEdxJ0Lm94GUgL8z3vAp71nc74JQlyxWLVF4iUpqRDGKKOgcgLBCCb8DKYQfxVid3l yuyiE9SHrqE6Xyk0yQ8v8sNs5CwGkV3O2r/Dny0s+LKCWHwIBZutUjhGW7GPdyon3yBR shZQreorqx3KulGPayZxzDtte98JbQhCDiLHzftGMTVswwk/syNwIR+/9tR81aiIKVH9 8Uhra5Go7/nr92csEiZRe0aXZEKFsHGUA5zFYvmswFhiOq69rZ9ReaaWFzoiQjsrQMSM h8JQzjeL2ZrPV3VXdGnQiwwRfFE5jRgcXcHKmEKRw5IjzpckUyn/bsPXsJ3gUlfPk5UU opOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698771990; x=1699376790; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VfSEd6WnR9qpg2WRZq4IcYy3W6tTqSMn1DwQbb7IVx8=; b=TFz28AaluXtkFMEAyJBvlGRPnYg2C+y4jQpjhCCDOcx+0979Qy7PJZ1zpaYt5R6JeQ Vpvpax3CF19BQGzk9NU2/PkE9D+xhoogxVtUynjbmUwRFPpEe214qZcg2j5TCOx9ROso dLAeFy1eOu6bMvvNwW/r0CUJuuik3Rvy8gGWZcJTQ9SSlpS+FS7muZ2CDZfSXEBspNnY K378dukl2VWHCLheeKPQKVYFcqPC5Uef2h62N3qxXjCCEdVnwLqrKpIhlmfuY9159d5e PONz9DdbkxbZzAMj7oynZur1rvx1kQ5lE88suhaqbYKqOXt5rWsOOHxVVZ2Fhk15bsxC 94Ww== X-Gm-Message-State: AOJu0Yxrasj8k2gxlsIHtW+L751gOOWvZ3wte3NxF48x56HV+mDTZBqf EkNLVRXWv7b79H31YtohhMWk9MOvezGX9YVD1T8= X-Google-Smtp-Source: AGHT+IEqi2Qr4eS4IaRomEkXw4s77d9Mmy+nbx103cn8jAJobhVre+PhOuAUCP6D7yN+ik4Vak1ZDnqKnJR1mURjqsA= X-Received: by 2002:a9d:4f15:0:b0:6c9:7aca:f436 with SMTP id d21-20020a9d4f15000000b006c97acaf436mr13041543otl.29.1698771990587; Tue, 31 Oct 2023 10:06:30 -0700 (PDT) MIME-Version: 1.0 References: <20230607210050.107944-1-abdullah.sevincer@intel.com> <20231030211244.2516043-1-abdullah.sevincer@intel.com> In-Reply-To: From: Jerin Jacob Date: Tue, 31 Oct 2023 22:36:04 +0530 Message-ID: Subject: Re: [PATCH v3] event/dlb2: fix disable PASID for kernel 6.2 To: "Sevincer, Abdullah" Cc: "dev@dpdk.org" , "jerinj@marvell.com" , "Chen, Mike Ximing" , "Richardson, Bruce" , "stable@dpdk.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Tue, Oct 31, 2023 at 8:43=E2=80=AFPM Sevincer, Abdullah wrote: > > > > +This patch can be splited as two, > > +1) Generic PCIe function to enable/disable PASID > > +2) Call generic function to disable PASID in drivers/event/dlb2/. Also= mention which Linux kernel commit is introducing this issue in the git com= mit log. > > Hi Jerrin, > I think I need to provide more information here, then we can decide which= way we will go would be good for now. I agree to having 2 functions in pci= common > code to enable/disable PASID, but we need to have hardcoded PASID cap off= set inside these functions as well since PASID capability is not exposed to= user. Hence, to be more specific > main reason to have hardcoded PASID is, rte_pci_find_ext_capability() fun= ction to retrieve the offset returns '0' since PASID is not exposed to user= yet. > > We can see this is vfio_pci_config.c in kernel code where PASID is not ex= posed to user. > [PCI_EXT_CAP_ID_PASID] =3D 0, /* not yet */ > > So if it is okay to go with hardcoded offset now in these functions I wil= l move the implementation to pci_common file. I would suggest, add argument option to API whether to probe the capability or not? - 0 means probe and- non zero means specific PASID cap offset till Linux VFIO is exposing it.