From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Xen-devel] [PATCH 1/1] xen-hvm.c: Add support for Xen access to vmport Date: Wed, 1 Oct 2014 09:01:31 -0700 Message-ID: References: <1411757235-29128-1-git-send-email-dslutz@verizon.com> <1411757235-29128-2-git-send-email-dslutz@verizon.com> <5429FA0F.4050905@terremark.com> <1412174646.4861.38.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <1412174646.4861.38.camel@citrix.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Ian Campbell Cc: Alexander Graf , "xen-devel@lists.xensource.com" , Marcel Apfelbaum , "Michael S. Tsirkin" , "qemu-devel@nongnu.org" , "Slutz, Donald Christopher" , Markus Armbruster , Anthony Liguori , =?UTF-8?Q?Andreas_F=C3=A4rber?= , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Wed, Oct 1, 2014 at 7:44 AM, Ian Campbell 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