> From: Paolo Bonzini
> Sent: Wednesday, October 27, 2021 6:32 PM
>
> On 27/10/21 08:18, Tian, Kevin wrote:
> >> I absolutely do *not* want an API that tells KVM to enable WBINVD. This
> >> is not up for discussion.
> >>
> >> But really, let's stop calling the file descriptor a security proof
On 27/10/21 08:18, Tian, Kevin wrote:
I absolutely do *not* want an API that tells KVM to enable WBINVD. This
is not up for discussion.
But really, let's stop calling the file descriptor a security proof or a
capability. It's overkill; all that we are doing here is kernel
acceleration of the
Hi, Paolo,
> From: Paolo Bonzini
> Sent: Wednesday, June 9, 2021 11:21 PM
>
> On 09/06/21 16:45, Jason Gunthorpe wrote:
> > On Wed, Jun 09, 2021 at 08:31:34AM -0600, Alex Williamson wrote:
> >
> >> If we go back to the wbinvd ioctl mechanism, if I call that ioctl with
> >> an ioasidfd that
On Mon, Jun 07, 2021 at 11:14:24AM -0300, Jason Gunthorpe wrote:
> "non-coherent DMA" is some general euphemism that evokes images of
> embedded platforms that don't have coherent DMA at all and have low
> cost ways to regain coherence. This is not at all what we are talking
> about here at all.
On Fri, Jun 04, 2021 at 08:58:05AM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 04, 2021 at 09:11:03AM +0800, Jason Wang wrote:
> > > nor do any virtio drivers implement the required platform specific
> > > cache flushing to make no-snoop TLPs work.
> >
> > I don't get why virtio drivers needs to
On Wed, Jun 09, 2021 at 09:47:42AM -0300, Jason Gunthorpe wrote:
> I can vaugely understand this rational for vfio, but not at all for
> the platform's iommu driver, sorry.
Agreed. More importantly the dependency is not for the platform iommu
driver but just for the core iommu code, which is
On Mon, Jun 07, 2021 at 03:25:32AM +, Tian, Kevin wrote:
>
> Possibly just a naming thing, but I feel it's better to just talk about
> no-snoop or non-coherent in the uAPI. Per Intel SDM wbinvd is a
> privileged instruction. A process on the host has no privilege to
> execute it. Only when
On Tue, Jun 08, 2021 at 09:20:29AM +0800, Jason Wang wrote:
> "
>
> 6.2.17 _CCA (Cache Coherency Attribute) The _CCA object returns whether or
> not a bus-master device supports hardware managed cache coherency. Expected
> values are 0 to indicate it is not supported, and 1 to indicate that it is
On Mon, Jun 07, 2021 at 04:08:02PM -0300, Jason Gunthorpe wrote:
> Compatibility is important, but when I look in the kernel code I see
> very few places that call wbinvd(). Basically all DRM for something
> relavent to qemu.
>
> That tells me that the vast majority of PCI devices do not generate
On Wed, Jun 23, 2021 at 07:59:21AM +, Tian, Kevin wrote:
> > From: David Gibson
> > Sent: Thursday, June 17, 2021 11:48 AM
> >
> > On Tue, Jun 08, 2021 at 10:17:56AM -0300, Jason Gunthorpe wrote:
> > > On Tue, Jun 08, 2021 at 12:37:04PM +1000, David Gibson wrote:
> > >
> > > > > The
On Fri, Jun 18, 2021 at 07:03:31PM +0200, Jean-Philippe Brucker wrote:
> On Thu, Jun 17, 2021 at 01:00:14PM +1000, David Gibson wrote:
> > On Thu, Jun 10, 2021 at 06:37:31PM +0200, Jean-Philippe Brucker wrote:
> > > On Tue, Jun 08, 2021 at 04:31:50PM +1000, David Gibson wrote:
> > > > For the qemu
On Wed, Jun 23, 2021 at 08:00:49AM +, Tian, Kevin wrote:
> > From: David Gibson
> > Sent: Thursday, June 17, 2021 12:08 PM
> >
> > On Thu, Jun 03, 2021 at 08:12:27AM +, Tian, Kevin wrote:
> > > > From: David Gibson
> > > > Sent: Wednesday, June 2, 2021 2:15 PM
> > > >
> > > [...]
> > >
>
> From: Jason Gunthorpe
> Sent: Saturday, June 19, 2021 2:31 AM
>
> On Fri, Jun 18, 2021 at 07:03:31PM +0200, Jean-Philippe Brucker wrote:
>
> > configuration. The Arm SMMUs have a lot of small features that
> > implementations can mix and match and that a user shouldn't have to care
> > about,
> From: David Gibson
> Sent: Thursday, June 17, 2021 12:08 PM
>
> On Thu, Jun 03, 2021 at 08:12:27AM +, Tian, Kevin wrote:
> > > From: David Gibson
> > > Sent: Wednesday, June 2, 2021 2:15 PM
> > >
> > [...]
> >
> > > >
> > > > /*
> > > > * Get information about an I/O address space
> > >
> From: David Gibson
> Sent: Thursday, June 17, 2021 11:48 AM
>
> On Tue, Jun 08, 2021 at 10:17:56AM -0300, Jason Gunthorpe wrote:
> > On Tue, Jun 08, 2021 at 12:37:04PM +1000, David Gibson wrote:
> >
> > > > The PPC/SPAPR support allows KVM to associate a vfio group to an
> IOMMU
> > > > page
> From: Jean-Philippe Brucker
> Sent: Saturday, June 19, 2021 1:04 AM
>
> On Thu, Jun 17, 2021 at 01:00:14PM +1000, David Gibson wrote:
> > On Thu, Jun 10, 2021 at 06:37:31PM +0200, Jean-Philippe Brucker wrote:
> > > On Tue, Jun 08, 2021 at 04:31:50PM +1000, David Gibson wrote:
> > > > For the
On Fri, Jun 18, 2021 at 07:03:31PM +0200, Jean-Philippe Brucker wrote:
> configuration. The Arm SMMUs have a lot of small features that
> implementations can mix and match and that a user shouldn't have to care
> about, and there are lots of different implementations by various
> vendors.
This
On Thu, Jun 17, 2021 at 01:00:14PM +1000, David Gibson wrote:
> On Thu, Jun 10, 2021 at 06:37:31PM +0200, Jean-Philippe Brucker wrote:
> > On Tue, Jun 08, 2021 at 04:31:50PM +1000, David Gibson wrote:
> > > For the qemu case, I would imagine a two stage fallback:
> > >
> > > 1) Ask for the
On Tue, Jun 08, 2021 at 10:17:56AM -0300, Jason Gunthorpe wrote:
> On Tue, Jun 08, 2021 at 12:37:04PM +1000, David Gibson wrote:
>
> > > The PPC/SPAPR support allows KVM to associate a vfio group to an IOMMU
> > > page table so that it can handle iotlb programming from pre-registered
> > > memory
On Thu, Jun 03, 2021 at 08:12:27AM +, Tian, Kevin wrote:
> > From: David Gibson
> > Sent: Wednesday, June 2, 2021 2:15 PM
> >
> [...]
>
> > >
> > > /*
> > > * Get information about an I/O address space
> > > *
> > > * Supported capabilities:
> > > * - VFIO type1 map/unmap;
> >
On Tue, Jun 08, 2021 at 04:04:06PM -0300, Jason Gunthorpe wrote:
> On Tue, Jun 08, 2021 at 10:53:02AM +1000, David Gibson wrote:
> > On Thu, Jun 03, 2021 at 08:52:24AM -0300, Jason Gunthorpe wrote:
> > > On Thu, Jun 03, 2021 at 03:13:44PM +1000, David Gibson wrote:
> > >
> > > > > We can still
On Thu, Jun 10, 2021 at 06:37:31PM +0200, Jean-Philippe Brucker wrote:
> On Tue, Jun 08, 2021 at 04:31:50PM +1000, David Gibson wrote:
> > For the qemu case, I would imagine a two stage fallback:
> >
> > 1) Ask for the exact IOMMU capabilities (including pagetable
> >format) that the
> From: Jason Gunthorpe
> Sent: Wednesday, June 16, 2021 7:59 AM
>
> On Tue, Jun 15, 2021 at 11:56:28PM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, June 16, 2021 7:41 AM
> > >
> > > On Tue, Jun 15, 2021 at 11:09:37PM +, Tian, Kevin wrote:
> > >
> > > > which
On Tue, Jun 15, 2021 at 11:56:28PM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, June 16, 2021 7:41 AM
> >
> > On Tue, Jun 15, 2021 at 11:09:37PM +, Tian, Kevin wrote:
> >
> > > which information can you elaborate? This is the area which I'm not
> > > familiar
> From: Jason Gunthorpe
> Sent: Wednesday, June 16, 2021 7:41 AM
>
> On Tue, Jun 15, 2021 at 11:09:37PM +, Tian, Kevin wrote:
>
> > which information can you elaborate? This is the area which I'm not
> > familiar with thus would appreciate if you can help explain how this
> > bus specific
On Tue, Jun 15, 2021 at 11:09:37PM +, Tian, Kevin wrote:
> which information can you elaborate? This is the area which I'm not
> familiar with thus would appreciate if you can help explain how this
> bus specific information is utilized within the attach function or
> sometime later.
This
> From: Jason Gunthorpe
> Sent: Wednesday, June 16, 2021 7:02 AM
>
> On Tue, Jun 15, 2021 at 10:59:06PM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, June 15, 2021 11:07 PM
> > >
> > > On Tue, Jun 15, 2021 at 08:59:25AM +, Tian, Kevin wrote:
> > > > Hi, Jason,
>
On Tue, Jun 15, 2021 at 10:59:06PM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, June 15, 2021 11:07 PM
> >
> > On Tue, Jun 15, 2021 at 08:59:25AM +, Tian, Kevin wrote:
> > > Hi, Jason,
> > >
> > > > From: Jason Gunthorpe
> > > > Sent: Thursday, June 3, 2021 9:05 PM
> From: Jason Gunthorpe
> Sent: Tuesday, June 15, 2021 11:07 PM
>
> On Tue, Jun 15, 2021 at 08:59:25AM +, Tian, Kevin wrote:
> > Hi, Jason,
> >
> > > From: Jason Gunthorpe
> > > Sent: Thursday, June 3, 2021 9:05 PM
> > >
> > > On Thu, Jun 03, 2021 at 06:39:30AM +, Tian, Kevin wrote:
> >
On Tue, Jun 15, 2021 at 08:59:25AM +, Tian, Kevin wrote:
> Hi, Jason,
>
> > From: Jason Gunthorpe
> > Sent: Thursday, June 3, 2021 9:05 PM
> >
> > On Thu, Jun 03, 2021 at 06:39:30AM +, Tian, Kevin wrote:
> > > > > Two helper functions are provided to support VFIO_ATTACH_IOASID:
> > > > >
Hi, Jason,
> From: Jason Gunthorpe
> Sent: Thursday, June 3, 2021 9:05 PM
>
> On Thu, Jun 03, 2021 at 06:39:30AM +, Tian, Kevin wrote:
> > > > Two helper functions are provided to support VFIO_ATTACH_IOASID:
> > > >
> > > > struct attach_info {
> > > > u32 ioasid;
在 2021/6/10 下午7:47, Jason Gunthorpe 写道:
On Thu, Jun 10, 2021 at 10:00:01AM +0800, Jason Wang wrote:
在 2021/6/8 下午9:20, Jason Gunthorpe 写道:
On Tue, Jun 08, 2021 at 09:10:42AM +0800, Jason Wang wrote:
Well, this sounds like a re-invention of io_uring which has already worked
for multifds.
On Tue, Jun 08, 2021 at 04:31:50PM +1000, David Gibson wrote:
> For the qemu case, I would imagine a two stage fallback:
>
> 1) Ask for the exact IOMMU capabilities (including pagetable
>format) that the vIOMMU has. If the host can supply, you're
>good
>
> 2) If not, ask
On Thu, Jun 10, 2021 at 10:00:01AM +0800, Jason Wang wrote:
>
> 在 2021/6/8 下午9:20, Jason Gunthorpe 写道:
> > On Tue, Jun 08, 2021 at 09:10:42AM +0800, Jason Wang wrote:
> >
> > > Well, this sounds like a re-invention of io_uring which has already worked
> > > for multifds.
> > How so? io_uring is
在 2021/6/10 上午10:00, Jason Wang 写道:
在 2021/6/8 下午9:20, Jason Gunthorpe 写道:
On Tue, Jun 08, 2021 at 09:10:42AM +0800, Jason Wang wrote:
Well, this sounds like a re-invention of io_uring which has already
worked
for multifds.
How so? io_uring is about sending work to the kernel, not getting
在 2021/6/8 下午6:45, Enrico Weigelt, metux IT consult 写道:
On 07.06.21 20:01, Jason Gunthorpe wrote:
it is what it is, select has a fixed size bitmap of FD #s and
a hard upper bound on that size as part of the glibc ABI - can't be
fixed.
in glibc ABI ? Uuuuh!
Note that dealing with select()
在 2021/6/8 下午9:20, Jason Gunthorpe 写道:
On Tue, Jun 08, 2021 at 09:10:42AM +0800, Jason Wang wrote:
Well, this sounds like a re-invention of io_uring which has already worked
for multifds.
How so? io_uring is about sending work to the kernel, not getting
structued events back?
Actually it
On Wed, 9 Jun 2021 02:49:32 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Wednesday, June 9, 2021 2:47 AM
> >
> > On Tue, 8 Jun 2021 15:44:26 +0200
> > Paolo Bonzini wrote:
> >
> > > On 08/06/21 15:15, Jason Gunthorpe wrote:
> > > > On Tue, Jun 08, 2021 at 09:56:09AM
On 09/06/21 16:45, Jason Gunthorpe wrote:
On Wed, Jun 09, 2021 at 08:31:34AM -0600, Alex Williamson wrote:
If we go back to the wbinvd ioctl mechanism, if I call that ioctl with
an ioasidfd that contains no devices, then I shouldn't be able to
generate a wbinvd on the processor, right? If I
On Wed, Jun 09, 2021 at 08:31:34AM -0600, Alex Williamson wrote:
> If we go back to the wbinvd ioctl mechanism, if I call that ioctl with
> an ioasidfd that contains no devices, then I shouldn't be able to
> generate a wbinvd on the processor, right? If I add a device,
> especially in a
On Wed, Jun 09, 2021 at 03:24:11PM +0200, Paolo Bonzini wrote:
> On 09/06/21 14:47, Jason Gunthorpe wrote:
> > On Wed, Jun 09, 2021 at 02:46:05PM +0200, Paolo Bonzini wrote:
> > > On 09/06/21 13:57, Jason Gunthorpe wrote:
> > > > On Wed, Jun 09, 2021 at 02:49:32AM +, Tian, Kevin wrote:
> > > >
On Wed, 9 Jun 2021 08:54:45 -0300
Jason Gunthorpe wrote:
> On Wed, Jun 09, 2021 at 11:11:17AM +0200, Paolo Bonzini wrote:
> > On 09/06/21 10:51, Enrico Weigelt, metux IT consult wrote:
> > > On 08.06.21 21:00, Jason Gunthorpe wrote:
> > >
> > > > Eg I can do open() on a file and I get to
On 09/06/21 14:47, Jason Gunthorpe wrote:
On Wed, Jun 09, 2021 at 02:46:05PM +0200, Paolo Bonzini wrote:
On 09/06/21 13:57, Jason Gunthorpe wrote:
On Wed, Jun 09, 2021 at 02:49:32AM +, Tian, Kevin wrote:
Last unclosed open. Jason, you dislike symbol_get in this contract per
earlier
On Wed, Jun 09, 2021 at 02:46:05PM +0200, Paolo Bonzini wrote:
> On 09/06/21 13:57, Jason Gunthorpe wrote:
> > On Wed, Jun 09, 2021 at 02:49:32AM +, Tian, Kevin wrote:
> >
> > > Last unclosed open. Jason, you dislike symbol_get in this contract per
> > > earlier comment. As Alex explained,
On 09/06/21 13:57, Jason Gunthorpe wrote:
On Wed, Jun 09, 2021 at 02:49:32AM +, Tian, Kevin wrote:
Last unclosed open. Jason, you dislike symbol_get in this contract per
earlier comment. As Alex explained, looks it's more about module
dependency which is orthogonal to how this contract is
On Wed, Jun 09, 2021 at 02:49:32AM +, Tian, Kevin wrote:
> Last unclosed open. Jason, you dislike symbol_get in this contract per
> earlier comment. As Alex explained, looks it's more about module
> dependency which is orthogonal to how this contract is designed. What
> is your opinion now?
On Wed, Jun 09, 2021 at 11:11:17AM +0200, Paolo Bonzini wrote:
> On 09/06/21 10:51, Enrico Weigelt, metux IT consult wrote:
> > On 08.06.21 21:00, Jason Gunthorpe wrote:
> >
> > > Eg I can do open() on a file and I get to keep that FD. I get to keep
> > > that FD even if someone later does
On 09/06/21 10:51, Enrico Weigelt, metux IT consult wrote:
On 08.06.21 21:00, Jason Gunthorpe wrote:
Eg I can do open() on a file and I get to keep that FD. I get to keep
that FD even if someone later does chmod() on that file so I can't
open it again.
There are lots of examples where a one
On 08.06.21 21:00, Jason Gunthorpe wrote:
Eg I can do open() on a file and I get to keep that FD. I get to keep
that FD even if someone later does chmod() on that file so I can't
open it again.
There are lots of examples where a one time access control check
provides continuing access to a
> From: David Gibson
> Sent: Tuesday, June 8, 2021 8:50 AM
>
> On Thu, Jun 03, 2021 at 06:49:20AM +, Tian, Kevin wrote:
> > > From: David Gibson
> > > Sent: Thursday, June 3, 2021 1:09 PM
> > [...]
> > > > > In this way the SW mode is the same as a HW mode with an infinite
> > > > > cache.
>
> From: Alex Williamson
> Sent: Wednesday, June 9, 2021 2:47 AM
>
> On Tue, 8 Jun 2021 15:44:26 +0200
> Paolo Bonzini wrote:
>
> > On 08/06/21 15:15, Jason Gunthorpe wrote:
> > > On Tue, Jun 08, 2021 at 09:56:09AM +0200, Paolo Bonzini wrote:
> > >
> > Alternatively you can add a
On Tue, Jun 08, 2021 at 04:04:26PM +1000, David Gibson wrote:
> > What I would like is that the /dev/iommu side managing the IOASID
> > doesn't really care much, but the device driver has to tell
> > drivers/iommu what it is going to do when it attaches.
>
> By the device driver, do you mean the
On Tue, Jun 08, 2021 at 10:53:02AM +1000, David Gibson wrote:
> On Thu, Jun 03, 2021 at 08:52:24AM -0300, Jason Gunthorpe wrote:
> > On Thu, Jun 03, 2021 at 03:13:44PM +1000, David Gibson wrote:
> >
> > > > We can still consider it a single "address space" from the IOMMU
> > > > perspective. What
On Tue, Jun 08, 2021 at 12:47:00PM -0600, Alex Williamson wrote:
> On Tue, 8 Jun 2021 15:44:26 +0200
> Paolo Bonzini wrote:
>
> > On 08/06/21 15:15, Jason Gunthorpe wrote:
> > > On Tue, Jun 08, 2021 at 09:56:09AM +0200, Paolo Bonzini wrote:
> > >
> > Alternatively you can add a
On Tue, 8 Jun 2021 15:44:26 +0200
Paolo Bonzini wrote:
> On 08/06/21 15:15, Jason Gunthorpe wrote:
> > On Tue, Jun 08, 2021 at 09:56:09AM +0200, Paolo Bonzini wrote:
> >
> Alternatively you can add a KVM_DEV_IOASID_{ADD,DEL} pair of ioctls. But
> it
> seems useless
On 08/06/21 15:15, Jason Gunthorpe wrote:
On Tue, Jun 08, 2021 at 09:56:09AM +0200, Paolo Bonzini wrote:
Alternatively you can add a KVM_DEV_IOASID_{ADD,DEL} pair of ioctls. But it
seems useless complication compared to just using what we have now, at least
while VMs only use IOASIDs via VFIO.
On Tue, Jun 08, 2021 at 09:10:42AM +0800, Jason Wang wrote:
> Well, this sounds like a re-invention of io_uring which has already worked
> for multifds.
How so? io_uring is about sending work to the kernel, not getting
structued events back?
It is more like one of the perf rings
Jason
On Tue, Jun 08, 2021 at 12:37:04PM +1000, David Gibson wrote:
> > The PPC/SPAPR support allows KVM to associate a vfio group to an IOMMU
> > page table so that it can handle iotlb programming from pre-registered
> > memory without trapping out to userspace.
>
> To clarify that's a guest side
On Tue, Jun 08, 2021 at 09:56:09AM +0200, Paolo Bonzini wrote:
> > > Alternatively you can add a KVM_DEV_IOASID_{ADD,DEL} pair of ioctls. But
> > > it
> > > seems useless complication compared to just using what we have now, at
> > > least
> > > while VMs only use IOASIDs via VFIO.
> >
> > The
On Tue, Jun 08, 2021 at 12:43:38PM +0200, Enrico Weigelt, metux IT consult
wrote:
> > It is two devices, thus two files.
>
> Two separate real (hardware) devices or just two logical device nodes ?
A real PCI device and a real IOMMU block integrated into the CPU
Jason
On Tue, Jun 08, 2021 at 10:54:59AM +0200, Enrico Weigelt, metux IT consult
wrote:
> Maybe the device as well as the transport could announce their
> capability (which IMHO should go via the virtio protocol), and if both
> are capable, the (guest's) virtio subsys tells the driver whether it's
>
On 07.06.21 20:01, Jason Gunthorpe wrote:
it is what it is, select has a fixed size bitmap of FD #s and
a hard upper bound on that size as part of the glibc ABI - can't be
fixed.
in glibc ABI ? Uuuuh!
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
On 04.06.21 14:30, Jason Gunthorpe wrote:
Hi,
Containers already needed to do this today. Container orchestration is
hard.
Yes, but I hate to see even more work upcoming here.
Yes, /dev/ioasid shouldn't do anything unless you have a device to
connect it with. In this way it is probably
On 08.06.21 03:00, Jason Wang wrote:
Hi folks,
Just to make sure we are in the same page. What I meant is, if the DMA
behavior like (no-snoop) is device specific. There's no need to mandate
a virtio general attributes. We can describe it per device. The devices
implemented in the current
On 07/06/21 19:59, Jason Gunthorpe wrote:
The KVM interface is the same kvm-vfio device that exists already. The
userspace API does not need to change at all: adding one VFIO file
descriptor with WBINVD enabled to the kvm-vfio device lets the VM use WBINVD
functionality (see
On Thu, Jun 03, 2021 at 09:11:05AM -0300, Jason Gunthorpe wrote:
> On Thu, Jun 03, 2021 at 03:45:09PM +1000, David Gibson wrote:
> > On Wed, Jun 02, 2021 at 01:58:38PM -0300, Jason Gunthorpe wrote:
> > > On Wed, Jun 02, 2021 at 04:48:35PM +1000, David Gibson wrote:
> > > > > > /* Bind guest
On Thu, Jun 03, 2021 at 07:17:23AM +, Tian, Kevin wrote:
> > From: David Gibson
> > Sent: Wednesday, June 2, 2021 2:15 PM
> >
> [...]
> > > An I/O address space takes effect in the IOMMU only after it is attached
> > > to a device. The device in the /dev/ioasid context always refers to a
>
On Fri, Jun 04, 2021 at 12:24:08PM +0200, Jean-Philippe Brucker wrote:
> On Thu, Jun 03, 2021 at 03:45:09PM +1000, David Gibson wrote:
> > > > But it would certainly be possible for a system to have two
> > > > different host bridges with two different IOMMUs with different
> > > > pagetable
On Thu, Jun 03, 2021 at 09:28:32AM -0300, Jason Gunthorpe wrote:
> On Thu, Jun 03, 2021 at 03:23:17PM +1000, David Gibson wrote:
> > On Wed, Jun 02, 2021 at 01:37:53PM -0300, Jason Gunthorpe wrote:
> > > On Wed, Jun 02, 2021 at 04:57:52PM +1000, David Gibson wrote:
> > >
> > > > I don't think
Hi Jaocb,
Sorry for the late response. Was on PTO on Friday last week.
Please see comments below.
> From: Jacob Pan
> Sent: Friday, June 4, 2021 2:28 AM
>
> Hi Parav,
>
> On Tue, 1 Jun 2021 17:30:51 +, Parav Pandit wrote:
>
> > > From: Tian, Kevin
> > > Sent: Thursday, May 27, 2021
On Tue, Jun 01, 2021 at 04:22:25PM -0600, Alex Williamson wrote:
> On Tue, 1 Jun 2021 07:01:57 +
> "Tian, Kevin" wrote:
> >
> > I summarized five opens here, about:
> >
> > 1) Finalizing the name to replace /dev/ioasid;
> > 2) Whether one device is allowed to bind to multiple IOASID fd's;
On Thu, Jun 03, 2021 at 06:49:20AM +, Tian, Kevin wrote:
> > From: David Gibson
> > Sent: Thursday, June 3, 2021 1:09 PM
> [...]
> > > > In this way the SW mode is the same as a HW mode with an infinite
> > > > cache.
> > > >
> > > > The collaposed shadow page table is really just a cache.
> >
On Fri, Jun 04, 2021 at 09:30:54AM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 04, 2021 at 12:44:28PM +0200, Enrico Weigelt, metux IT consult
> wrote:
> > On 02.06.21 19:24, Jason Gunthorpe wrote:
> >
> > Hi,
> >
> > >> If I understand this correctly, /dev/ioasid is a kind of "common
> >
On Thu, Jun 03, 2021 at 08:52:24AM -0300, Jason Gunthorpe wrote:
> On Thu, Jun 03, 2021 at 03:13:44PM +1000, David Gibson wrote:
>
> > > We can still consider it a single "address space" from the IOMMU
> > > perspective. What has happened is that the address table is not just a
> > > 64 bit IOVA,
在 2021/6/8 上午3:41, Alex Williamson 写道:
On Mon, 7 Jun 2021 16:08:02 -0300
Jason Gunthorpe wrote:
On Mon, Jun 07, 2021 at 12:59:46PM -0600, Alex Williamson wrote:
It is up to qemu if it wants to proceed or not. There is no issue with
allowing the use of no-snoop and blocking wbinvd, other
在 2021/6/3 上午1:21, Jason Gunthorpe 写道:
On Wed, Jun 02, 2021 at 04:54:26PM +0800, Jason Wang wrote:
在 2021/6/2 上午1:31, Jason Gunthorpe 写道:
On Tue, Jun 01, 2021 at 04:47:15PM +0800, Jason Wang wrote:
We can open up to ~0U file descriptors, I don't see why we need to restrict
it in uAPI.
There
On 2021/6/7 20:19, Liu, Yi L wrote:
>> From: Shenming Lu
>> Sent: Friday, June 4, 2021 10:03 AM
>>
>> On 2021/6/4 2:19, Jacob Pan wrote:
>>> Hi Shenming,
>>>
>>> On Wed, 2 Jun 2021 12:50:26 +0800, Shenming Lu
>>
>>> wrote:
>>>
On 2021/6/2 1:33, Jason Gunthorpe wrote:
> On Tue, Jun 01,
在 2021/6/7 下午10:14, Jason Gunthorpe 写道:
On Mon, Jun 07, 2021 at 11:18:33AM +0800, Jason Wang wrote:
Note that no drivers call these things doesn't meant it was not
supported by the spec.
Of course it does. If the spec doesn't define exactly when the driver
should call the cache flushes for
On Mon, 7 Jun 2021 20:03:53 -0300
Jason Gunthorpe wrote:
> On Mon, Jun 07, 2021 at 01:41:28PM -0600, Alex Williamson wrote:
>
> > > Compatibility is important, but when I look in the kernel code I see
> > > very few places that call wbinvd(). Basically all DRM for something
> > > relavent to
On Mon, Jun 07, 2021 at 01:41:28PM -0600, Alex Williamson wrote:
> > Compatibility is important, but when I look in the kernel code I see
> > very few places that call wbinvd(). Basically all DRM for something
> > relavent to qemu.
> >
> > That tells me that the vast majority of PCI devices do
On Mon, 7 Jun 2021 16:08:02 -0300
Jason Gunthorpe wrote:
> On Mon, Jun 07, 2021 at 12:59:46PM -0600, Alex Williamson wrote:
>
> > > It is up to qemu if it wants to proceed or not. There is no issue with
> > > allowing the use of no-snoop and blocking wbinvd, other than some
> > > drivers may
On Mon, Jun 07, 2021 at 12:59:46PM -0600, Alex Williamson wrote:
> > It is up to qemu if it wants to proceed or not. There is no issue with
> > allowing the use of no-snoop and blocking wbinvd, other than some
> > drivers may malfunction. If the user is certain they don't have
> > malfunctioning
On Mon, 7 Jun 2021 15:18:58 -0300
Jason Gunthorpe wrote:
> On Mon, Jun 07, 2021 at 09:41:48AM -0600, Alex Williamson wrote:
> > You're calling this an admin knob, which to me suggests a global module
> > option, so are you trying to implement both an administrator and a user
> > policy? ie. the
On Mon, Jun 07, 2021 at 09:41:48AM -0600, Alex Williamson wrote:
> You're calling this an admin knob, which to me suggests a global module
> option, so are you trying to implement both an administrator and a user
> policy? ie. the user can create scenarios where access to wbinvd might
> be
On Mon, Jun 07, 2021 at 03:30:21PM +0200, Enrico Weigelt, metux IT consult
wrote:
> On 02.06.21 19:21, Jason Gunthorpe wrote:
>
> Hi,
>
> > Not really, once one thing in an applicate uses a large number FDs the
> > entire application is effected. If any open() can return 'very big
> > number'
On Mon, Jun 07, 2021 at 08:51:42AM +0200, Paolo Bonzini wrote:
> On 07/06/21 05:25, Tian, Kevin wrote:
> > Per Intel SDM wbinvd is a privileged instruction. A process on the
> > host has no privilege to execute it.
>
> (Half of) the point of the kernel is to do privileged tasks on the
>
On Sat, Jun 05, 2021 at 08:22:27AM +0200, Paolo Bonzini wrote:
> On 04/06/21 19:22, Jason Gunthorpe wrote:
> > 4) The KVM interface is the very simple enable/disable WBINVD.
> > Possessing a FD that can do IOMMU_EXECUTE_WBINVD is required
> > to enable WBINVD at KVM.
>
> The KVM
On Fri, Jun 04, 2021 at 11:10:53PM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Friday, June 4, 2021 8:09 PM
> >
> > On Fri, Jun 04, 2021 at 06:37:26AM +, Tian, Kevin wrote:
> > > > From: Jason Gunthorpe
> > > > Sent: Thursday, June 3, 2021 9:05 PM
> > > >
> > > > > >
> > >
On Fri, 4 Jun 2021 20:01:08 -0300
Jason Gunthorpe wrote:
> On Fri, Jun 04, 2021 at 03:29:18PM -0600, Alex Williamson wrote:
> > On Fri, 4 Jun 2021 14:22:07 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Fri, Jun 04, 2021 at 06:10:51PM +0200, Paolo Bonzini wrote:
> > > > On 04/06/21 18:03,
On Mon, Jun 07, 2021 at 11:18:33AM +0800, Jason Wang wrote:
> Note that no drivers call these things doesn't meant it was not
> supported by the spec.
Of course it does. If the spec doesn't define exactly when the driver
should call the cache flushes for no-snoop transactions then the
protocol
On 02.06.21 19:21, Jason Gunthorpe wrote:
Hi,
Not really, once one thing in an applicate uses a large number FDs the
entire application is effected. If any open() can return 'very big
number' then nothing in the process is allowed to ever use select.
isn't that a bug in select() ?
--mtx
--
> From: Shenming Lu
> Sent: Friday, June 4, 2021 10:03 AM
>
> On 2021/6/4 2:19, Jacob Pan wrote:
> > Hi Shenming,
> >
> > On Wed, 2 Jun 2021 12:50:26 +0800, Shenming Lu
>
> > wrote:
> >
> >> On 2021/6/2 1:33, Jason Gunthorpe wrote:
> >>> On Tue, Jun 01, 2021 at 08:30:35PM +0800, Lu Baolu wrote:
On 07/06/21 05:25, Tian, Kevin wrote:
Per Intel SDM wbinvd is a privileged instruction. A process on the
host has no privilege to execute it.
(Half of) the point of the kernel is to do privileged tasks on the
processes' behalf. There are good reasons why a process that uses VFIO
(without
> From: Paolo Bonzini
> Sent: Saturday, June 5, 2021 2:22 PM
>
> On 04/06/21 19:22, Jason Gunthorpe wrote:
> > 4) The KVM interface is the very simple enable/disable WBINVD.
> > Possessing a FD that can do IOMMU_EXECUTE_WBINVD is required
> > to enable WBINVD at KVM.
>
> The KVM
> From: Alex Williamson
> Sent: Saturday, June 5, 2021 5:29 AM
>
> On Fri, 4 Jun 2021 14:22:07 -0300
> Jason Gunthorpe wrote:
>
> > On Fri, Jun 04, 2021 at 06:10:51PM +0200, Paolo Bonzini wrote:
> > > On 04/06/21 18:03, Jason Gunthorpe wrote:
> > > > On Fri, Jun 04, 2021 at 05:57:19PM +0200,
在 2021/6/4 下午7:58, Jason Gunthorpe 写道:
On Fri, Jun 04, 2021 at 09:11:03AM +0800, Jason Wang wrote:
nor do any virtio drivers implement the required platform specific
cache flushing to make no-snoop TLPs work.
I don't get why virtio drivers needs to do that. I think DMA API should hide
those
On 04/06/21 19:22, Jason Gunthorpe wrote:
4) The KVM interface is the very simple enable/disable WBINVD.
Possessing a FD that can do IOMMU_EXECUTE_WBINVD is required
to enable WBINVD at KVM.
The KVM interface is the same kvm-vfio device that exists already. The
userspace API does
> From: Jason Gunthorpe
> Sent: Friday, June 4, 2021 8:34 PM
>
> On Fri, Jun 04, 2021 at 06:08:28AM +, Tian, Kevin wrote:
>
> > In Qemu case the problem is that it doesn't know the list of devices
> > that will be attached to an IOASID when it's created. This is a guest-
> > side knowledge
> From: Jason Gunthorpe
> Sent: Friday, June 4, 2021 8:09 PM
>
> On Fri, Jun 04, 2021 at 06:37:26AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, June 3, 2021 9:05 PM
> > >
> > > > >
> > > > > 3) Device accepts any PASIDs from the guest. No
> > > > >
On Fri, Jun 04, 2021 at 03:29:18PM -0600, Alex Williamson wrote:
> On Fri, 4 Jun 2021 14:22:07 -0300
> Jason Gunthorpe wrote:
>
> > On Fri, Jun 04, 2021 at 06:10:51PM +0200, Paolo Bonzini wrote:
> > > On 04/06/21 18:03, Jason Gunthorpe wrote:
> > > > On Fri, Jun 04, 2021 at 05:57:19PM +0200,
1 - 100 of 259 matches
Mail list logo
