> From: Alex Williamson
> Sent: Friday, January 26, 2024 5:20 AM
>
> On Thu, 25 Jan 2024 09:18:02 +0100
> Eric Auger wrote:
>
> > Hi Vivek,
> >
> > On 1/18/24 20:20, Vivek Kasireddy wrote:
> > >
> > > +if (iommu_phys_bits && phys_bits > iommu_phys_bits) {
> > > +phys_bits =
> From: Jason Gunthorpe
> Sent: Thursday, September 21, 2023 2:20 AM
>
> 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
> From: Jason Gunthorpe
> Sent: Friday, May 19, 2023 4:19 AM
>
> On Thu, May 18, 2023 at 03:45:24PM -0400, Peter Xu wrote:
>
> > I see that Intel is already copied here (at least Yi and Kevin) so I assume
> > there're already some kind of synchronizations on multi-vIOMMU vs recent
> > works on
> From: Jason Gunthorpe
> Sent: Thursday, May 18, 2023 10:57 PM
>
> 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
Hi, Alex,
> From: Alex Williamson
> Sent: Thursday, June 2, 2022 2:01 AM
>
> On Wed, 1 Jun 2022 17:09:25 +
> "Dong, Eddie" wrote:
>
> > > -Original Message-
> > > From: Qemu-devel > > bounces+eddie.dong=intel@nongnu.org> On Behalf Of Alex
> Williamson
> > > On Tue, 24 May
> From: Daniel P. Berrangé
> Sent: Friday, April 29, 2022 12:20 AM
>
> On Thu, Apr 28, 2022 at 08:24:48AM -0600, Alex Williamson wrote:
> > On Thu, 28 Apr 2022 03:21:45 +0000
> > "Tian, Kevin" wrote:
> >
> > > > From: Alex Williams
> From: Alex Williamson
> Sent: Wednesday, April 27, 2022 12:22 AM
> > >
> > > My expectation would be that libvirt uses:
> > >
> > > -object iommufd,id=iommufd0,fd=NNN
> > > -device vfio-pci,fd=MMM,iommufd=iommufd0
> > >
> > > Whereas simple QEMU command line would be:
> > >
> > > -object
> From: Liu, Yi L
> Sent: Tuesday, April 26, 2022 5:55 PM
> On 2022/4/22 22:58, Jason Gunthorpe wrote:
> > On Thu, Apr 14, 2022 at 03:47:07AM -0700, Yi Liu wrote:
> >
> >> +
> >> +/* try to attach to an existing container in this space */
> >> +QLIST_FOREACH(bcontainer, >containers, next)
> From: Eric Auger
> Sent: Tuesday, April 26, 2022 3:55 AM
>
> Hi Kevin,
>
> On 4/18/22 10:49 AM, Tian, Kevin wrote:
> >> From: Liu, Yi L
> >> Sent: Thursday, April 14, 2022 6:47 PM
> >>
> >> This series qomifies the VFIOContainer object
> From: Alex Williamson
> Sent: Monday, April 25, 2022 10:38 PM
>
> On Mon, 25 Apr 2022 11:10:14 +0100
> Daniel P. Berrangé wrote:
>
> > On Fri, Apr 22, 2022 at 04:09:43PM -0600, Alex Williamson wrote:
> > > [Cc +libvirt folks]
> > >
> > > On Thu, 14 Apr 2022 03:46:52 -0700
> > > Yi Liu
> From: Liu, Yi L
> Sent: Thursday, April 14, 2022 6:47 PM
>
> With the introduction of iommufd[1], the linux kernel provides a generic
> interface for userspace drivers to propagate their DMA mappings to kernel
> for assigned devices. This series does the porting of the VFIO devices
> onto the
> From: Jason Wang
> Sent: Wednesday, April 6, 2022 11:33 AM
> To: Tian, Kevin
> Cc: Liu, Yi L ; m...@redhat.com; pet...@redhat.com;
> yi.y@linux.intel.com; qemu-devel@nongnu.org
> Subject: Re: [PATCH V2 1/4] intel-iommu: don't warn guest errors when
> getting rid2pa
> From: Jason Wang
> Sent: Wednesday, March 30, 2022 4:37 PM
> On Wed, Mar 30, 2022 at 4:16 PM Tian, Kevin wrote:
> >
> > > From: Jason Wang
> > > Sent: Tuesday, March 29, 2022 12:52 PM
> > > >
> > > >>>
> > >
> From: Jason Wang
> Sent: Wednesday, March 30, 2022 4:32 PM
>
> >
> > >
> > > > If there is certain fault
> > > > triggered by a request with PASID, we do want to report this
> information
> > > > upward.
> > >
> > > I tend to do it increasingly on top of this series (anyhow at least
> > >
> From: Jason Wang
> Sent: Wednesday, March 30, 2022 4:32 PM
>
> On Wed, Mar 30, 2022 at 4:02 PM Tian, Kevin wrote:
> >
> > > From: Jason Wang
> > > Sent: Tuesday, March 29, 2022 12:49 PM
> > >
> > > On Mon, Mar 28, 2022 at 3:03 PM Ti
> From: Jason Wang
> Sent: Tuesday, March 29, 2022 12:52 PM
> >
> >>>
> >>> Currently the implementation of vtd_ce_get_rid2pasid_entry() is also
> >>> problematic. According to VT-d spec, RID2PASID field is effective only
> >>> when ecap.rps is true otherwise PASID#0 is used for RID2PASID. I
> From: Jason Wang
> Sent: Tuesday, March 29, 2022 12:49 PM
>
> On Mon, Mar 28, 2022 at 3:03 PM Tian, Kevin wrote:
> >
> > > From: Jason Wang
> > > Sent: Monday, March 21, 2022 1:54 PM
> > >
> > > +/*
> > > + * vtd-spec v3
> From: Jason Wang
> Sent: Tuesday, March 29, 2022 12:47 PM
>
> On Mon, Mar 28, 2022 at 2:47 PM Tian, Kevin wrote:
> >
> > > From: Jason Wang
> > > Sent: Monday, March 28, 2022 10:31 AM
> > >
> > > On Thu, Mar 24, 2022 at 4:54 PM Ti
> From: Jason Wang
> Sent: Monday, March 21, 2022 1:54 PM
>
> +/*
> + * vtd-spec v3.4 3.14:
> + *
> + * """
> + * Requests-with-PASID with input address in range 0xFEEx_ are
> + * translated normally like any other request-with-PASID through
> + * DMA-remapping
> From: Jason Wang
> Sent: Monday, March 28, 2022 10:31 AM
>
> On Thu, Mar 24, 2022 at 4:54 PM Tian, Kevin wrote:
> >
> > > From: Jason Wang
> > > Sent: Monday, March 21, 2022 1:54 PM
> > >
> > > This patch introduce ECAP_PASID v
> From: Jason Wang
> Sent: Monday, March 21, 2022 1:54 PM
>
> This patch introduce ECAP_PASID via "x-pasid-mode". Based on the
> existing support for scalable mode, we need to implement the following
> missing parts:
>
> 1) tag VTDAddressSpace with PASID and support IOMMU/DMA translation
>
> From: Jason Wang
> Sent: Monday, March 21, 2022 1:54 PM
> @@ -1724,6 +1713,19 @@ out:
> trace_vtd_pt_enable_fast_path(source_id, success);
> }
>
> +static void vtd_qualify_report_fault(IntelIOMMUState *s,
> + int err, bool is_fpd_set,
> +
> From: Jason Wang
> Sent: Monday, March 21, 2022 1:54 PM
>
> We use to warn on wrong rid2pasid entry. But this error could be
> triggered by the guest and could happens during initialization. So
> let's don't warn in this case.
>
> Signed-off-by: Jason Wang
> ---
> hw/i386/intel_iommu.c | 6
> From: Zeng, Guang
> Sent: Monday, January 10, 2022 5:47 PM
>
> On 1/10/2022 4:40 PM, Tian, Kevin wrote:
> >> From: Zhong, Yang
> >> Sent: Friday, January 7, 2022 5:32 PM
> >>
> >> From: Jing Liu
> >>
> >> Extended feature has
> From: Zhong, Yang
> Sent: Friday, January 7, 2022 5:32 PM
>
> From: Jing Liu
>
> Extended feature has large state while current
> kvm_xsave only allows 4KB. Use new XSAVE ioctls
> if the xstate size is large than kvm_xsave.
shouldn't we always use the new xsave ioctls as long as
CAP_XSAVE2
> From: Zhong, Yang
> Sent: Friday, January 7, 2022 5:32 PM
>
> From: Jing Liu
>
> Intel introduces XFD faulting mechanism for extended
> XSAVE features to dynamically enable the features in
> runtime. If CPUID (EAX=0Dh, ECX=n, n>1).ECX[2] is set
> as 1, it indicates support for XFD faulting
> From: Zhong, Yang
> Sent: Friday, January 7, 2022 5:32 PM
>
> Kernel mechanism for dynamically enabled XSAVE features
there is no definition of "dynamically-enabled XSAVE features).
> asks userspace VMM requesting guest permission if it wants
> to expose the features. Only with the
> From: Zhong, Yang
> Sent: Friday, January 7, 2022 5:31 PM
>
> From: Jing Liu
>
> AMX XTILECFG and XTILEDATA are managed by XSAVE feature
> set. State component 17 is used for 64-byte TILECFG register
> (XTILECFG state) and component 18 is used for 8192 bytes
> of tile data (XTILEDATA state).
> From: Zhong, Yang
> Sent: Friday, January 7, 2022 5:31 PM
>
> From: Jing Liu
>
> The extended state subleaves (EAX=0Dh, ECX=n, n>1).ECX[1]
> are all zero, while spec actually introduces that bit 01
> should indicate if the extended state component locates
> on the next 64-byte boundary
> From: Kunkun Jiang
> Sent: Monday, September 27, 2021 8:30 PM
>
> Hi Kevin:
>
> On 2021/9/24 14:47, Tian, Kevin wrote:
> >> From: Kunkun Jiang
> >> Sent: Friday, September 24, 2021 2:19 PM
> >>
> >> Hi all,
> >>
> >>
> From: Kirti Wankhede
> Sent: Friday, September 24, 2021 5:29 PM
>
> On 9/24/2021 12:17 PM, Tian, Kevin wrote:
> >> From: Kunkun Jiang
> >> Sent: Friday, September 24, 2021 2:19 PM
> >>
> >> Hi all,
> >>
> >> I encountered a
> From: Kunkun Jiang
> Sent: Friday, September 24, 2021 2:19 PM
>
> Hi all,
>
> I encountered a problem in vfio device migration test. The
> vCPU may be paused during vfio-pci DMA in iommu nested
> stage mode && vSVA. This may lead to migration fail and
> other problems related to device
> From: Kunkun Jiang
> Sent: Thursday, March 18, 2021 8:29 PM
>
> Hi Kevin,
>
> On 2021/3/18 17:04, Tian, Kevin wrote:
> >> From: Kunkun Jiang
> >> Sent: Thursday, March 18, 2021 3:59 PM
> >>
> >> Hi Kevin,
> >>
> >> On 2
> From: Kunkun Jiang
> Sent: Thursday, March 18, 2021 3:59 PM
>
> Hi Kevin,
>
> On 2021/3/18 14:28, Tian, Kevin wrote:
> >> From: Kunkun Jiang
> >> Sent: Wednesday, March 10, 2021 5:41 PM
> >>
> >> Hi all,
> >>
> &
> From: Kunkun Jiang
> Sent: Wednesday, March 10, 2021 5:41 PM
>
> Hi all,
>
> In the past, we clear dirty log immediately after sync dirty log to
> userspace. This may cause redundant dirty handling if userspace
> handles dirty log iteratively:
>
> After vfio clears dirty log, new dirty log
> From: Tarun Gupta (SW-GPU)
> Sent: Tuesday, March 16, 2021 9:35 PM
>
>
> >> +
> >> +* A ``save_live_iterate`` function that reads the VFIO device's data from
> the
> >> + vendor driver through the migration region during iterative phase.
> >> +
> >> +* A ``save_live_complete_precopy``
> From: Dr. David Alan Gilbert
> Sent: Tuesday, March 16, 2021 11:47 PM
>
> * Tian, Kevin (kevin.t...@intel.com) wrote:
> > > From: Qemu-devel bounces+kevin.tian=intel@nongnu.org>
> > > On Behalf Of Dr. David Alan Gilbert
> > >
> > &g
> From: Tarun Gupta
> Sent: Thursday, March 11, 2021 3:20 AM
>
> Document interfaces used for VFIO device migration. Added flow of state
> changes
> during live migration with VFIO device. Tested by building docs with the new
> vfio-migration.rst file.
>
> v2:
> - Included the new
> From: Qemu-devel
> On Behalf Of Dr. David Alan Gilbert
>
> * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > On Thu, Mar 11, 2021 at 12:50:09AM +0530, Tarun Gupta wrote:
> > > Document interfaces used for VFIO device migration. Added flow of state
> changes
> > > during live migration with
> From: Alex Williamson
> Sent: Tuesday, March 9, 2021 6:51 AM
>
> [Cc +Intel]
>
> On Mon, 8 Mar 2021 21:39:49 +0530
> Tarun Gupta wrote:
>
> > VFIO migration support in QEMU is experimental as of now, which was
> done to
> > provide soak time and resolve concerns regarding bit-stream.
> >
> From: Jean-Philippe Brucker
> Sent: Friday, February 26, 2021 9:01 PM
>
> On Fri, Feb 26, 2021 at 08:11:41AM +, Tian, Kevin wrote:
> > > From: Qemu-devel bounces+kevin.tian=intel@nongnu.org>
> > > On Behalf Of Jean-Philippe Brucker
> > >
>
> From: Qemu-devel
> On Behalf Of Jean-Philippe Brucker
>
> On Sun, Feb 21, 2021 at 06:45:18AM -0500, Michael S. Tsirkin wrote:
> > On Thu, Feb 18, 2021 at 11:59:30AM +0100, Jean-Philippe Brucker wrote:
> > > Currently the virtio-iommu device must be programmed before it allows
> > > DMA from
> From: Peter Xu
> Sent: Sunday, February 7, 2021 10:47 PM
>
> Hi, Kevin,
>
> On Sun, Feb 07, 2021 at 09:04:55AM +, Tian, Kevin wrote:
> > > From: Peter Xu
> > > Sent: Friday, February 5, 2021 11:31 PM
> > >
> > > > >
> > &g
> From: Peter Xu
> Sent: Friday, February 5, 2021 11:31 PM
>
> > >
> > >
> > >> or virtio-iommu
> > >> since dev-iotlb (or PCIe ATS)
> > >
> > >
> > > We may need to add this in the future.
> > added Jean-Philippe in CC
>
> So that's the part I'm unsure about.. Since everybody is cced so maybe
> From: Stefan Hajnoczi
> Sent: Friday, October 30, 2020 3:51 PM
>
> Hi,
> The "Scalable Work Submission in Device Virtualization" talk at KVM
> Forum 2020 was interesting and I have some beginner questions about
> ENQCMD:
> https://static.sched.com/hosted_files/kvmforum2020/22/Scalable_Work_Su
> From: Cornelia Huck
> Sent: Friday, September 11, 2020 6:08 PM
>
> On Fri, 11 Sep 2020 08:56:00 +0800
> Yan Zhao wrote:
>
> > On Thu, Sep 10, 2020 at 12:02:44PM -0600, Alex Williamson wrote:
> > > On Thu, 10 Sep 2020 13:50:11 +0100
> > > Sean Mooney wrote:
> > >
> > > > On Thu, 2020-09-10
> From: Xiang Zheng
> Sent: Wednesday, July 22, 2020 10:56 AM
>
> Hi Alex,
>
> Thank you for your suggestion.
>
> On 2020/7/22 6:43, Alex Williamson wrote:
> > On Tue, 21 Jul 2020 10:43:21 +0800
> > Xiang Zheng wrote:
> >
> >> Hi Kirti,
> >>
> >> Sorry to disturb you since this patch set has
Hi, Kirti,
Will you send out a new version in Qemu side, or previous v16 still applies?
Thanks
Kevin
> From: Kirti Wankhede
> Sent: Saturday, May 16, 2020 5:13 AM
>
> Hi,
>
> This patch set adds:
> * IOCTL VFIO_IOMMU_DIRTY_PAGES to get dirty pages bitmap with
> respect to IOMMU container
> From: Yan Zhao
> Sent: Tuesday, April 21, 2020 10:37 AM
>
> On Tue, Apr 21, 2020 at 06:56:00AM +0800, Alex Williamson wrote:
> > On Sun, 19 Apr 2020 21:24:57 -0400
> > Yan Zhao wrote:
> >
> > > On Fri, Apr 17, 2020 at 07:24:57PM +0800, Cornelia Huck wrote:
> > > > On Fri, 17 Apr 2020 05:52:02
> From: Dr. David Alan Gilbert
> Sent: Wednesday, March 25, 2020 4:23 AM
>
> * Alex Williamson (alex.william...@redhat.com) wrote:
> > On Mon, 23 Mar 2020 23:01:18 -0400
> > Yan Zhao wrote:
> >
> > > On Tue, Mar 24, 2020 at 02:51:14AM +0800, Dr. David Alan Gilbert wrote:
> > > > * Alex
> From: Jean-Philippe Brucker
> Sent: Thursday, March 5, 2020 3:34 PM
>
> On Thu, Mar 05, 2020 at 02:56:20AM +, Tian, Kevin wrote:
> > > From: Jean-Philippe Brucker
> > > Sent: Thursday, March 5, 2020 12:47 AM
> > >
> > [...]
> > >
> From: Jean-Philippe Brucker
> Sent: Thursday, March 5, 2020 12:47 AM
>
[...]
> > >
> > > * We can't use DVM in nested mode unless the VMID is shared with the
> > > CPU. For that we'll need the host SMMU driver to hook into the KVM
> VMID
> > > allocator, just like we do for the ASID allocator.
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Wednesday, November 20, 2019 7:17 AM
>
> On Fri, 15 Nov 2019 05:10:53 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Friday, November 15, 2019 11:22 AM
> From: Alex Williamson
> Sent: Friday, November 15, 2019 11:22 AM
>
> On Thu, 14 Nov 2019 21:40:35 -0500
> Yan Zhao wrote:
>
> > On Fri, Nov 15, 2019 at 05:06:25AM +0800, Alex Williamson wrote:
> > > On Fri, 15 Nov 2019 00:26:07 +0530
> > > Kirti Wankhede wrote:
> > >
> > > > On 11/14/2019
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Friday, November 1, 2019 4:10 PM
>
>
> On 2019/11/1 下午4:04, Jason Wang wrote:
> >
> > On 2019/11/1 下午3:46, Tian, Kevin wrote:
> >>> From: Jason Wang [mailto:jasow...@redhat.com]
>
[RFC v2 00/22] intel_iommu: expose Shared Virtual
> Addressing to VM
> >>
> >>
> >> On 2019/10/25 下午6:12, Tian, Kevin wrote:
> >>>> From: Jason Wang [mailto:jasow...@redhat.com]
> >>>> Sent: Friday, October 25, 2019 5:49 PM
> >>>
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Thursday, October 31, 2019 12:33 PM
>
>
> On 2019/10/25 下午6:12, Tian, Kevin wrote:
> >> From: Jason Wang [mailto:jasow...@redhat.com]
> >> Sent: Friday, October 25, 2019 5:49 PM
> >>
>
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Friday, October 25, 2019 5:49 PM
>
>
> On 2019/10/24 下午8:34, Liu Yi L wrote:
> > Shared virtual address (SVA), a.k.a, Shared virtual memory (SVM) on Intel
> > platforms allow address space sharing between device DMA and
> applications.
>
>
Sorry for late reply...
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, September 27, 2019 5:33 AM
>
> On Thu, 26 Sep 2019 03:07:08 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson [mailto:alex.william...@redhat.co
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, September 26, 2019 3:06 AM
[...]
> > > > The second point is about write-protection:
> > > >
> > > > > There is another value of recording GPA in VFIO. Vendor drivers
> > > > > (e.g. GVT-g) may need to selectively
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Wednesday, September 25, 2019 2:03 AM
>
> On Tue, 24 Sep 2019 02:19:15 +0000
> "Tian, Kevin" wrote:
>
> > > From: Tian, Kevin
> > > Sent: Friday, September 13, 20
> From: Tian, Kevin
> Sent: Friday, September 13, 2019 7:00 AM
>
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Thursday, September 12, 2019 10:41 PM
> >
> > On Tue, 3 Sep 2019 06:57:27 +
> > "Tian, Kevin" wrote:
>
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Friday, September 20, 2019 9:19 AM
>
> On 2019/9/20 上午6:54, Tian, Kevin wrote:
> >> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> >> Sent: Thursday, September 19, 2019 7:14 PM
> >>
> >> O
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Thursday, September 19, 2019 7:14 PM
>
> On 19/09/19 09:16, Tian, Kevin wrote:
> >>> why GPA1 and GPA2 should be both dirty?
> >>> even they have the same HVA due to overlaping virtual address space
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, September 20, 2019 1:21 AM
>
> On Wed, 18 Sep 2019 07:21:05 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jason Wang [mailto:jasow...@redhat.com]
> > > Sent: Wednesday, Septemb
ao wrote:
> >>> On Thu, Sep 19, 2019 at 09:05:12AM +0800, Jason Wang wrote:
> >>>> On 2019/9/18 下午4:37, Tian, Kevin wrote:
> >>>>>> From: Jason Wang [mailto:jasow...@redhat.com]
> >>>>>> Sent: Wednesday, September 18, 2019 2:10 PM
&
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Wednesday, September 18, 2019 2:10 PM
>
> >>
> >> Note that the HVA to GPA mapping is not an 1:1 mapping. One HVA
> range
> >> could be mapped to several GPA ranges.
> > This is fine. Currently vfio_dma maintains IOVA->HVA mapping.
> >
> >
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Wednesday, September 18, 2019 2:10 PM
>
> On 2019/9/18 上午9:44, Tian, Kevin wrote:
> >> From: Jason Wang [mailto:jasow...@redhat.com]
> >> Sent: Tuesday, September 17, 2019 6:36 PM
> >>
> >> On
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Wednesday, September 18, 2019 2:04 PM
>
> On 2019/9/18 上午9:31, Tian, Kevin wrote:
> >> From: Alex Williamson [mailto:alex.william...@redhat.com]
> >> Sent: Tuesday, September 17, 2019 10:54 PM
> >>
> From: Tian, Kevin
> Sent: Wednesday, September 18, 2019 9:32 AM
>
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Tuesday, September 17, 2019 10:54 PM
> >
> > On Tue, 17 Sep 2019 08:48:36 +
> > "Tian, Kevin"
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Tuesday, September 17, 2019 6:36 PM
>
> On 2019/9/17 下午4:48, Tian, Kevin wrote:
> >> From: Jason Wang [mailto:jasow...@redhat.com]
> >> Sent: Monday, September 16, 2019 4:33 PM
> >>
> >>
>
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Tuesday, September 17, 2019 10:54 PM
>
> On Tue, 17 Sep 2019 08:48:36 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jason Wang [mailto:jasow...@redhat.com]
> > > Sent: Monday, Septembe
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Monday, September 16, 2019 4:33 PM
>
>
> On 2019/9/16 上午9:51, Tian, Kevin wrote:
> > Hi, Jason
> >
> > We had a discussion about dirty page tracking in VFIO, when vIOMMU
> > is enabled:
> >
&
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, September 13, 2019 11:48 PM
>
> On Thu, 12 Sep 2019 23:00:03 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > &g
Hi, Jason
We had a discussion about dirty page tracking in VFIO, when vIOMMU
is enabled:
https://lists.nongnu.org/archive/html/qemu-devel/2019-09/msg02690.html
It's actually a similar model as vhost - Qemu cannot interpose the fast-path
DMAs thus relies on the kernel part to track and report
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, September 12, 2019 10:41 PM
>
> On Tue, 3 Sep 2019 06:57:27 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> >
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Wednesday, September 4, 2019 1:37 PM
>
> On Wed, Sep 04, 2019 at 04:23:50AM +, Tian, Kevin wrote:
> > > From: Peter Xu [mailto:pet...@redhat.com]
> > > Sent: Wednesday, September 4, 2019 9:44 AM
> > >
&
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Wednesday, September 4, 2019 9:44 AM
>
> On Tue, Sep 03, 2019 at 01:37:11PM +0200, Auger Eric wrote:
> > Hi Peter,
> >
> > On 8/19/19 10:11 AM, Peter Xu wrote:
> > > On Tue, Jul 30, 2019 at 07:21:30PM +0200, Eric Auger wrote:
> > >
> > > [...]
>
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Saturday, August 31, 2019 12:33 AM
>
> On Fri, 30 Aug 2019 08:06:32 +0000
> "Tian, Kevin" wrote:
>
> > > From: Tian, Kevin
> > > Sent: Friday, August 30, 2019 3:26 PM
> &g
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Saturday, August 31, 2019 12:15 AM
>
> On Fri, 30 Aug 2019 07:25:59 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Thursd
> From: Tian, Kevin
> Sent: Friday, August 30, 2019 3:26 PM
>
[...]
> > How does QEMU handle the fact that IOVAs are potentially dynamic while
> > performing the live portion of a migration? For example, each time a
> > guest driver calls dma_m
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, August 29, 2019 4:51 AM
>
> On Tue, 27 Aug 2019 00:25:41 +0530
> Kirti Wankhede wrote:
>
> > - Defined MIGRATION region type and sub-type.
> > - Used 3 bits to define VFIO device states.
> > Bit 0 => _RUNNING
> >
> From: Dr. David Alan Gilbert [mailto:dgilb...@redhat.com]
> Sent: Friday, August 23, 2019 5:27 PM
>
> * Tian, Kevin (kevin.t...@intel.com) wrote:
> > > From: Dr. David Alan Gilbert [mailto:dgilb...@redhat.com]
> > > Sent: Friday, August 23, 2019 3:13 AM
> &
> From: Dr. David Alan Gilbert [mailto:dgilb...@redhat.com]
> Sent: Friday, August 23, 2019 3:13 AM
>
> * Kirti Wankhede (kwankh...@nvidia.com) wrote:
> >
> >
> > On 8/22/2019 3:02 PM, Dr. David Alan Gilbert wrote:
> > > * Kirti Wankhede (kwankh...@nvidia.com) wrote:
> > >> Sorry for delay to
> From: Auger Eric [mailto:eric.au...@redhat.com]
> Sent: Thursday, August 1, 2019 3:45 AM
>
> Hi Michael,
>
> On 7/31/19 9:25 PM, Michael S. Tsirkin wrote:
> > On Tue, Jul 30, 2019 at 11:20:44PM +, Tian, Kevin wrote:
> >>> From: Michael S. Tsirkin
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Wednesday, July 31, 2019 3:38 AM
>
> On Tue, Jul 30, 2019 at 07:21:33PM +0200, Eric Auger wrote:
> > We introduce a new msi_bypass field which indicates whether
> > the IOAPIC MSI window [0xFEE0 - 0xFEEF] must be exposed
it's
> From: Elijah Shakkour [mailto:elija...@mellanox.com]
> Sent: Sunday, April 7, 2019 9:47 PM
>
>
> > -Original Message-----
> > From: Tian, Kevin
> > Sent: Thursday, April 4, 2019 10:58 AM
> > To: Peter Xu ; Elijah Shakkour
> >
> > Cc: Knut
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Thursday, April 4, 2019 3:00 PM
>
> On Wed, Apr 03, 2019 at 10:10:35PM +, Elijah Shakkour wrote:
>
> [...]
>
> > > > > > > > You can also try to enable VT-d device log by appending:
> > > > > > > >
> > > > > > > > -trace enable="vtd_*"
>
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Tuesday, March 12, 2019 4:19 AM
> On Mon, 11 Mar 2019 02:33:11 +0000
> "Tian, Kevin" wrote:
>
[...]
>
> I think I've fully conceded any notion of security by obscurity towards
> opaque d
> From: Alex Williamson
> Sent: Saturday, March 9, 2019 6:03 AM
>
> On Fri, 8 Mar 2019 16:21:46 +
> "Dr. David Alan Gilbert" wrote:
>
> > * Alex Williamson (alex.william...@redhat.com) wrote:
> > > On Thu, 7 Mar 2019 23:20:36 +
> > &
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, March 8, 2019 1:44 AM
> > >
> > > > This kind of data needs to be saved / loaded in pre-copy and
> > > > stop-and-copy phase.
> > > > The data of device memory is held in device memory region.
> > >
> From: Yi Sun [mailto:yi.y@linux.intel.com]
> Sent: Friday, March 1, 2019 3:13 PM
>
> On 19-03-01 15:07:34, Peter Xu wrote:
> > On Thu, Feb 28, 2019 at 09:47:54PM +0800, Yi Sun wrote:
> > > Intel vt-d rev3.0 [1] introduces a new translation mode called
> > > 'scalable mode', which enables
> From: Neo Jia [mailto:c...@nvidia.com]
> Sent: Thursday, February 21, 2019 3:10 PM
>
> On Thu, Feb 21, 2019 at 05:52:53AM +, Tian, Kevin wrote:
> > > From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> > > Sent: Thursday, February 21, 2019 1:25 PM
> &
> From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> Sent: Thursday, February 21, 2019 1:25 PM
>
> On 2/20/2019 3:52 PM, Dr. David Alan Gilbert wrote:
> > * Kirti Wankhede (kwankh...@nvidia.com) wrote:
> >> Add migration support for VFIO device
> >
> > Hi Kirti,
> > Can you explain how this
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Thursday, February 14, 2019 4:13 PM
>
> On Thu, Feb 14, 2019 at 07:35:20AM +, Tian, Kevin wrote:
> > > From: Peter Xu [mailto:pet...@redhat.com]
> > > Sent: Thursday, February 14, 2019 3:14 PM
> &g
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Thursday, February 14, 2019 3:14 PM
>
> >
> > > When 256 bits invalidation descriptor is used, the guest driver
> > > should be responsible to fill in zeros into reserved fields.
> > >
> > > Another question: is val[2] & val[3] used in any place
> From: Yu Zhang
> Sent: Saturday, December 22, 2018 1:34 AM
>
[...]
> >
> > > As to the check against hardware IOMMU, Peter once had a proposal in
> > > http://lists.nongnu.org/archive/html/qemu-devel/2018-
> 11/msg02281.html
> > >
> > > Do you have any comment or suggestion on Peter's proposal?
> From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> Sent: Friday, November 23, 2018 4:02 AM
>
[...]
> >
> > I looked at the explanations in this patch, but still didn't get the
> > intention,
> e.g.:
> >
> > + * - VFIO_DEVICE_STATE_MIGRATION_SETUP:
> > + * Transition VFIO device in
> From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> Sent: Wednesday, November 21, 2018 12:24 PM
>
>
> On 11/21/2018 5:56 AM, Tian, Kevin wrote:
> >> From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> >> Sent: Wednesday, November 21, 2018 4:40 AM
> >
> From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> Sent: Wednesday, November 21, 2018 4:40 AM
>
> - Defined MIGRATION region type and sub-type.
> - Defined VFIO device states during migration process.
> - Defined vfio_device_migration_info structure which will be placed at 0th
> offset of
1 - 100 of 305 matches
Mail list logo
