On Wed, Oct 1, 2014 at 7:44 AM, Ian Campbell <ian.campb...@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-de...@lists.xen.org > http://lists.xen.org/xen-devel
