[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.