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

[George Dunlap <george.dunlap@eu.citrix.com>]

On 09/23/2014 01:30 PM, Ian Campbell wrote:
> 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.

Do you mean the instruction decoding in vmware_gp_check()?

I was wondering how hard it would be to use the generic emulation code.  
We already have to emulate IO instructions anyway.  This is very 
complicated code, and having it duplicated in two places seems like it's 
just asking for someone to update the one and forget to update the 
other, opening up a bug / security vulnerability.

The other question would be whether doing it in qemu would be fast 
enough, or if there would be information needed by the hypercall that's 
not available; things like GETTIME / GETTIMEFULL / GETHZ.

On the other hand, things like GETSCREENSIZE and GETGUIOPTIONS probably 
*are* better handled by qemu.

  -George