qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH 00/15] RFC xen device model support


From: Stefano Stabellini
Subject: [Qemu-devel] Re: [PATCH 00/15] RFC xen device model support
Date: Fri, 13 Aug 2010 20:35:08 +0100
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)

On Fri, 13 Aug 2010, Anthony Liguori wrote:
> Hi Stefano/Anthony,
> 
> On 08/12/2010 09:08 AM, Stefano Stabellini wrote:
> > Hi all,
> > this is the long awaited patch series to add xen device model support in
> > qemu; the main author is Anthony Perard.
> >    
> 
> Thanks for sending this out.  Overall, the series looks pretty good.  I 
> think there's just a couple issues we need to address to get it into a 
> mergable state.
> 

Thank you very much for taking the time to review our series!

> We definitely need to resolve the various CODING_STYLE issues.
> 

Of course, we'll do in the next version.

> We should limit XenStore interactions to strictly be device model 
> setup.  Any management operations should be done through QMP.  The main 
> reason to take this approach is to ensure that we don't end up with a 
> more powerful interface via xenstore verses QMP or vice versa.
> 

I want to be clear on this: I like QMP and I dislike xenstore,
especially when it is used as an RPC mechanism.
I have NO intention of transforming xenstore in a QMP alternative, in
fact we removed quite a lot of xenstore interactions developing this
series, in particular the whole disk setup (and it felt good :).
Currently in qemu-xen we are using xenstore even for pci passthrough,
but I certainly do not intend to make the same mistake again when we'll
add pci passthrough support to qemu this time.
Implementing QMP support in libxl is definitely on our todo list.


> The target changes are probably the most contentious.  Fortunately, we 
> have a very similar set of goals with KVM so I think we'll be able to 
> come up with a common solution to the problem.
> 

Yes, this is the part that worries me the most.
Do you think is reasonable to keep the new target for the time being or
do you want us to try the other approach ASAP?
If you really want us to drop the xen specific target we'll need
close guidance in how to proceed.



reply via email to

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