This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Anthony Liguori <anthony@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH 00/15] RFC xen device model support
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Fri, 13 Aug 2010 20:35:08 +0100
Cc: Anthony, Perard <anthony.perard@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "qemu-devel@xxxxxxxxxx" <qemu-devel@xxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Fri, 13 Aug 2010 12:35:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C659881.70806@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <alpine.DEB.2.00.1008121244200.2545@kaball-desktop> <4C659881.70806@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.

Xen-devel mailing list