On Fri, 24 Jun 2022 18:51:44 +0100
Robin Murphy wrote:
> Since IOMMU groups are mandatory for drivers to support, it stands to
> reason that any device which has been successfully added to a group
> must be on a bus supported by that IOMMU driver, and therefore a domain
> viable for any device in
On Fri, 24 Jun 2022 18:51:44 +0100
Robin Murphy wrote:
> Since IOMMU groups are mandatory for drivers to support, it stands to
> reason that any device which has been successfully added to a group
> must be on a bus supported by that IOMMU driver, and therefore a domain
> viable for any device in
On Fri, 24 Jun 2022 16:12:55 +0100
Robin Murphy wrote:
> On 2022-06-24 15:28, Alex Williamson wrote:
> > On Fri, 24 Jun 2022 11:18:36 -0300
> > Jason Gunthorpe wrote:
> >
> >> On Fri, Jun 24, 2022 at 08:11:59AM -0600, Alex Williamson wrote:
> >&
On Fri, 24 Jun 2022 11:18:36 -0300
Jason Gunthorpe wrote:
> On Fri, Jun 24, 2022 at 08:11:59AM -0600, Alex Williamson wrote:
> > On Thu, 23 Jun 2022 22:50:30 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Thu, Jun 23, 2022 at 05:00:44P
On Thu, 23 Jun 2022 22:50:30 -0300
Jason Gunthorpe wrote:
> On Thu, Jun 23, 2022 at 05:00:44PM -0600, Alex Williamson wrote:
>
> > > >> +struct vfio_device *vfio_device_get_from_iommu(struct iommu_group
> > > >> *iommu_group)
> > > &
On Thu, 23 Jun 2022 13:23:05 +0100
Robin Murphy wrote:
> On 2022-06-22 23:17, Alex Williamson wrote:
> > On Wed, 22 Jun 2022 13:04:11 +0100
> > Robin Murphy wrote:
> >
> >> Since IOMMU groups are mandatory for drivers to support, it stands to
> >>
On Thu, 23 Jun 2022 08:46:45 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Thursday, June 23, 2022 6:17 AM
> >
> > >
> > > ret = -EIO;
> > > - domain->domain = iommu_domain_alloc(bus);
> > > + domain->do
On Wed, 22 Jun 2022 13:04:11 +0100
Robin Murphy wrote:
> Since IOMMU groups are mandatory for drivers to support, it stands to
> reason that any device which has been successfully be added to a group
s/be //
> must be on a bus supported by that IOMMU driver, and therefore a domain
> viable for
On Wed, 15 Jun 2022 17:03:01 -0700
Nicolin Chen wrote:
> From: Jason Gunthorpe
>
> The KVM mechanism for controlling wbinvd is based on OR of the coherency
> property of all devices attached to a guest, no matter those devices are
> attached to a single domain or multiple domains.
>
> So, ther
On Thu, 19 May 2022 14:03:48 -0300
Jason Gunthorpe wrote:
> Since asserting dma ownership now causes the group to have its DMA blocked
> the iommu layer requires a working iommu. This means the dma_owner APIs
> cannot be used on the fake groups that VFIO creates. Test for this and
> avoid calling
On Thu, 19 May 2022 09:32:05 +0200
Joerg Roedel wrote:
> On Wed, May 18, 2022 at 04:14:46PM -0300, Jason Gunthorpe wrote:
> > Fixes: 0286300e6045 ("iommu: iommu_group_claim_dma_owner() must always
> > assign a domain")
> > Reported-by: Eric Farman
> > Signed-off-by: Jason Gunthorpe
> > ---
> >
On Tue, 10 May 2022 13:55:24 -0300
Jason Gunthorpe wrote:
> This control causes the ARM SMMU drivers to choose a stage 2
> implementation for the IO pagetable (vs the stage 1 usual default),
> however this choice has no visible impact to the VFIO user. Further qemu
> never implemented this and no
On Fri, 13 May 2022 17:49:44 +0200
Joerg Roedel wrote:
> Hi Alex,
>
> On Wed, May 04, 2022 at 10:29:56AM -0600, Alex Williamson wrote:
> > Done, and thanks for the heads-up. Please try to cc me when the
> > vfio-notifier-fix branch is merged back into your next branch. Th
On Tue, 5 Apr 2022 13:11:54 +0100
Robin Murphy wrote:
> IOMMU groups have been mandatory for some time now, so a device without
> one is necessarily a device without any usable IOMMU, therefore the
> iommu_present() check is redundant (or at best unhelpful).
>
> Signed-off-by: Robin Murphy
> -
On Wed, 4 May 2022 10:42:07 +0200
Joerg Roedel wrote:
> On Mon, May 02, 2022 at 12:12:04PM -0400, Qian Cai wrote:
> > Reverting this series fixed an user-after-free while doing SR-IOV.
> >
> > BUG: KASAN: use-after-free in __lock_acquire
>
> Hrm, okay. I am going exclude this series from my
On Fri, 29 Apr 2022 05:45:20 +
"Tian, Kevin" wrote:
> > From: Joao Martins
> > 3) Unmapping an IOVA range while returning its dirty bit prior to
> > unmap. This case is specific for non-nested vIOMMU case where an
> > erronous guest (or device) DMAing to an address being unmapped at the
> >
On Fri, 8 Apr 2022 10:59:22 -0500
Bjorn Helgaas wrote:
> On Fri, Apr 08, 2022 at 05:37:16PM +0200, Joerg Roedel wrote:
> > On Fri, Apr 08, 2022 at 11:17:47AM -0300, Jason Gunthorpe wrote:
> > > You might consider using a linear tree instead of the topic branches,
> > > topics are tricky and I'm
E_COHERENCY))
> + return -EINVAL;
> +
> return __vfio_register_dev(device,
> vfio_group_find_or_alloc(device->dev));
> }
Acked-by: Alex Williamson
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
er_noncoherent_dma().
I think this last sentence is alluding to it, but I wish the user
visible change to VFIO_DMA_CC_IOMMU on non-x86 were more explicit.
Perhaps for the last sentence:
No other archs implement kvm_arch_register_noncoherent_dma() nor are
there any other known consumers of VFIO_DMA_CC_IOMM
On Thu, 7 Apr 2022 12:23:31 -0300
Jason Gunthorpe wrote:
> On Thu, Apr 07, 2022 at 04:17:11PM +0100, Robin Murphy wrote:
>
> > For the specific case of overriding PCIe No Snoop (which is more problematic
> > from an Arm SMMU PoV) when assigning to a VM, would that not be easier
> > solved by jus
On Tue, 5 Apr 2022 13:16:02 -0300
Jason Gunthorpe wrote:
> This new mechanism will replace using IOMMU_CAP_CACHE_COHERENCY and
> IOMMU_CACHE to control the no-snoop blocking behavior of the IOMMU.
>
> Currently only Intel and AMD IOMMUs are known to support this
> feature. They both implement i
On Tue, 5 Apr 2022 13:16:01 -0300
Jason Gunthorpe wrote:
> dev_is_dma_coherent() is the control to determine if IOMMU_CACHE can be
> supported.
>
> IOMMU_CACHE means that normal DMAs do not require any additional coherency
> mechanism and is the basic uAPI that VFIO exposes to userspace. For
>
On Wed, 30 Mar 2022 14:18:47 +
"Tian, Kevin" wrote:
> +Alex
>
> > From: Tian, Kevin
> > Sent: Wednesday, March 30, 2022 10:13 PM
> >
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, March 30, 2022 7:58 PM
> > >
> > > On Wed, Mar 30, 2022 at 06:50:11AM +, Tian, Kevin wrote:
> > >
>
be able to do kernel patch testing.
>
>
> Alex Williamson scribed the following, on or around Fri, Mar 25, 2022 at
> 04:10:22PM -0600:
> > Hi Daniel,
> >
> ...
> >
> > Coherency possibly.
> >
> > There's a possible coherency issue at the
On Mon, 28 Mar 2022 16:47:49 -0300
Jason Gunthorpe wrote:
> On Mon, Mar 28, 2022 at 03:57:53PM -0300, Jason Gunthorpe wrote:
>
> > So, currently AMD and Intel have exactly the same HW feature with a
> > different kAPI..
>
> I fixed it like below and made the ordering changes Kevin pointed
> t
On Thu, 24 Mar 2022 10:46:22 -0300
Jason Gunthorpe wrote:
> On Thu, Mar 24, 2022 at 07:25:03AM +, Tian, Kevin wrote:
>
> > Based on that here is a quick tweak of the force-snoop part (not compiled).
> >
>
> I liked your previous idea better, that IOMMU_CAP_CACHE_COHERENCY
> started out O
Hi Daniel,
On Fri, 25 Mar 2022 13:06:40 -0700
"Daniel F. Smith" wrote:
> This email is to document an insidious (incorrect data, no error or warning)
> VFIO bug found when using the Intel IOMMU to perform DMA transfers; and the
> associated workaround.
>
> There may be security implications (un
On Thu, 24 Mar 2022 19:27:39 -0300
Jason Gunthorpe wrote:
> On Thu, Mar 24, 2022 at 02:40:15PM -0600, Alex Williamson wrote:
> > On Tue, 22 Mar 2022 13:15:21 -0300
> > Jason Gunthorpe via iommu wrote:
> >
> > > On Tue, Mar 22, 2022 at 09:29:23A
On Wed, 23 Mar 2022 21:33:42 -0300
Jason Gunthorpe wrote:
> On Wed, Mar 23, 2022 at 04:51:25PM -0600, Alex Williamson wrote:
>
> > My overall question here would be whether we can actually achieve a
> > compatibility interface that has sufficient feature transparency that we
On Tue, 22 Mar 2022 13:15:21 -0300
Jason Gunthorpe via iommu wrote:
> On Tue, Mar 22, 2022 at 09:29:23AM -0600, Alex Williamson wrote:
>
> > I'm still picking my way through the series, but the later compat
> > interface doesn't mention this difference as an outstan
On Fri, 18 Mar 2022 14:27:36 -0300
Jason Gunthorpe wrote:
> iommufd can directly implement the /dev/vfio/vfio container IOCTLs by
> mapping them into io_pagetable operations. Doing so allows the use of
> iommufd by symliking /dev/vfio/vfio to /dev/iommufd. Allowing VFIO to
> SET_CONTAINER using a
On Wed, 23 Mar 2022 16:34:39 -0300
Jason Gunthorpe wrote:
> On Wed, Mar 23, 2022 at 01:10:38PM -0600, Alex Williamson wrote:
> > On Fri, 18 Mar 2022 14:27:33 -0300
> > Jason Gunthorpe wrote:
> >
> > > +static int conv_iommu_prot(u32 map_flags)
&
On Fri, 18 Mar 2022 14:27:33 -0300
Jason Gunthorpe wrote:
> +static int conv_iommu_prot(u32 map_flags)
> +{
> + int iommu_prot;
> +
> + /*
> + * We provide no manual cache coherency ioctls to userspace and most
> + * architectures make the CPU ops for cache flushing privileged.
On Fri, 18 Mar 2022 14:27:35 -0300
Jason Gunthorpe wrote:
> +/**
> + * iommufd_bind_pci_device - Bind a physical device to an iommu fd
> + * @fd: iommufd file descriptor.
> + * @pdev: Pointer to a physical PCI device struct
> + * @id: Output ID number to return to userspace for this device
> + *
>
On Fri, 18 Mar 2022 14:27:32 -0300
Jason Gunthorpe wrote:
> +/*
> + * The area takes a slice of the pages from start_bytes to start_byte +
> length
> + */
> +static struct iopt_area *
> +iopt_alloc_area(struct io_pagetable *iopt, struct iopt_pages *pages,
> + unsigned long iova, unsig
On Tue, 22 Mar 2022 11:57:41 -0300
Jason Gunthorpe wrote:
> On Tue, Mar 22, 2022 at 03:28:22PM +0100, Niklas Schnelle wrote:
> > On Fri, 2022-03-18 at 14:27 -0300, Jason Gunthorpe wrote:
> > >
> > > user->locked_vm is the correct accounting to use for ulimit because it is
> > > per-user, and t
On Mon, 14 Mar 2022 15:44:34 -0400
Matthew Rosato wrote:
> s390x will introduce a new IOMMU domain type where the mappings are
> managed by KVM rather than in response to userspace mapping ioctls. Allow
> for specifying this type on the VFIO_SET_IOMMU ioctl and triggering the
> appropriate iommu
removes the iommu group notifer which contains BUG_ON() and WARN().
>
> Signed-off-by: Lu Baolu
> Reviewed-by: Jason Gunthorpe
> ---
> drivers/vfio/vfio.c | 147
> 1 file changed, 147 dele
ned-off-by: Jason Gunthorpe
> Signed-off-by: Lu Baolu
> ---
> drivers/vfio/vfio.c | 74 ++-------
> 1 file changed, 2 insertions(+), 72 deletions(-)
Acked-by: Alex Williamson
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
tus.
>
> Signed-off-by: Lu Baolu
> Reviewed-by: Jason Gunthorpe
> ---
> drivers/vfio/vfio.c | 18 ++
> 1 file changed, 6 insertions(+), 12 deletions(-)
Acked-by: Alex Williamson
___
iommu mailing list
iommu@lists.lin
Gunthorpe
> ---
> drivers/vfio/fsl-mc/vfio_fsl_mc.c | 1 +
> drivers/vfio/pci/vfio_pci.c | 1 +
> drivers/vfio/platform/vfio_amba.c | 1 +
> drivers/vfio/platform/vfio_platform.c | 1 +
> drivers/vfio/vfio.c
On Fri, 18 Feb 2022 08:55:20 +0800
Lu Baolu wrote:
> The iommu core and driver core have been enhanced to avoid unsafe driver
> binding to a live group after iommu_group_set_dma_owner(PRIVATE_USER)
> has been called. There's no need to register iommu group notifier. This
> removes the iommu group
page, then our next pfn should be calculated from level_pfn
rather than our working pfn.
Fixes: 3f34f1259776 ("iommu/vt-d: Implement map/unmap_pages() iommu_ops
callback")
Reported-by: Ajay Garg
Link: https://lore.kernel.org/all/20211002124012.18186-1-ajaygargn...@gmail.com/
Signe
Hi Baolu,
Have you looked into this? I'm able to reproduce by starting and
destroying an assigned device VM several times. It seems like it came
in with Joerg's pull request for the v5.15 merge window. Bisecting
lands me on 3f34f1259776 where intel-iommu added map/unmap_pages
support, but I'm
On Mon, 11 Oct 2021 11:49:33 +0530
Ajay Garg wrote:
> The flooding was seen today again, after I booted the host-machine in
> the morning.
> Need to look what the heck is going on ...
>
> On Sun, Oct 10, 2021 at 11:45 AM Ajay Garg wrote:
> >
> > > I'll try and backtrack to the userspace proce
On Sat, 2 Oct 2021 22:48:24 +0530
Ajay Garg wrote:
> Thanks Lu for the reply.
>
> >
> > Isn't the domain should be switched from a default domain to an
> > unmanaged domain when the device is assigned to the guest?
> >
> > Even you want to r-setup the same mappings, you need to un-map all
> > ex
On Wed, 29 Sep 2021 12:08:59 +1000
David Gibson wrote:
> On Sun, Sep 19, 2021 at 02:38:30PM +0800, Liu Yi L wrote:
> > This patch introduces a new interface (/dev/vfio/devices/$DEVICE) for
> > userspace to directly open a vfio device w/o relying on container/group
> > (/dev/vfio/$GROUP). Anything
On Wed, 22 Sep 2021 22:34:42 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Thursday, September 23, 2021 4:11 AM
> >
> > On Wed, 22 Sep 2021 09:22:52 -0300
> > Jason Gunthorpe wrote:
> >
> > > On W
On Sun, 19 Sep 2021 14:38:38 +0800
Liu Yi L wrote:
> +struct iommu_device_info {
> + __u32 argsz;
> + __u32 flags;
> +#define IOMMU_DEVICE_INFO_ENFORCE_SNOOP (1 << 0) /* IOMMU enforced
> snoop */
Is this too PCI specific, or perhaps too much of the mechanism rather
than the res
On Wed, 22 Sep 2021 01:19:08 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Wednesday, September 22, 2021 5:09 AM
> >
> > On Tue, 21 Sep 2021 13:40:01 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Sun, Sep 19, 2021 at
On Tue, 21 Sep 2021 14:29:39 -0300
Jason Gunthorpe wrote:
> On Sun, Sep 19, 2021 at 02:38:36PM +0800, Liu Yi L wrote:
> > +struct vfio_device_iommu_bind_data {
> > + __u32 argsz;
> > + __u32 flags;
> > + __s32 iommu_fd;
> > + __u64 dev_cookie;
>
> Missing explicit padding
>
>
On Wed, 22 Sep 2021 09:22:52 -0300
Jason Gunthorpe wrote:
> On Wed, Sep 22, 2021 at 09:23:34AM +, Tian, Kevin wrote:
>
> > > Providing an ioctl to bind to a normal VFIO container or group might
> > > allow a reasonable fallback in userspace..
> >
> > I didn't get this point though. An err
On Tue, 21 Sep 2021 13:40:01 -0300
Jason Gunthorpe wrote:
> On Sun, Sep 19, 2021 at 02:38:33PM +0800, Liu Yi L wrote:
> > This patch exposes the device-centric interface for vfio-pci devices. To
> > be compatiable with existing users, vfio-pci exposes both legacy group
> > interface and device-ce
On Sun, 19 Sep 2021 14:38:30 +0800
Liu Yi L wrote:
> This patch introduces a new interface (/dev/vfio/devices/$DEVICE) for
> userspace to directly open a vfio device w/o relying on container/group
> (/dev/vfio/$GROUP). Anything related to group is now hidden behind
> iommufd (more specifically in
On Mon, 30 Aug 2021 19:59:10 -0700
Nicolin Chen wrote:
> The SMMUv3 devices implemented in the Grace SoC support NVIDIA's custom
> CMDQ-Virtualization (CMDQV) hardware. Like the new ECMDQ feature first
> introduced in the ARM SMMUv3.3 specification, CMDQV adds multiple VCMDQ
> interfaces to suppl
On Tue, 13 Jul 2021 09:55:03 -0300
Jason Gunthorpe wrote:
> On Mon, Jul 12, 2021 at 11:56:24PM +, Tian, Kevin wrote:
>
> > Maybe I misunderstood your question. Are you specifically worried
> > about establishing the security context for a mdev vs. for its
> > parent?
>
> The way to think
On Mon, 12 Jul 2021 01:22:11 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Saturday, July 10, 2021 5:51 AM
> > On Fri, 9 Jul 2021 07:48:44 +
> > "Tian, Kevin" wrote:
> > > For mdev the struct device should be the poi
Hi Kevin,
A couple first pass comments...
On Fri, 9 Jul 2021 07:48:44 +
"Tian, Kevin" wrote:
> 2.2. /dev/vfio device uAPI
> ++
>
> /*
> * Bind a vfio_device to the specified IOMMU fd
> *
> * The user should provide a device cookie when calling this ioctl. The
On Mon, 28 Jun 2021 19:48:18 -0300
Jason Gunthorpe wrote:
> On Mon, Jun 28, 2021 at 04:31:45PM -0600, Alex Williamson wrote:
>
> > I'd expect that /dev/iommu will be used by multiple subsystems. All
> > will want to bind devices to address spaces, so shouldn'
On Mon, 28 Jun 2021 01:09:18 +
"Tian, Kevin" wrote:
> > From: Jason Gunthorpe
> > Sent: Friday, June 25, 2021 10:36 PM
> >
> > On Fri, Jun 25, 2021 at 10:27:18AM +, Tian, Kevin wrote:
> >
> > > - When receiving the binding call for the 1st device in a group,
> > > iommu_fd
> > >
On Fri, 18 Jun 2021 08:37:35 -0700
"Raj, Ashok" wrote:
> On Fri, Jun 18, 2021 at 12:15:06PM -0300, Jason Gunthorpe wrote:
> > On Fri, Jun 18, 2021 at 03:47:51PM +0200, Joerg Roedel wrote:
> > > Hi Kevin,
> > >
> > > On Thu, Jun 17, 2021 at 07:31:03AM +, Tian, Kevin wrote:
> > > > Now let
On Thu, 17 Jun 2021 07:31:03 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Thursday, June 17, 2021 3:40 AM
> >
> > On Wed, 16 Jun 2021 06:43:23 +
> > "Tian, Kevin" wrote:
> >
> > > > Fr
On Wed, 16 Jun 2021 06:43:23 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Wednesday, June 16, 2021 12:12 AM
> >
> > On Tue, 15 Jun 2021 02:31:39 +
> > "Tian, Kevin" wrote:
> >
> > > >
On Tue, 15 Jun 2021 01:21:35 +
"Tian, Kevin" wrote:
> > From: Jason Gunthorpe
> > Sent: Monday, June 14, 2021 9:38 PM
> >
> > On Mon, Jun 14, 2021 at 03:09:31AM +, Tian, Kevin wrote:
> >
> > > If a device can be always blocked from accessing memory in the IOMMU
> > > before it's boun
On Tue, 15 Jun 2021 02:31:39 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Tuesday, June 15, 2021 12:28 AM
> >
> [...]
> > > IOASID. Today the group fd requires an IOASID before it hands out a
> > > device_fd. With iomm
On Mon, 14 Jun 2021 11:07:11 -0300
Jason Gunthorpe wrote:
> On Sat, Jun 12, 2021 at 10:57:11AM -0600, Alex Williamson wrote:
> > On Fri, 11 Jun 2021 22:28:46 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Fri, Jun 11, 2021 at 01:38:28PM -0600, Alex Williamson
On Mon, 14 Jun 2021 03:09:31 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Saturday, June 12, 2021 5:39 AM
> >
> > On Fri, 11 Jun 2021 00:58:35 +
> > "Tian, Kevin" wrote:
> >
> > > Hi, Alex,
> > &
On Fri, 11 Jun 2021 22:28:46 -0300
Jason Gunthorpe wrote:
> On Fri, Jun 11, 2021 at 01:38:28PM -0600, Alex Williamson wrote:
>
> > That's fine for a serial port, but not a device that can do DMA.
> > The entire point of vfio is to try to provide secure, DMA capable
> &
On Fri, 11 Jun 2021 00:58:35 +
"Tian, Kevin" wrote:
> Hi, Alex,
>
> > From: Alex Williamson
> > Sent: Thursday, June 10, 2021 11:39 PM
> >
> > On Wed, 9 Jun 2021 15:49:40 -0300
> > Jason Gunthorpe wrote:
> >
> > > On
On Fri, 11 Jun 2021 13:45:29 -0300
Jason Gunthorpe wrote:
> On Thu, Jun 10, 2021 at 09:38:42AM -0600, Alex Williamson wrote:
>
> > Opening the group is not the extent of the security check currently
> > required, the group must be added to a container and an IOMMU model
>
On Wed, 9 Jun 2021 15:49:40 -0300
Jason Gunthorpe wrote:
> On Wed, Jun 09, 2021 at 10:27:22AM -0600, Alex Williamson wrote:
>
> > > > It is a kernel decision, because a fundamental task of the kernel is to
> > > > ensure isolation between user-space tas
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 Guntho
On Wed, 9 Jun 2021 10:15:32 -0600
Alex Williamson wrote:
> On Wed, 9 Jun 2021 17:51:26 +0200
> Joerg Roedel wrote:
>
> > On Wed, Jun 09, 2021 at 12:00:09PM -0300, Jason Gunthorpe wrote:
> > > Only *drivers* know what the actual device is going to do, devices do
&g
On Wed, 9 Jun 2021 17:51:26 +0200
Joerg Roedel wrote:
> On Wed, Jun 09, 2021 at 12:00:09PM -0300, Jason Gunthorpe wrote:
> > Only *drivers* know what the actual device is going to do, devices do
> > not. Since the group doesn't have drivers it is the wrong layer to be
> > making choices about how
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 kee
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 complication
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 som
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 tha
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
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 wrot
On Fri, 4 Jun 2021 09:13:37 -0300
Jason Gunthorpe wrote:
> On Thu, Jun 03, 2021 at 02:41:36PM -0600, Alex Williamson wrote:
>
> > Could you clarify "vfio_driver"?
>
> This is the thing providing the vfio_device_ops function pointers.
>
> So vfio-
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, Paolo Bonzini wrote:
> > > > I don't want a security proof myself; I want to
On Fri, 4 Jun 2021 09:19:50 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Friday, June 4, 2021 4:42 AM
> >
> > > 'qemu --allow-no-snoop' makes more sense to me
> >
> > I'd be tempted to attach it to the
[Cc +Paolo]
On Fri, 4 Jun 2021 09:28:30 -0300
Jason Gunthorpe wrote:
> On Fri, Jun 04, 2021 at 08:38:26AM +, Tian, Kevin wrote:
> > > I think more to drive the replacement design; if we can't figure out
> > > how to do something other than backwards compatibility trickery in the
> > > kernel
On Thu, 3 Jun 2021 17:10:18 -0300
Jason Gunthorpe wrote:
> On Thu, Jun 03, 2021 at 02:01:46PM -0600, Alex Williamson wrote:
>
> > > > > 1) Mixing IOMMU_CAP_CACHE_COHERENCY and !IOMMU_CAP_CACHE_COHERENCY
> > > > >domains.
> > > > >
> &g
On Thu, 3 Jun 2021 09:40:36 -0300
Jason Gunthorpe wrote:
> On Thu, Jun 03, 2021 at 03:22:27AM +, Tian, Kevin wrote:
> > > From: Alex Williamson
> > > Sent: Thursday, June 3, 2021 10:51 AM
> > >
> > > On Wed, 2 Jun 2021 19:45:36 -0300
> > >
On Thu, 3 Jun 2021 09:34:01 -0300
Jason Gunthorpe wrote:
> On Wed, Jun 02, 2021 at 08:50:54PM -0600, Alex Williamson wrote:
> > On Wed, 2 Jun 2021 19:45:36 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Wed, Jun 02, 2021 at 02:37:34PM -0600, Alex Williamson wro
On Thu, 3 Jun 2021 03:22:27 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Thursday, June 3, 2021 10:51 AM
> >
> > On Wed, 2 Jun 2021 19:45:36 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Wed, Jun 02, 2021 at 02:37:3
On Wed, 2 Jun 2021 19:45:36 -0300
Jason Gunthorpe wrote:
> On Wed, Jun 02, 2021 at 02:37:34PM -0600, Alex Williamson wrote:
>
> > Right. I don't follow where you're jumping to relaying DMA_PTE_SNP
> > from the guest page table... what page table?
>
> I
On Wed, 2 Jun 2021 16:54:04 -0300
Jason Gunthorpe wrote:
> On Wed, Jun 02, 2021 at 01:00:53PM -0600, Alex Williamson wrote:
> >
> > Right, the device can generate the no-snoop transactions, but it's the
> > IOMMU that essentially determines whether those transacti
On Wed, 2 Jun 2021 15:09:25 -0300
Jason Gunthorpe wrote:
> On Wed, Jun 02, 2021 at 12:01:11PM -0600, Alex Williamson wrote:
> > On Wed, 2 Jun 2021 14:35:10 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Wed, Jun 02, 2021 at 11:11:17A
On Wed, 2 Jun 2021 14:35:10 -0300
Jason Gunthorpe wrote:
> On Wed, Jun 02, 2021 at 11:11:17AM -0600, Alex Williamson wrote:
>
> > > > > present and be able to test if DMA for that device is cache
> > > > > coherent.
> > >
> > > Why is
On Wed, 2 Jun 2021 13:01:40 -0300
Jason Gunthorpe wrote:
> On Wed, Jun 02, 2021 at 02:20:15AM +, Tian, Kevin wrote:
> > > From: Alex Williamson
> > > Sent: Wednesday, June 2, 2021 6:22 AM
> > >
> > > On Tue, 1 Jun 2021 07:01:57 +
> >
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;
> 3) Carry device information in invalidation/fault reporting uAPI;
> 4) What
On Wed, 26 May 2021 23:40:02 +0530
Kirti Wankhede wrote:
> On 5/26/2021 4:22 AM, Alex Williamson wrote:
> > On Wed, 26 May 2021 00:56:30 +0530
> > Kirti Wankhede wrote:
> >
> >> On 5/25/2021 5:07 AM, Jason Gunthorpe wrote:
> >>> On Mon, May 24, 20
On Wed, 26 May 2021 00:56:30 +0530
Kirti Wankhede wrote:
> On 5/25/2021 5:07 AM, Jason Gunthorpe wrote:
> > On Mon, May 24, 2021 at 05:52:58PM +1000, David Gibson wrote:
> >
> I don't really see a semantic distinction between "always one-device
> groups" and "groups don't matter". R
On Fri, 21 May 2021 14:38:25 +0800
Shenming Lu wrote:
> On 2021/5/19 2:58, Alex Williamson wrote:
> > On Fri, 9 Apr 2021 11:44:17 +0800
> > Shenming Lu wrote:
> >
> >> Since enabling IOPF for devices may lead to a slow ramp up of performance,
> >> we
On Fri, 21 May 2021 14:37:21 +0800
Shenming Lu wrote:
> Hi Alex,
>
> On 2021/5/19 2:57, Alex Williamson wrote:
> > On Fri, 9 Apr 2021 11:44:12 +0800
> > Shenming Lu wrote:
> >
> >> Hi,
> >>
> >> Requesting for your comments and sug
On Fri, 21 May 2021 14:38:52 +0800
Shenming Lu wrote:
> On 2021/5/19 2:58, Alex Williamson wrote:
> > On Fri, 9 Apr 2021 11:44:14 +0800
> > Shenming Lu wrote:
> >
> >> VFIO manages the DMA mapping itself. To support IOPF (on-demand paging)
> >> for VFIO
On Mon, 24 May 2021 21:11:11 +0800
Shenming Lu wrote:
> On 2021/5/21 15:59, Shenming Lu wrote:
> > On 2021/5/19 2:58, Alex Williamson wrote:
> >> On Fri, 9 Apr 2021 11:44:20 +0800
> >> Shenming Lu wrote:
> >>
> >>> To set up nested m
1 - 100 of 1200 matches
Mail list logo
