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: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH 00/15] RFC xen device model support
From: Anthony Liguori <anthony@xxxxxxxxxxxxx>
Date: Fri, 13 Aug 2010 15:48:57 -0500
Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "qemu-devel@xxxxxxxxxx" <qemu-devel@xxxxxxxxxx>
Delivery-date: Fri, 13 Aug 2010 13:49:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1008132016310.2545@kaball-desktop>
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> <alpine.DEB.2.00.1008132016310.2545@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6
On 08/13/2010 02:35 PM, Stefano Stabellini wrote:
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 :).

Ah, fantastic :-)

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?

Let's figure out the right solution and then we'll figure out the incremental approach. I don't mind if you keep it in the next few rounds of the series but I don't think we can merge it.

A good way to start would be for ya'll to take a look at the places where we hook for KVM. For instance, cpu_register_phys_memory_client. With an additional hook in the map()/unmap()/rw() path, you should be able to implement the map cache support and deal with memory in a sane way.

I think that would allow us to separate the discussion of having xen hooks with removing TCG support in the Xen builds which as I said earlier, is something we also would like to do in KVM.


Anthony Liguori

If you really want us to drop the xen specific target we'll need
close guidance in how to proceed.

Xen-devel mailing list