qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] summary of current vfio mdev upstreaming status


From: Xiao Guangrong
Subject: Re: [Qemu-devel] summary of current vfio mdev upstreaming status
Date: Thu, 29 Sep 2016 17:46:03 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0



On 09/29/2016 05:36 PM, Neo Jia wrote:
On Thu, Sep 29, 2016 at 05:05:47PM +0800, Xiao Guangrong wrote:


On 09/29/2016 04:55 PM, Jike Song wrote:
Hi all,

In order to have a clear understanding about the VFIO mdev upstreaming
status, I'd like to summarize it. Please share your opinions on this,
and correct my misunderstandings.

The whole vfio mdev series can be logically divided into several parts,
they work together to provide the mdev support.

I think what Jike want to suggest is how about partially push/develop the
mdev. As jike listed, there are some parts can be independent and they have
mostly been agreed.

Such development plan can make the discussion be much efficient in the
community. Also it make the possibility that Intel, Nvdia, IBM can focus
on different parts and co-develop it.

Hi Guangrong,

JFYI. we are preparing v8 patches to accommodate most comments we have discussed
so far and we will also include several things that we have decided on sysfs.

I definitely would like to see more interactive discussions especially on the
sysfs class front from intel folks.

Regarding the patch development and given the current status, especially where
we are and what we have been through, I am very confident that we should be able
to fully handle this ourselves, but thanks for offering help anyway!

We should be able to react as fast as possible based on the public mailing list
discussions, so again I don't think that part is an issue.

We understand the progress goes okay. However, splitting such big patchset
into small parts is a better way to push large code to upstream - it is
better for review and validation and we can quickly iterate the code if
there are new issues exposed during the review of new version.

Particularly, based on the current situation that the sysfs interfaces are
far from the way to be decided, it is definitely a good idea to push the
basic infrastructure first, later let's focal on the ABI part - sysfs
interface design.

Thanks!








reply via email to

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