| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [PATCH 00/15] RFC xen device model support
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.
Regards,
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home