Re: [Qemu-devel] [Xen-devel] [PATCH 1/1] xen-hvm.c: Add support for Xen access to vmport

[Anthony Liguori <anthony@codemonkey.ws>]

On Wed, Oct 1, 2014 at 7:44 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2014-10-01 at 10:20 +0100, Stefano Stabellini wrote:
>> I wonder if we could send both ioreqs at once from Xen and back from
>> QEMU. Or maybe append the registers to IOREQ_TYPE_VMWARE_PORT, changing
>> the size of ioreq_t only for this ioreq type.
>
> Random idea: Why new add a IOREQ_TYPE_FULL_STATE which would be issued
> for these ports and let qemu decode the fact that it is vmware
> internally? That might be a more generically useful interface in the
> future?
>
> WRT to fitting all the register state in the current sized request, you
> could declare that this new thing takes multiple slots.
>
> Also, I may be wrong, but I thought most IOREQs were synchronous so only
> one slot was ever used? The buffered ioreq stuff has a separate ring (or
> uses a different part of the page, or something). I might be talking
> nonsense here though ;-)

There really isn't a concept of "CPU associated with an IOREQ" outside
of two very special cases, LAPIC emulation and vmport.  LAPIC
emulation really belongs closer to the CPU and given V-APIC, it's
gotten moved into hardware anyway.  vmport is just a hack VMware made.

I think it's better to think of it as a VMware specific hypercall and
terminate the IOREQ within the hypervisor.  Passing a decoded version
of the request to QEMU is fine but passing the full CPU state as part
of an IOREQ_TYPE_FULL_STATE is not very useful.  It's just an
IOREQ_TYPE_VMPORT with more information than is needed.

Regards,

Anthony Liguori

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