[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Xen-devel] [PATCH 1/1] xen-hvm.c: Add support for Xen
From: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] [Xen-devel] [PATCH 1/1] xen-hvm.c: Add support for Xen access to vmport |
Date: |
Wed, 1 Oct 2014 09:01:31 -0700 |
On Wed, Oct 1, 2014 at 7:44 AM, Ian Campbell <address@hidden> 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
> address@hidden
> http://lists.xen.org/xen-devel