Re: [Xen-devel] [PATCH for-4.5 v6 08/16] xen: Add limited support of VMware's hyper-call rpc

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 09/22/2014 02:47 PM, Ian Campbell wrote:
> On Sat, 2014-09-20 at 14:07 -0400, Don Slutz wrote:
> > This interface is an extension of __HYPERVISOR_HVM_op.  It was
> > picked because xc_get_hvm_param() also uses it and VMware guest
> > info is a lot like a hvm param.
> Sorry if this has been discussed before, but did you consider doing all
> this in qemu rather than Xen?
>
> Unless there are frequent accesses to these things then qemu would be
> the default best place for this sort of thing, especially since as
> you've observed there is some pretty complex memory management and
> string handling which it would generally be better to avoid in the
> hypervisor.
>
> Your description of HVM_PARAM_VMPORT_RESET_TIME suggests they aren't
> typically accessed very frequently.
Well the whole architecture implies to me that VMWare have an 
unprivileged program in a service domain somewhere handling the actual 
RPC requests, almost certainly to keep all this crazy stuff out of their 
hypervisor.  We should take advantage of the asyncronous nature to keep 
it out of our hypervisor as well.
From an architectural perspective, since we're getting support for 
multiple ioreq servers, one could imagine having a special vmport ioreq 
server that would read stuff from xenstore.  But since KVM might want to 
use it at some point, it probably makes more sense to implement it there 
if it's possible.
Storing these key-value pairs in xenstore seems like the most obvious 
thing to do -- does qemu-xen have absolutely no xenstore access?
 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel