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

[Anthony Liguori <anthony@codemonkey.ws>]

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.
>