Re: [Xen-devel] [PATCH v11 8/9] Add IOREQ_TYPE_VMWARE_PORT

[Don Slutz <don.slutz@xxxxxxxxx>]

On 06/08/15 06:05, George Dunlap wrote:
> 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@xxxxxxxxxxx>
>>>> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
>>> 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.
> 

Yes.

> 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.
> 

The current way does not support multiple ioreq servers.  However any
one of the ioreq servers can be the one using it.  Currently QEMU
already gets it.  QEMU can say it does not want the page, but that is
code that currently does not exist.

> 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.
> 

Not sure how KVM can use Xen's ioreq, but you seem to think there is a way.

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

It is also only 32bits of the 64bit registers....

>> 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.
> 

Yes.

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

Not clear eax is any benefit, it is already in ioreq by a different name
(really rax) req->data. eip and esp would be much harder to get correct.

> 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.

Mostly why I was going with VMware "only" and I/O instructions only.

> 
> 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?
> 

The switch to 4 pages is harder.  There is code in QEMU that does the
page mapping.  So you need to add a way to map 4 pages in QEMU, wait for
it to get into upstream QEMU, then change Xen to use it.  The 1 page
code is already there (QEMU 2.3 and later).

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

The actual layout is mostly controlled (a copy is in the QEMU soucre) by
Xen include files.  I do not think that a QEMU built without the correct
Xen include files would work, but I would not want to bet that it would
never happen.

However the code to move registers around is in QEMU and does not come
from include files.  So adding more registers does not work.  I have not
looked at switch to 64bits in the registers in QEMU, that maybe could be
done with an include file change.

If I am reading this correctly, you would like the code in QEMU to fully
be from xen include files.  This would still need design, coding, and
acceptance by QEMU before Xen can be changed to use it.

   -Don Slutz

> 
>  -George
> 

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