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

[Anthony Liguori <anthony@xxxxxxxxxxxxx>]

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