Messages in this thread | | | From | Shameerali Kolothum Thodi <> | Subject | RE: [PATCH v5 7/8] hisi_acc_vfio_pci: Add support for VFIO live migration | Date | Wed, 23 Feb 2022 15:58:03 +0000 |
| |
> -----Original Message----- > From: Jason Gunthorpe [mailto:jgg@nvidia.com] > Sent: 23 February 2022 00:53 > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com> > Cc: kvm@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-crypto@vger.kernel.org; alex.williamson@redhat.com; > cohuck@redhat.com; mgurtovoy@nvidia.com; yishaih@nvidia.com; Linuxarm > <linuxarm@huawei.com>; liulongfang <liulongfang@huawei.com>; Zengtao (B) > <prime.zeng@hisilicon.com>; Jonathan Cameron > <jonathan.cameron@huawei.com>; Wangzhou (B) <wangzhou1@hisilicon.com> > Subject: Re: [PATCH v5 7/8] hisi_acc_vfio_pci: Add support for VFIO live > migration > > On Mon, Feb 21, 2022 at 11:40:42AM +0000, Shameer Kolothum wrote: > > > + /* > > + * ACC VF dev BAR2 region consists of both functional register space > > + * and migration control register space. For migration to work, we > > + * need access to both. Hence, we map the entire BAR2 region here. > > + * But from a security point of view, we restrict access to the > > + * migration control space from Guest(Please see mmap/ioctl/read/write > > + * override functions). > > + * > > + * Also the HiSilicon ACC VF devices supported by this driver on > > + * HiSilicon hardware platforms are integrated end point devices > > + * and has no capability to perform PCIe P2P. > > If that is the case why not implement the RUNNING_P2P as well as a > NOP? > > Alex expressed concerned about proliferation of non-P2P devices as it > complicates qemu to support mixes
Since both PRE_COPY and P2P are optional, Qemu anyway will have to check and add the support, right?. Just worried the FSM will look complicated with both PRE_COPY and P2P arcs now.
Thanks, Shameer
| |