Re: [Xen-devel] [PATCH for-4.5 v6 00/16] Xen VMware tools support

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2014-09-22 at 13:19 -0400, Don Slutz wrote:
> >> It sounds plausible, for sure.
> >>
> >> Even so, why can't the result of that #GP be a calldown into qemu for
> >> further processing?
> >
> 
> This is not simple in that QEMU does not have access to the VCPU 
> registers.  Unlike a normal
> I/O request, vmware_port (aka vmport) both reads and writes VCPU registers.

Are you saying that emulating a normal in or out instruction doesn't
require accessing vcpu registers? Are you sure? Surely it needs to
either read the source or write the destination register somehow.

> 
> > I was only responding to the part of your comment in parentheses. :-)
> >
> > I suppose in large part it would depend on what the hypercalls were 
> > actually doing; I'd have to go back and look at them to say if they 
> > need to be in Xen or whether they could be passed on to qemu.
> >
> 
> Clearly it is possible to pass the VCPU registers to QEMU, but that is 
> currently not done.

I think there's an existing hypercall to get/set the state for a vcpu,
perhaps it is too heavy weight to be used here though.

An alternative would be a semantically higher level I/O req which took a
guest pointer to a key and a guest pointer to the buffer etc, without
needing the registers themselves.

>   So a new
> version of QEMU would also be needed to go this way.  None the the 
> proposed features need
> any data from QEMU, so I do not think this make sense.

The concern is that it is adding a load of complex looking string and
pointer manipulation stuff to the hypervisor, the sort of thing which
often leads to security vulnerabilities.

So that would be better done outside of Xen itself if possible, if a
qemu update is the price for that then it doesn't seem so bad to me.

Ian.


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