On Wed, Jul 16, 2025 at 11:09:45AM -0700, Nicolin Chen wrote:
> OK. I see your point. That will leads to a very long list of
> parameters.
I would have some useful prebaked ones. Realistically there are not
that many combinations of HW capabilities that are
interesting/exist.
> So, a vSMMU model
On Wed, Jul 16, 2025 at 10:35:25AM -0700, Nicolin Chen wrote:
> On Wed, Jul 16, 2025 at 08:51:23AM -0300, Jason Gunthorpe wrote:
> > On Tue, Jul 15, 2025 at 07:57:57PM -0700, Nicolin Chen wrote:
> > > > +val = FIELD_EX32(s_accel->info.idr[5], IDR5, GRAN4K);
> > &
On Tue, Jul 15, 2025 at 07:57:57PM -0700, Nicolin Chen wrote:
> > +val = FIELD_EX32(s_accel->info.idr[5], IDR5, GRAN4K);
> > +if (val < FIELD_EX32(s->idr[5], IDR5, GRAN4K)) {
> > +s->idr[5] = FIELD_DP32(s->idr[5], IDR5, GRAN4K, val);
> > +}
> > +val = FIELD_EX32(s_accel->inf
On Wed, Jun 18, 2025 at 11:40:38AM +0800, Yi Liu wrote:
> Actually, as I explained in the first hunk of [1], there is no issue with
> the legacy mode support. :)
>
> [1]
> https://lore.kernel.org/qemu-devel/2025052452.3316354-1-zhenzhong.d...@intel.com/T/#m4c8fa70742001d4c22b3c297e240a2151d2
On Mon, Jun 16, 2025 at 08:14:27PM -0700, Nicolin Chen wrote:
> On Mon, Jun 16, 2025 at 08:15:11AM +, Duan, Zhenzhong wrote:
> > >IIUIC, the guest kernel cmdline can switch the mode between the
> > >stage1 (nesting) and stage2 (legacy/emulated VT-d), right?
> >
> > Right. E.g., kexec from "int
On Tue, Jun 17, 2025 at 09:03:32PM +0800, Yi Liu wrote:
> > I suggest fixing the Linux driver to refuse to run in sm_on mode if
> > the HW supports scalable mode and ecap_slts = false. That may not be
> > 100% spec compliant but it seems like a reasonable approach.
>
> running sm_on with only ecap
On Wed, Jun 04, 2025 at 02:20:23PM +0200, Cédric Le Goater wrote:
> NOTE: some trailers ignored due to from/email mismatches:
> ! Trailer: Reviewed-by: Nicolin Chen
> Msg From: Nicolin Chen via
Oh this is some some mailman dysfunction causing this :(
mailman starts mangling messages wh
On Wed, Jun 04, 2025 at 08:59:37AM +0200, Cédric Le Goater wrote:
> b4 complained for a couple of trailers :
He re-reviewed patches he contributed to making :)
> Reviewed-by: Nicolin Chen (✗ DKIM/nvidia.com)
But why do you have an X? The messages are properly formed leaving the
nvidia serv
On Wed, Mar 26, 2025 at 06:18:49PM +0100, Eric Auger wrote:
> Again I think we need to understand the consequence of having a more
> comprehensive support of SSID. This also holds with old the IDR fields
> that may be inherited from the HW and we don't support yet in the
> emulation code
To be ver
On Wed, Mar 19, 2025 at 06:26:48PM +0100, Eric Auger wrote:
> Effectively with ASID invalidation you potentially need to do both qemu
> IOTLB invalidation and host invalidation propagation.
> but this code is already in place in the code and used in vhost mode:
Let's not forget the focus here, the
On Tue, Mar 18, 2025 at 05:22:51PM -0400, Donald Dutile wrote:
> I agree with Eric that 'accel' isn't needed -- this should be
> ascertained from the pSMMU that a physical device is attached to.
I seem to remember the point was made that we don't actually know if
accel is possible, or desired, es
On Tue, Mar 18, 2025 at 07:31:36PM +0100, Eric Auger wrote:
> Nevertheless I don't think anything prevents the acceleration granted
> device from also working with virtio/vhost devices for instance unless
> you unplug the existing infra.
If the accel mode is using something like vcmdq then it is n
On Mon, Mar 17, 2025 at 12:10:19PM -0700, Nicolin Chen wrote:
> Another question: how does an emulated device work with a vSMMUv3?
> I could imagine that all the accel steps would be bypassed since
> !sdev->idev. Yet, the emulated iotlb should cache its translation
> so we will need to flush the io
On Fri, Feb 07, 2025 at 12:21:54PM +, Shameerali Kolothum Thodi wrote:
> Just wondering whether we can have something like the
> vfio_register_iommu_driver() for iommufd subsystem by which it can directly
> access iommu drivers ops(may be a restricted set).
I very much want to try hard to av
On Thu, Feb 06, 2025 at 02:46:42PM -0800, Nicolin Chen wrote:
> > You'd use the command line information and wouldn't need GET_HW_INFO,
> > it would be complicated
>
> Do you mean the "-device arm-smmuv3-accel,id=xx" line? This still
> won't give us the host IDR/IIDR register values to probe a vSM
On Thu, Feb 06, 2025 at 12:48:40PM -0800, Nicolin Chen wrote:
> On Thu, Feb 06, 2025 at 04:38:55PM -0400, Jason Gunthorpe wrote:
> > On Thu, Feb 06, 2025 at 12:33:19PM -0800, Nicolin Chen wrote:
> > > On Thu, Feb 06, 2025 at 02:22:01PM -0400, Jason Gunthorpe wrote:
> > >
On Thu, Feb 06, 2025 at 12:33:19PM -0800, Nicolin Chen wrote:
> On Thu, Feb 06, 2025 at 02:22:01PM -0400, Jason Gunthorpe wrote:
> > On Thu, Feb 06, 2025 at 06:18:14PM +, Shameerali Kolothum Thodi wrote:
> >
> > > > So even if you invent an iommu ID we cann
On Thu, Feb 06, 2025 at 06:18:14PM +, Shameerali Kolothum Thodi wrote:
> > So even if you invent an iommu ID we cannot accept it as a handle to
> > create viommu in iommufd.
>
> Creating the vIOMMU only happens when the user does a cold/hot plug of
> a VFIO device. At that time Qemu checks w
On Thu, Feb 06, 2025 at 06:04:57PM +, Shameerali Kolothum Thodi wrote:
> > Some kind of hot plug smmu would have to create a vSMMU without any
> > kernel backing and then later bind it to a kernel implementation.
>
> Not sure I get the problem with associating vSMMU with a pSMMU. Something
> l
On Thu, Feb 06, 2025 at 05:54:57PM +, Daniel P. Berrangé wrote:
> > > We shouldn't assume any VFIO device exists in the QEMU cnofig at the time
> > > we realize the virtual ssmu. I expect the SMMU may be cold plugged, while
> > > the VFIO devices may be hot plugged arbitrarly later, and we shou
On Thu, Feb 06, 2025 at 05:57:38PM +, Shameerali Kolothum Thodi wrote:
> Also how do we do it with multiple VF devices under a pSUMMU ? Which
> cdev fd in that case?
It doesn't matter, they are all interchangeable. Creating the VIOMMU
object just requires any vfio device that is attached to
On Thu, Feb 06, 2025 at 05:10:32PM +, Daniel P. Berrangé wrote:
> On Thu, Feb 06, 2025 at 01:02:38PM -0400, Jason Gunthorpe wrote:
> > On Thu, Feb 06, 2025 at 03:07:06PM +, Shameerali Kolothum Thodi wrote:
> > > > If we set the physical/guest SMMU relationship
On Thu, Feb 06, 2025 at 03:07:06PM +, Shameerali Kolothum Thodi wrote:
> > If we set the physical/guest SMMU relationship directly, then at the
> > time the VFIO device is plugged, we can diagnose the incorrectly
> > placed VFIO device, and better reason about behaviour.
>
> Agree.
Can you ju
On Fri, Jan 31, 2025 at 02:39:53PM +, Shameerali Kolothum Thodi wrote:
> > > And Qemu does some checking to make sure that the device is indeed
> > associated
> > > with the specified phys-smmuv3. This can be done going through the
> > sysfs path checking
> > > which is what I guess libvirt i
On Fri, Jan 31, 2025 at 09:33:16AM +, Shameerali Kolothum Thodi wrote:
> And Qemu does some checking to make sure that the device is indeed associated
> with the specified phys-smmuv3. This can be done going through the sysfs
> path checking
> which is what I guess libvirt is currently doing
On Mon, Jan 20, 2025 at 01:57:36PM +0100, David Hildenbrand wrote:
> > I don't want to overload those APIs, I prefer to see a new API that is
> > just about splitting areas. Splitting is a special operation that can
> > fail depending on driver support.
>
> So we'd just always perform a split-befo
On Wed, Jan 15, 2025 at 02:39:55PM +1100, Alexey Kardashevskiy wrote:
> > The thread was talking about the built-in support in iommufd to split
> > mappings.
>
> Just to clarify - I am talking about splitting only "iommufd areas", not
> large pages.
In generality it is the same thing as you canno
On Fri, Jan 10, 2025 at 02:45:39PM +0100, David Hildenbrand wrote:
>
> In your commit I read:
>
> "Implement the cut operation to be hitless, changes to the page table
> during cutting must cause zero disruption to any ongoing DMA. This is the
> expectation of the VFIO type 1 uAPI. Hitless requir
On Fri, Jan 10, 2025 at 09:26:02AM +0100, David Hildenbrand wrote:
> > > > > > > > > > One limitation (also discussed in the guest_memfd
> > > > > > > > > > meeting) is that VFIO expects the DMA mapping for
> > > > > > > > > > a specific IOVA to be mapped and unmapped with the
> > > > > > > > > > s
On Fri, Dec 13, 2024 at 12:00:43PM +, Daniel P. Berrangé wrote:
> On Fri, Nov 08, 2024 at 12:52:37PM +, Shameer Kolothum via wrote:
> > Hi,
> >
> > This series adds initial support for a user-creatable "arm-smmuv3-nested"
> > device to Qemu. At present the Qemu ARM SMMUv3 emulation is per
On Fri, Dec 13, 2024 at 11:58:02AM +, Daniel P. Berrangé wrote:
> Libvirt does not rquire use of pcie-switch. It supports them, but in the
> absence of app requested configs, libvirt will always just populate
> pcie-root-port devices. switches are something that has to be explicitly
> asked fo
On Wed, Dec 11, 2024 at 09:20:20AM -0800, Nicolin Chen wrote:
> On Wed, Dec 11, 2024 at 09:11:12AM -0400, Jason Gunthorpe wrote:
> > On Tue, Dec 10, 2024 at 05:28:17PM -0800, Nicolin Chen wrote:
> > > > I would ideally turn it around and provide that range information to
&
On Tue, Dec 10, 2024 at 05:28:17PM -0800, Nicolin Chen wrote:
> > I would ideally turn it around and provide that range information to
> > the kernel and totally ignore the SW_MSI reserved region once
> > userspace provides it.
>
> Hmm.. that sounds like a uAPI for vITS range..but yes..
It contro
On Tue, Dec 10, 2024 at 03:01:48PM -0800, Nicolin Chen wrote:
> Yet, here we seem to be missing a pathway between VMM and kernel
> to agree on the MSI window decided by the kernel, as this patch
> does the hard coding for a [0x800, 0x810) range.
I would ideally turn it around and provide
On Wed, Nov 27, 2024 at 08:44:47PM -0800, Nicolin Chen wrote:
> On Wed, Nov 27, 2024 at 11:29:06PM -0500, Donald Dutile wrote:
> > On 11/27/24 5:21 AM, Shameerali Kolothum Thodi wrote:
> > > > > W.r.t naming, maybe something related to "hardware-accelerated"?
> > > > >
> > > > Given that 'accel' h
On Thu, Nov 28, 2024 at 08:28:15AM +, Shameerali Kolothum Thodi wrote:
> I think if I am right Zhangfei was testing with vfio-pci device assigned on
> his vSVA
> branch. But migration with vfio device is currently explicitly blocked if
> vIOMMU is
> present.
>
> I think Joao is working on
On Wed, Nov 27, 2024 at 06:03:23PM -0500, Donald Dutile wrote:
> The association would be done via the VMM -- no different then what associates
> an assigned device to a VM today -- no hw-level (VM-)ID needed; a matter of
> exposing
> it to the VM, or not; or mapping the (virtual) CMDQ to the map
On Wed, Nov 27, 2024 at 10:21:24AM +, Shameerali Kolothum Thodi wrote:
> > For SMMUv3, NVIDIA-specific vCMDQ, it needs a parameter to state that
> > specifically,
> > since I'm concluding from reading the SMMUv3 version G.a spec, that
> > ECMDQ was added
> > to be able to assign an ECMDQ to a V
On Thu, Oct 31, 2024 at 09:09:20PM -0700, Nicolin Chen wrote:
> FWIW, Robin requested a different solution for MSI mapping [1], v.s.
> the RMR one that we have been using since Eric's work. I drafted a
> few VFIO/IOMMUFD patches for that,
I also talked to MarcZ about this at LPC and he seems wil
On Thu, Aug 15, 2024 at 10:59:05AM -0600, Alex Williamson wrote:
> > This is probably the only way to approach this, trap and emulate the
> > places in the device that program additional interrupt sources and do
> > a full MSI-like flow to set them up in the kernel.
>
> Your last sentence here se
On Tue, Aug 13, 2024 at 03:03:20PM -0600, Alex Williamson wrote:
> How does the guest know to write a remappable vector format? How does
> the guest know the host interrupt architecture? For example why would
> an aarch64 guest program an MSI vector of 0xfee... if the host is x86?
All excellent
On Mon, Aug 12, 2024 at 11:00:40AM -0600, Alex Williamson wrote:
> These devices have an embedded interrupt controller which is programmed
> with guest physical MSI address/data, which doesn't work. We need
> vfio-pci kernel support to provide a device feature which disables
> virtualization of th
On Tue, Jul 23, 2024 at 10:09:13AM +0200, Eric Auger wrote:
> > In pratice I don't know if such HW platforms even exist where different
> > IOMMU
> > instances present different value of dirty tracking, given that this is a
> > IOMMU
> > feature, rather than endpoint dependent. In x86 it's homoge
On Thu, Jul 11, 2024 at 08:48:10AM -0700, Andrea Bolognani wrote:
> IIUC having devices associated to the "correct" SMMU is only a
> requirement for optimal performance, not pure functionality, right?
> In other words, getting the association wrong will make things slower
> but they will keep work
On Tue, May 07, 2024 at 02:24:30AM +, Duan, Zhenzhong wrote:
> >On Mon, May 06, 2024 at 02:30:47AM +, Duan, Zhenzhong wrote:
> >
> >> I'm not clear how useful multiple iommufd instances support are.
> >> One possible benefit is for security? It may bring a slightly fine-grained
> >> isolati
On Mon, May 06, 2024 at 02:30:47AM +, Duan, Zhenzhong wrote:
> I'm not clear how useful multiple iommufd instances support are.
> One possible benefit is for security? It may bring a slightly fine-grained
> isolation in kernel.
No. I don't think there is any usecase, it is only harmful.
Jaso
On Fri, May 03, 2024 at 04:04:25PM +0200, Cédric Le Goater wrote:
> However, have you considered another/complementary approach which
> would be to create an host IOMMU (iommufd) backend object and a vIOMMU
> device object together for each vfio-pci device being plugged in the
> machine ?
>
> Some
On Mon, Feb 12, 2024 at 01:56:41PM +, Joao Martins wrote:
> Allow disabling hugepages to be dirty track at base page
> granularity in similar vein to vfio_type1_iommu.disable_hugepages
> but per IOAS.
No objection to this, but I just wanted to observe I didn't imagine
using this option for thi
On Mon, Feb 12, 2024 at 01:56:37PM +, Joao Martins wrote:
> There's generally two modes of operation for IOMMUFD:
>
> * The simple user API which intends to perform relatively simple things
> with IOMMUs e.g. DPDK. It generally creates an IOAS and attach to VFIO
> and mainly performs IOAS_MAP
On Tue, Jan 09, 2024 at 11:36:03AM -0800, Dan Williams wrote:
> Jason Gunthorpe wrote:
> > On Tue, Jan 09, 2024 at 06:02:03PM +0100, David Hildenbrand wrote:
> > > > Given that, an alternative proposal that I think would work
> > > > for you would be to add a &#x
On Tue, Jan 09, 2024 at 06:02:03PM +0100, David Hildenbrand wrote:
> > Given that, an alternative proposal that I think would work
> > for you would be to add a 'placeholder' memory node definition
> > in SRAT (so allow 0 size explicitly - might need a new SRAT
> > entry to avoid backwards compat i
On Thu, Nov 09, 2023 at 01:21:59PM +, Joao Martins wrote:
> On 09/11/2023 13:09, Jason Gunthorpe wrote:
> > On Thu, Nov 09, 2023 at 01:03:02PM +, Joao Martins wrote:
> >
> >>> I am not talking about mdevs; but rather the regular (non mdev) case not
> >
On Thu, Nov 09, 2023 at 01:03:02PM +, Joao Martins wrote:
> > I am not talking about mdevs; but rather the regular (non mdev) case not
> > being
> > able to use dirty tracking with autodomains hwpt allocation.
>
> ... without any vIOMMU.
Ah, well, that is troublesome isn't it..
So do we te
On Thu, Nov 09, 2023 at 12:17:35PM +, Joao Martins wrote:
>
>
> On 08/11/2023 12:48, Jason Gunthorpe wrote:
> > On Wed, Nov 08, 2023 at 07:16:52AM +, Duan, Zhenzhong wrote:
> >
> >>>> +ret = iommufd_backend
On Wed, Nov 08, 2023 at 01:25:34PM +, Duan, Zhenzhong wrote:
> >I was expecting that hwpt manipulation would be done exclusively
> >inside the device-specific vIOMMU userspace driver. Generic code paths
> >that don't have that knowledge should use the IOAS for everything
>
> Yes, this way we
On Wed, Nov 08, 2023 at 07:16:52AM +, Duan, Zhenzhong wrote:
> >> +ret = iommufd_backend_alloc_hwpt(iommufd, vbasedev->devid,
> >> + container->ioas_id, &hwpt_id);
> >> +
> >> +if (ret) {
> >> +error_setg_errno(errp, errno, "error alloc shado
On Tue, Oct 17, 2023 at 10:54:19AM -0600, Alex Williamson wrote:
> On Tue, 17 Oct 2023 12:28:30 -0300
> Jason Gunthorpe wrote:
>
> > On Tue, Oct 17, 2023 at 09:21:16AM -0600, Alex Williamson wrote:
> >
> > > Do we therefore need some programatic means for the ker
On Tue, Oct 17, 2023 at 09:21:16AM -0600, Alex Williamson wrote:
> Do we therefore need some programatic means for the kernel driver to
> expose the node configuration to userspace? What interfaces would
> libvirt like to see here? Is there an opportunity that this could
> begin to define flavor
On Sat, Oct 07, 2023 at 03:40:50AM +, Zhijian Li (Fujitsu) wrote:
> +rdma-core
>
>
> Is global variable *errno* reliable when the documentation only states
> "returns 0 on success, or the value of errno on failure (which indicates the
> failure reason)."
I think the intention of this langua
On Wed, Sep 27, 2023 at 03:03:09PM +, Vikram Sethi wrote:
> > From: Alex Williamson
> > Sent: Wednesday, September 27, 2023 9:25 AM
> > To: Jason Gunthorpe
> > Cc: Jonathan Cameron ; Ankit Agrawal
> > ; David Hildenbrand ; Cédric Le
> > Goater ; shan
On Wed, Sep 27, 2023 at 12:33:18PM +0100, Jonathan Cameron wrote:
> CXL accelerators / GPUs etc are a different question but who has one
> of those anyway? :)
That's exactly what I mean when I say CXL will need it too. I keep
describing this current Grace & Hopper as pre-CXL HW. You can easially
On Mon, Sep 25, 2023 at 03:53:51PM +0100, Jonathan Cameron wrote:
> On Mon, 25 Sep 2023 11:03:28 -0300
> Jason Gunthorpe wrote:
>
> > On Mon, Sep 25, 2023 at 02:54:40PM +0100, Jonathan Cameron wrote:
> >
> > > Possible the ASWG folk would say this is fine and I&
On Mon, Sep 25, 2023 at 02:54:40PM +0100, Jonathan Cameron wrote:
> Possible the ASWG folk would say this is fine and I'm reading too much into
> the spec, but I'd definitely suggest asking them via the appropriate path,
> or throwing in a code first proposal for a comment on this special case and
On Wed, Sep 20, 2023 at 12:17:24PM -0600, Alex Williamson wrote:
> > The iommufd design requires one open of the /dev/iommu to be shared
> > across all the vfios.
>
> "requires"? It's certainly of limited value to have multiple iommufd
> instances rather than create multiple address spaces withi
On Wed, Sep 20, 2023 at 12:01:42PM -0600, Alex Williamson wrote:
> On Wed, 20 Sep 2023 03:42:20 +
> "Duan, Zhenzhong" wrote:
>
> > >-Original Message-
> > >From: Cédric Le Goater
> > >Sent: Wednesday, September 20, 2023 1:08 AM
> > >Subject: Re: [PATCH v1 15/22] Add iommufd configure
On Wed, Sep 20, 2023 at 07:37:53PM +0200, Eric Auger wrote:
> >> qemu will typically not be able to
> >> self-open /dev/iommufd as it is root-only.
> >
> > I don't understand, we open multiple fds to KVM devices. This is the
> > same.
> Actually qemu opens the /dev/iommu in case no fd is passed al
On Wed, Sep 20, 2023 at 01:39:02PM +0100, Daniel P. Berrangé wrote:
> > diff --git a/util/chardev_open.c b/util/chardev_open.c
> > new file mode 100644
> > index 00..d03e415131
> > --- /dev/null
> > +++ b/util/chardev_open.c
> > @@ -0,0 +1,61 @@
> > +/*
> > + * Copyright (C) 2023 Intel Cor
On Wed, Sep 20, 2023 at 02:19:42PM +0200, Cédric Le Goater wrote:
> On 9/20/23 05:42, Duan, Zhenzhong wrote:
> >
> >
> > > -Original Message-
> > > From: Cédric Le Goater
> > > Sent: Wednesday, September 20, 2023 1:08 AM
> > > Subject: Re: [PATCH v1 15/22] Add iommufd configure option
>
On Wed, Sep 20, 2023 at 02:01:39PM +0100, Daniel P. Berrangé wrote:
> Assuming we must have the exact same FD used for all vfio-pci devices,
> then using -object iommufd is the least worst way to get that FD
> injected into QEMU from libvirt.
Yes, same FD. It is a shared resource.
Jason
On Mon, Sep 18, 2023 at 02:23:48PM +0200, Cédric Le Goater wrote:
> On 9/18/23 13:51, Jason Gunthorpe wrote:
> > On Fri, Sep 15, 2023 at 02:42:48PM +0200, Cédric Le Goater wrote:
> > > On 8/30/23 12:37, Zhenzhong Duan wrote:
> > > > Hi All,
> > > >
>
On Fri, Sep 15, 2023 at 02:42:48PM +0200, Cédric Le Goater wrote:
> On 8/30/23 12:37, Zhenzhong Duan wrote:
> > Hi All,
> >
> > As the kernel side iommufd cdev and hot reset feature have been queued,
> > also hwpt alloc has been added in Jason's for_next branch [1], I'd like
> > to update a new ve
On Wed, Sep 06, 2023 at 01:09:26PM -0600, Alex Williamson wrote:
> On Wed, 6 Sep 2023 15:10:39 -0300
> Jason Gunthorpe wrote:
>
> > On Wed, Aug 30, 2023 at 06:37:53PM +0800, Zhenzhong Duan wrote:
> > > Note the /dev/iommu device may have been pre-opened by a
> > >
On Wed, Aug 30, 2023 at 06:37:53PM +0800, Zhenzhong Duan wrote:
> Note the /dev/iommu device may have been pre-opened by a
> management tool such as libvirt. This mode is no more considered
> for the legacy backend. So let's remove the "TODO" comment.
Can you show an example of that syntax too?
A
On Tue, Aug 08, 2023 at 09:23:09AM +0300, Avihai Horon wrote:
>
> On 07/08/2023 18:53, Cédric Le Goater wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > [ Adding Juan and Peter for their awareness ]
> >
> > On 8/2/23 10:14, Avihai Horon wrote:
> > > Changing the d
On Sun, Jul 16, 2023 at 11:15:35AM +0300, Avihai Horon wrote:
> Hi all,
>
> The first patch in this series adds a small optimization to VFIO
> migration by moving the STOP_COPY->STOP transition to
> vfio_save_cleanup(). Testing with a ConnectX-7 VFIO device showed that
> this can reduce downtime b
On Tue, Jun 27, 2023 at 02:21:55PM +0200, Cédric Le Goater wrote:
> We have a way to run and migrate a machine with a device not supporting
> dirty tracking. Only Hisilicon is in that case today. May be there are
> plans to add dirty tracking support ?
Hisilicon will eventually use Joao's work fo
On Mon, Jun 26, 2023 at 05:26:42PM +0200, Cédric Le Goater wrote:
> Since dirty tracking is a must-have to implement migration support
> for any existing and future VFIO PCI variant driver, anything else
> would be experimental code and we are trying to remove the flag !
> Please correct me if I a
On Thu, Jun 08, 2023 at 03:53:23PM -0400, Peter Xu wrote:
> Though that does look slightly special, because the whole empty UNMAP
> region can be seen as a hole too; not sure when that -ENOENT will be useful
> if qemu should always bypass it anyway. Indeed not a problem to qemu.
It sounds like it
On Thu, Jun 08, 2023 at 11:40:55AM -0400, Peter Xu wrote:
> > But if there is the proper locks to prevent a map/unmap race, then
> > there should also be the proper locks to check that there is no map in
> > the first place and avoid the kernel call..
>
> The problem is IIRC guest iommu driver ca
On Thu, Jun 08, 2023 at 10:05:08AM -0400, Peter Xu wrote:
> IIUC what VFIO does here is it returns succeed if unmap over nothing rather
> than failing like iommufd. Curious (like JasonW) on why that retval? I'd
> assume for returning "how much unmapped" we can at least still return 0 for
> nothi
On Fri, May 26, 2023 at 08:44:29AM +, Liu, Yi L wrote:
> > > >> In fact, the other purpose of this patch is to eliminate noisy error
> > > >> log when we work with IOMMUFD. It looks the duplicate UNMAP call will
> > > >> fail with IOMMUFD while always succeed with legacy container. This
> > >
On Thu, May 18, 2023 at 03:45:24PM -0400, Peter Xu wrote:
> On Thu, May 18, 2023 at 11:56:46AM -0300, Jason Gunthorpe wrote:
> > On Thu, May 18, 2023 at 10:16:24AM -0400, Peter Xu wrote:
> >
> > > What you mentioned above makes sense to me from the POV that 1 vIOMMU ma
On Thu, May 18, 2023 at 10:16:24AM -0400, Peter Xu wrote:
> What you mentioned above makes sense to me from the POV that 1 vIOMMU may
> not suffice, but that's at least totally new area to me because I never
> used >1 IOMMUs even bare metal (excluding the case where I'm aware that
> e.g. a GPU cou
On Tue, May 16, 2023 at 02:35:21PM +, Shameerali Kolothum Thodi wrote:
> Ok. Got it. So it depends on what SMMU does for that mapping and is not
> related to migration per se and has the potential to crash the system if
> SMMU go ahead with that memory access. Isn't it a more generic problem
On Tue, May 16, 2023 at 01:57:22PM +, Shameerali Kolothum Thodi wrote:
> > What happens on your platform if a guest tries to do P2P? Does the
> > platform crash?
>
> I am not sure. Since the devices are behind SMMU, I was under the assumption
> that we do have the guarantee of isolation here(
On Tue, May 16, 2023 at 10:03:54AM +, Shameerali Kolothum Thodi wrote:
> > Currently VFIO migration doesn't implement some kind of intermediate
> > quiescent state in which P2P DMAs are quiesced before stopping or
> > running the device. This can cause problems in multi-device migration
> > wh
On Wed, Mar 01, 2023 at 03:39:17PM -0700, Alex Williamson wrote:
> On Wed, 1 Mar 2023 17:12:51 -0400
> Jason Gunthorpe wrote:
>
> > On Wed, Mar 01, 2023 at 12:55:59PM -0700, Alex Williamson wrote:
> >
> > > So it seems like what we need here is both a preface
On Wed, Mar 01, 2023 at 12:55:59PM -0700, Alex Williamson wrote:
> So it seems like what we need here is both a preface buffer size and a
> target device latency. The QEMU pre-copy algorithm should factor both
> the remaining data size and the device latency into deciding when to
> transition to
On Mon, Feb 27, 2023 at 09:14:44AM -0700, Alex Williamson wrote:
> But we have no requirement to send all init_bytes before stop-copy.
> This is a hack to achieve a theoretical benefit that a driver might be
> able to improve the latency on the target by completing another
> iteration.
I think th
On Fri, Feb 24, 2023 at 12:53:26PM +, Joao Martins wrote:
> > But reading the code this ::bypass_iommu (new to me) apparently tells that
> > vIOMMU is bypassed or not for the PCI devices all the way to avoiding
> > enumerating in the IVRS/DMAR ACPI tables. And I see VFIO double-checks
> > whet
On Thu, Feb 23, 2023 at 03:33:09PM -0700, Alex Williamson wrote:
> On Thu, 23 Feb 2023 16:55:54 -0400
> Jason Gunthorpe wrote:
>
> > On Thu, Feb 23, 2023 at 01:06:33PM -0700, Alex Williamson wrote:
> > > > #2 is the presumption that the guest is using an identity ma
On Thu, Feb 23, 2023 at 01:06:33PM -0700, Alex Williamson wrote:
> > #2 is the presumption that the guest is using an identity map.
>
> This is a dangerous assumption.
>
> > > I'd think the only viable fallback if the vIOMMU doesn't report its max
> > > IOVA is the full 64-bit address space, othe
On Thu, Feb 23, 2023 at 01:16:40PM -0700, Alex Williamson wrote:
> On Thu, 23 Feb 2023 15:30:28 -0400
> Jason Gunthorpe wrote:
>
> > On Thu, Feb 23, 2023 at 12:27:23PM -0700, Alex Williamson wrote:
> > > So again, I think I'm just looking for a better comment that
On Thu, Feb 23, 2023 at 12:27:23PM -0700, Alex Williamson wrote:
> So again, I think I'm just looking for a better comment that doesn't
> add FUD to the reasoning behind switching to a single range,
It isn't a single range, it is a single page of ranges, right?
The comment should say
"Keep the
On Wed, Feb 22, 2023 at 04:34:39PM -0700, Alex Williamson wrote:
> > +/*
> > + * With vIOMMU we try to track the entire IOVA space. As the IOVA
> > space can
> > + * be rather big, devices might not be able to track it due to HW
> > + * limitations. In that case:
> > + * (1) Re
On Wed, Feb 22, 2023 at 03:40:43PM -0700, Alex Williamson wrote:
> > +/*
> > + * DMA logging uAPI guarantees to support at least num_ranges that
> > fits into
> > + * a single host kernel page. To be on the safe side, use this as a
> > limit
> > + * from which to merge to a single
On Wed, Feb 15, 2023 at 01:14:35PM -0700, Alex Williamson wrote:
> We'll need to consider whether we want to keep "dumb" dirty tracking,
> or even any form of dirty tracking in the type1 uAPI, under an
> experimental opt-in. Thanks,
I was expecting we'd delete the kernel code for type 1 dirty tr
On Fri, Feb 03, 2023 at 06:57:02PM +0100, Eric Auger wrote:
> Hi Jason,
>
> On 2/3/23 13:51, Jason Gunthorpe wrote:
> > On Tue, Jan 31, 2023 at 09:53:05PM +0100, Eric Auger wrote:
> >> Now we support two types of iommu backends, let's add the capability
> >>
On Tue, Jan 31, 2023 at 09:52:47PM +0100, Eric Auger wrote:
> Given some iommufd kernel limitations, the iommufd backend is
> not yuet fully on par with the legacy backend w.r.t. features like:
> - p2p mappings (you will see related error traces)
> - coherency tracking
You said this was a qemu sid
On Tue, Jan 31, 2023 at 09:53:05PM +0100, Eric Auger wrote:
> Now we support two types of iommu backends, let's add the capability
> to select one of them. This depends on whether an iommufd object has
> been linked with the vfio-pci device:
>
> if the user wants to use the legacy backend, it shal
1 - 100 of 164 matches
Mail list logo
