[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN9PR11MB54338A0821C061FEE018F43E8CA99@BN9PR11MB5433.namprd11.prod.outlook.com>
Date: Wed, 29 Sep 2021 09:05:54 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>
CC: "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
"jgg@...dia.com" <jgg@...dia.com>,
"mgurtovoy@...dia.com" <mgurtovoy@...dia.com>,
Linuxarm <linuxarm@...wei.com>,
liulongfang <liulongfang@...wei.com>,
"Zengtao (B)" <prime.zeng@...ilicon.com>,
"Jonathan Cameron" <jonathan.cameron@...wei.com>,
"Wangzhou (B)" <wangzhou1@...ilicon.com>,
"He, Shaopeng" <shaopeng.he@...el.com>,
"Zhao, Yan Y" <yan.y.zhao@...el.com>
Subject: RE: [PATCH v3 0/6] vfio/hisilicon: add acc live migration driver
> From: Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@...wei.com>
>
> Hi Kevin,
>
> > From: Tian, Kevin [mailto:kevin.tian@...el.com]
> > Sent: 29 September 2021 04:58
> >
> > Hi, Shameer,
> >
> > > From: Shameer Kolothum <shameerali.kolothum.thodi@...wei.com>
> > > Sent: Wednesday, September 15, 2021 5:51 PM
> > >
> > > Hi,
> > >
> > > Thanks to the introduction of vfio_pci_core subsystem framework[0],
> > > now it is possible to provide vendor specific functionality to
> > > vfio pci devices. This series attempts to add vfio live migration
> > > support for HiSilicon ACC VF devices based on the new framework.
> > >
> > > HiSilicon ACC VF device MMIO space includes both the functional
> > > register space and migration control register space. As discussed
> > > in RFCv1[1], this may create security issues as these regions get
> > > shared between the Guest driver and the migration driver.
> > > Based on the feedback, we tried to address those concerns in
> > > this version.
> >
> > This series doesn't mention anything related to dirty page tracking.
> > Are you rely on Keqian's series for utilizing hardware iommu dirty
> > bit (e.g. SMMU HTTU)?
>
> Yes, this doesn't have dirty page tracking and the plan is to make use of
> Keqian's SMMU HTTU work to improve performance. We have done basic
> sanity testing with those patches.
>
Do you plan to support migration w/o HTTU as the fallback option?
Generally one would expect the basic functionality ready before talking
about optimization.
If not, how does userspace know that migration of a given device can
be allowed only when the iommu supports hardware dirty bit?
Thanks
Kevin
Powered by blists - more mailing lists