qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 0/5] Add migration support for VFIO device


From: Tian, Kevin
Subject: Re: [Qemu-devel] [PATCH v3 0/5] Add migration support for VFIO device
Date: Wed, 27 Feb 2019 01:51:29 +0000

> From: Neo Jia [mailto:address@hidden
> Sent: Thursday, February 21, 2019 3:10 PM
> 
> On Thu, Feb 21, 2019 at 05:52:53AM +0000, Tian, Kevin wrote:
> > > From: Kirti Wankhede [mailto:address@hidden
> > > Sent: Thursday, February 21, 2019 1:25 PM
> > >
> > > On 2/20/2019 3:52 PM, Dr. David Alan Gilbert wrote:
> > > > * Kirti Wankhede (address@hidden) wrote:
> > > >> Add migration support for VFIO device
> > > >
> > > > Hi Kirti,
> > > >   Can you explain how this compares and works with Yan Zhao's
> > > > set?
> > >
> > > This patch set is incremental version of my previous patch set:
> > > https://patchwork.ozlabs.org/cover/1000719/
> > > This takes care of the feedbacks received on previous version.
> > >
> > > This patch set is different than Yan Zhao's set.
> > >
> >
> > I can help give some background about Yan's work:
> >
> > There was a big gap between Kirti's last version and the overall review
> > comments, especially this one:
> > https://www.mail-archive.com/address@hidden/msg576652.html
> 
> Hi Kevin,
> 
> >
> > Then there was no reply from Kirti whether she agreed with the comments
> > and was working on a new version.
> 
> Sorry, we should ack on those comments when we have received them last
> time.
> 
> >
> > Then we think we should jump in to keep the ball moving, based on
> > a fresh implementation according to recommended direction, i.e. focusing
> > on device state management instead of sticking to migration flow in kernel
> > API design.
> >
> > and also more importantly we provided kernel side implementation based
> > on Intel GVT-g to give the whole picture of both user/kernel side changes.
> > That should give people a better understanding of how those new APIs
> > are expected to be used by Qemu, and to be implemented by vendor driver.
> >
> > That is why Yan just shared her work.
> 
> Really glad to see the v2 version works for you guys, appreciate for the 
> driver
> side changes.
> 
> >
> > Now it's great to see that Kirti is still actively working on this effort 
> > and is
> > also moving toward the right direction. Let's have a close look at two
> > implementations and then choose a cleaner one as base for future
> > enhancements. :-)
> 
> Yes, the v3 has addressed all the comments / concerns raised in the v2, I 
> think
> we should take a look and keep moving.
> 
> Just a quick thought - would be possible / better to have Kirti focus on the
> QEMU
> patches and Yan take care GVT-g kernel driver side changes? This will give us
> the best testing coverage. Hope I don't step on anybody's toes here. ;-)
> 

That is one option to be considered. For now let's focus on closing 
kernel interface definition. I saw Alex given lots of comments on both
series. Hope we can discuss and converge on that part soon, before
moving to next version. :-)

Thanks
Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]