> From: Tian, Kevin
> Sent: Tuesday, March 31, 2020 2:39 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [PATCH v1 1/2] vfio/pci: Expose PCIe PASID capability to guest
>
> > From: Liu, Yi L
> > Sent: Sunday, March 22, 2020 8:33 PM
> >
> > From: Liu Yi L
> >
> > This patch expose
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:33 PM
>
> From: Liu Yi L
>
> This patch exposes PCIe PASID capability to guest. Existing vfio_pci
> driver hides it from guest by setting the capability length as 0 in
> pci_ext_cap_length[].
>
> This capability is required for vSVA enabling o
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:33 PM
>
> From: Liu Yi L
>
> Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on
> Intel platforms allows address space sharing between device DMA and
> applications. SVA can reduce programming complexity and enhance security
> From: Jacob Pan
> Sent: Tuesday, March 31, 2020 12:08 AM
>
> On Mon, 30 Mar 2020 05:40:40 +
> "Tian, Kevin" wrote:
>
> > > From: Jacob Pan
> > > Sent: Saturday, March 28, 2020 7:54 AM
> > >
> > > On Fri, 27 Mar 2020 00:47:02 -0700
> > > Christoph Hellwig wrote:
> > >
> > > > On Fri, Mar
> From: Liu, Yi L
> Sent: Monday, March 30, 2020 10:37 PM
>
> > From: Tian, Kevin
> > Sent: Monday, March 30, 2020 4:32 PM
> > To: Liu, Yi L ; alex.william...@redhat.com;
> > Subject: RE: [PATCH v1 1/8] vfio: Add
> VFIO_IOMMU_PASID_REQUEST(alloc/free)
> >
> > > From: Liu, Yi L
> > > Sent: Sunda
On 3/30/20 1:42 PM, Alexander Graf wrote:
>
>
> On 30.03.20 15:40, Konrad Rzeszutek Wilk wrote:
>>
>>
>>
>> On Mon, Mar 30, 2020 at 02:06:01PM +0800, Kairui Song wrote:
>>> On Sat, Mar 28, 2020 at 7:57 PM Dave Young wrote:
On 03/26/20 at 05:29pm, Alexander Graf wrote:
> The swiotl
> From: Jacob Pan
> Sent: Tuesday, March 31, 2020 4:52 AM
>
> On Sat, 28 Mar 2020 08:02:01 +
> "Tian, Kevin" wrote:
>
> > > From: Jacob Pan
> > > Sent: Saturday, March 21, 2020 7:28 AM
> > >
> > > When supporting guest SVA with emulated IOMMU, the guest PASID
> > > table is shadowed in VMM
> From: Jacob Pan
> Sent: Tuesday, March 31, 2020 2:22 AM
>
> On Sun, 29 Mar 2020 16:03:36 +0800
> Lu Baolu wrote:
>
> > On 2020/3/27 20:21, Tian, Kevin wrote:
> > >> From: Jacob Pan
> > >> Sent: Saturday, March 21, 2020 7:28 AM
> > >>
> > >> Nested translation mode is supported in VT-d 3.0 Sp
> From: Auger Eric
> Sent: Monday, March 30, 2020 12:05 AM
>
> On 3/28/20 11:01 AM, Tian, Kevin wrote:
> >> From: Jacob Pan
> >> Sent: Saturday, March 21, 2020 7:28 AM
> >>
> >> When Shared Virtual Address (SVA) is enabled for a guest OS via
> >> vIOMMU, we need to provide invalidation support a
> From: Auger Eric
> Sent: Sunday, March 29, 2020 11:34 PM
>
> Hi,
>
> On 3/28/20 11:01 AM, Tian, Kevin wrote:
> >> From: Jacob Pan
> >> Sent: Saturday, March 21, 2020 7:28 AM
> >>
> >> When Shared Virtual Address (SVA) is enabled for a guest OS via
> >> vIOMMU, we need to provide invalidation
On 03/30/20 at 10:42pm, Alexander Graf wrote:
>
>
> On 30.03.20 15:40, Konrad Rzeszutek Wilk wrote:
> >
> >
> >
> > On Mon, Mar 30, 2020 at 02:06:01PM +0800, Kairui Song wrote:
> > > On Sat, Mar 28, 2020 at 7:57 PM Dave Young wrote:
> > > >
> > > > On 03/26/20 at 05:29pm, Alexander Graf wrot
Hi,
[snip]
> 2) Reuse the SWIOTLB from the previous boot on kexec/kdump
We should only care about kdump
>
> I see little direct relation to SEV here. The only reason SEV makes it more
> relevant, is that you need to have an SWIOTLB region available with SEV
> while without you could live with a
On 03/30/20 at 09:40am, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 30, 2020 at 02:06:01PM +0800, Kairui Song wrote:
> > On Sat, Mar 28, 2020 at 7:57 PM Dave Young wrote:
> > >
> > > On 03/26/20 at 05:29pm, Alexander Graf wrote:
> > > > The swiotlb is a very convenient fallback mechanism for bounce
Hello Konrad,
On Tue, Mar 03, 2020 at 12:03:53PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 04, 2020 at 07:35:00PM +, Ashish Kalra wrote:
> > Hello Konrad,
> >
> > Looking fwd. to your feedback regarding support of other memory
> > encryption architectures such as Power, S390, etc.
> >
On Fri, 27 Mar 2020 15:46:23 +0100
Auger Eric wrote:
> Hi Jacob,
>
> On 3/21/20 12:27 AM, Jacob Pan wrote:
> > When Shared Virtual Memory is exposed to a guest via vIOMMU,
> > scalable IOTLB invalidation may be passed down from outside IOMMU
> > subsystems. This patch adds invalidation functions
PASID cache type and shift of granularity bits are missing in
the current code.
Fixes: 6f7db75e1c46 ("iommu/vt-d: Add second level page table
interface")
Cc: Eric Auger
Signed-off-by: Jacob Pan
---
drivers/iommu/intel-pasid.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
On Sun, 29 Mar 2020 15:40:22 +0200
Auger Eric wrote:
> Hi,
>
> On 3/21/20 12:27 AM, Jacob Pan wrote:
> > When supporting guest SVA with emulated IOMMU, the guest PASID
> > table is shadowed in VMM. Updates to guest vIOMMU PASID table
> > will result in PASID cache flush which will be passed down
On Tue, 17 Mar 2020 20:39:08 +0530, Sibi Sankar wrote:
> Add iommus property to allow Q6 modem to boot on platforms which do
> not have trustZone.
>
> Signed-off-by: Sibi Sankar
> ---
> Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
Acke
On Sat, 28 Mar 2020 08:02:01 +
"Tian, Kevin" wrote:
> > From: Jacob Pan
> > Sent: Saturday, March 21, 2020 7:28 AM
> >
> > When supporting guest SVA with emulated IOMMU, the guest PASID
> > table is shadowed in VMM. Updates to guest vIOMMU PASID table
> > will result in PASID cache flush wh
On 30.03.20 15:40, Konrad Rzeszutek Wilk wrote:
On Mon, Mar 30, 2020 at 02:06:01PM +0800, Kairui Song wrote:
On Sat, Mar 28, 2020 at 7:57 PM Dave Young wrote:
On 03/26/20 at 05:29pm, Alexander Graf wrote:
The swiotlb is a very convenient fallback mechanism for bounce buffering of
DMAab
The PASID state has to be cleared on forks, since the child has a
different address space. The PASID is also cleared for thread clone. While
it would be correct to inherit the PASID in this case, it is unknown
whether the new task will use ENQCMD. Giving it the PASID "just in case"
would have the d
The IA32_PASID MSR (0xd93) contains the Process Address Space Identifier
(PASID), a 20-bit value. Bit 31 must be set to indicate the value
programmed in the MSR is valid. Hardware uses PASID to identify which
process submits the work and direct responses to the right process.
Signed-off-by: Fenghu
Typical hardware devices require a driver stack to translate application
buffers to hardware addresses, and a kernel-user transition to notify the
hardware of new work. What if both the translation and transition overhead
could be eliminated? This is what Shared Virtual Address (SVA) and ENQCMD
ena
From: Yu-cheng Yu
The IA32_PASID MSR is used when a task submits work via the ENQCMD
instruction. The per task MSR is stored in the task's supervisor FPU
PASID state and is context switched by XSAVES/XRSTORS.
Signed-off-by: Yu-cheng Yu
Co-developed-by: Fenghua Yu
Signed-off-by: Fenghua Yu
Rev
PASID is shared by all threads in a process. So the logical place to keep
track of it is in the "mm". Add the field to the architecture specific
mm_context_t structure.
A PASID is allocated for an "mm" the first time any thread attaches
to an SVM capable device. Later device atatches (whether to t
A #GP fault is generated when ENQCMD instruction is executed without
a valid PASID value programmed in. The #GP fault handler will initialize
the current thread's PASID MSR.
The following heuristic is used to avoid decoding the user instructions
to determine the precise reason for the #GP fault:
1
A user space application can execute ENQCMD instruction to submit work
to device. The kernel executes ENQCMDS instruction to submit work to
device.
There is a lot of other enabling needed for the instructions to actually
be usable in user space and the kernel, and that enabling is coming later
in
From: Ashok Raj
ENQCMD and Data Streaming Accelerator (DSA) and all of their associated
features are a complicated stack with lots of interconnected pieces.
This documentation provides a big picture overview for all of the
features.
Signed-off-by: Ashok Raj
Co-developed-by: Fenghua Yu
Signed-o
Hi,
On Sat, Mar 28, 2020 at 12:35 AM Sai Prakash Ranjan
wrote:
>
> > Of course the fact that in practice we'll *always* see the warning
> > because there's no way to tear down the default DMA domains, and even
> > if all devices *have* been nicely quiesced there's no way to tell, is
> > certainly
On Sun, 29 Mar 2020 16:03:36 +0800
Lu Baolu wrote:
> On 2020/3/27 20:21, Tian, Kevin wrote:
> >> From: Jacob Pan
> >> Sent: Saturday, March 21, 2020 7:28 AM
> >>
> >> Nested translation mode is supported in VT-d 3.0 Spec.CH 3.8.
> >
> > now the spec is already at rev3.1 😊
>
> Updated.
>
>
On Sun, 29 Mar 2020 15:20:55 +0800
Lu Baolu wrote:
> On 2020/3/27 19:53, Tian, Kevin wrote:
> >> From: Jacob Pan
> >> Sent: Saturday, March 21, 2020 7:28 AM
> >>
> >> Signed-off-by: Jacob Pan
> >
> > could you elaborate in which scenario this helper function is
> > required?
>
> I added b
On Mon, 30 Mar 2020 05:40:40 +
"Tian, Kevin" wrote:
> > From: Jacob Pan
> > Sent: Saturday, March 28, 2020 7:54 AM
> >
> > On Fri, 27 Mar 2020 00:47:02 -0700
> > Christoph Hellwig wrote:
> >
> > > On Fri, Mar 27, 2020 at 02:49:55AM +, Tian, Kevin wrote:
> > > > If those API calls
> From: Tian, Kevin
> Sent: Monday, March 30, 2020 4:32 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [PATCH v1 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)
>
> > From: Liu, Yi L
> > Sent: Sunday, March 22, 2020 8:32 PM
> >
> > From: Liu Yi L
> >
> > For a long time, de
On Mon, Mar 30, 2020 at 02:06:01PM +0800, Kairui Song wrote:
> On Sat, Mar 28, 2020 at 7:57 PM Dave Young wrote:
> >
> > On 03/26/20 at 05:29pm, Alexander Graf wrote:
> > > The swiotlb is a very convenient fallback mechanism for bounce buffering
> > > of
> > > DMAable data. It is usually used for
On Thu, Mar 26, 2020 at 06:11:31PM +0100, Alexander Graf wrote:
> On 26.03.20 18:05, Christoph Hellwig wrote:
> >
> > On Thu, Mar 26, 2020 at 05:29:22PM +0100, Alexander Graf wrote:
> > > The swiotlb is a very convenient fallback mechanism for bounce buffering
> > > of
> > > DMAable data. It is u
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:32 PM
>
> From: Liu Yi L
>
> Recent years, mediated device pass-through framework (e.g. vfio-mdev)
> are used to achieve flexible device sharing across domains (e.g. VMs).
are->is
> Also there are hardware assisted mediated pass-through solut
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:32 PM
>
> From: Liu Yi L
>
> For VFIO IOMMUs with the type VFIO_TYPE1_NESTING_IOMMU, guest
> "owns" the
> first-level/stage-1 translation structures, the host IOMMU driver has no
> knowledge of first-level/stage-1 structure cache updates unless
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:32 PM
>
> From: Liu Yi L
>
> VFIO_TYPE1_NESTING_IOMMU is an IOMMU type which is backed by
> hardware
> IOMMUs that have nesting DMA translation (a.k.a dual stage address
> translation). For such hardware IOMMUs, there are two stages/levels of
>
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:32 PM
>
> From: Liu Yi L
>
> VFIO exposes IOMMU nesting translation (a.k.a dual stage translation)
> capability to userspace. Thus applications like QEMU could support
> vIOMMU with hardware's nesting translation capability for pass-through
> d
> From: Liu, Yi L
> Sent: Monday, March 30, 2020 5:27 PM
>
> > From: Tian, Kevin
> > Sent: Monday, March 30, 2020 5:20 PM
> > To: Liu, Yi L ; alex.william...@redhat.com;
> > Subject: RE: [PATCH v1 2/8] vfio/type1: Add vfio_iommu_type1 parameter
> for quota
> > tuning
> >
> > > From: Liu, Yi L
>
On Sat, Mar 28, 2020 at 7:57 PM Dave Young wrote:
>
> On 03/26/20 at 05:29pm, Alexander Graf wrote:
> > The swiotlb is a very convenient fallback mechanism for bounce buffering of
> > DMAable data. It is usually used for the compatibility case where devices
> > can only DMA to a "low region".
> >
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:32 PM
>
> From: Liu Yi L
>
> This patch reports PASID alloc/free availability to userspace (e.g. QEMU)
> thus userspace could do a pre-check before utilizing this feature.
>
> Cc: Kevin Tian
> CC: Jacob Pan
> Cc: Alex Williamson
> Cc: Eric
> From: Tian, Kevin
> Sent: Monday, March 30, 2020 5:20 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [PATCH v1 2/8] vfio/type1: Add vfio_iommu_type1 parameter for
> quota
> tuning
>
> > From: Liu, Yi L
> > Sent: Monday, March 30, 2020 4:53 PM
> >
> > > From: Tian, Kevin
> >
> From: Liu, Yi L
> Sent: Monday, March 30, 2020 4:53 PM
>
> > From: Tian, Kevin
> > Sent: Monday, March 30, 2020 4:41 PM
> > To: Liu, Yi L ; alex.william...@redhat.com;
> > Subject: RE: [PATCH v1 2/8] vfio/type1: Add vfio_iommu_type1 parameter
> for quota
> > tuning
> >
> > > From: Liu, Yi L
>
> From: Tian, Kevin
> Sent: Monday, March 30, 2020 4:41 PM
> To: Liu, Yi L ; alex.william...@redhat.com;
> Subject: RE: [PATCH v1 2/8] vfio/type1: Add vfio_iommu_type1 parameter for
> quota
> tuning
>
> > From: Liu, Yi L
> > Sent: Sunday, March 22, 2020 8:32 PM
> >
> > From: Liu Yi L
> >
> > T
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:32 PM
>
> From: Liu Yi L
>
> This patch adds a module option to make the PASID quota tunable by
> administrator.
>
> TODO: needs to think more on how to make the tuning to be per-process.
>
> Previous discussions:
> https://patchwork.kernel.
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:32 PM
>
> From: Liu Yi L
>
> For a long time, devices have only one DMA address space from platform
> IOMMU's point of view. This is true for both bare metal and directed-
> access in virtualization environment. Reason is the source ID of DMA i
47 matches
Mail list logo