Re: [PATCH v11 8/9] Add IOREQ_TYPE_VMWARE_PORT

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

On 06/04/2015 12:28 PM, Don Slutz wrote:
> On 06/03/15 13:09, George Dunlap wrote:
>> On 05/22/2015 04:50 PM, Don Slutz wrote:
>>> This adds synchronization of the 6 vcpu registers (only 32bits of
>>> them) that vmport.c needs between Xen and QEMU.
>>>
>>> This is to avoid a 2nd and 3rd exchange between QEMU and Xen to
>>> fetch and put these 6 vcpu registers used by the code in vmport.c
>>> and vmmouse.c
>>>
>>> In the tools, enable usage of QEMU's vmport code.
>>>
>>> The currently most useful VMware port support that QEMU has is the
>>> VMware mouse support.  Xorg included a VMware mouse support that
>>> uses absolute mode.  This make using a mouse in X11 much nicer.
>>>
>>> Signed-off-by: Don Slutz <dslutz@verizon.com>
>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>> Sorry for coming a bit late to this party.  On a high level I think this
>> is good, but there doesn't seem to be anything in here in particular
>> that is vmware-specific.  Would it make more sense to give this a more
>> generic name, and have it include all of the general-purpose registers?
> 
> I do not know of a more general case.  The code here is very VMware "in
> (%dx),%eax" specific.  The x86 architecture does not have an in/out case
> where registers other then rax get used and/or changed that need to be
> sent to QEMU.  There already is code to handle ins better then 1 byte at
> a time.

"VMWare-specific" doesn't mean VMWare is *currently* the only one that
uses it; it means that the data passed is so VMWare specific that VMWare
is likely to *always* be the only user.

All this additional functionality does (as I understand it) is ship over
some registers verbatim, and restore them on completion.  You could
imagine other functionality which might be implemented in qemu (or
another ioreq server) that could use functionality like that.

For example, this functionality might potentially be of use to the XenGT
guys, who need to emulate writes to some pages to shadow the graphics
card pagetables; or to someone wanting to implement some sort of
introspection feature that is meant to work in both KVM and Xen.

The only thing vmware-specific about this at the moment is the
particular subset of registers you're copying over.

> There is also a data size issue.  The register data sent over is smaller
> then the ioreq data.  Therefore the number of vCPUs that are supported
> is the the same.  Changing the amount of data sent would effect this
> (like requiring more then 1 page).

Hmm... so it looks like the ioreq struct is about the size of 8
uint32_t's, or 4 uint64_ts.

So you could easily include eax, ebx, ecx, edx, esi, edi, eip, esp.

But it's not clear that you could do general-purpose emulation without
things like ebp, eflags, and so on.  Nor is it clear that it would be
useful to do only emulation for 32-bit instructions.

Would it be terribly bad to make it 4 pages long -- long enough to get
most of the 64-bit registers in there if wanted?

Or alternately, would it be possible to allow the contents of this page
to be changed in the future, perhaps with a domctl?

 -George