From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48753) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZMLQ-0005cX-Vg for qemu-devel@nongnu.org; Wed, 01 Oct 2014 12:01:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XZMLM-00058A-Jv for qemu-devel@nongnu.org; Wed, 01 Oct 2014 12:01:36 -0400 Received: from mail-qa0-f44.google.com ([209.85.216.44]:63014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZMLM-00057w-Gm for qemu-devel@nongnu.org; Wed, 01 Oct 2014 12:01:32 -0400 Received: by mail-qa0-f44.google.com with SMTP id x12so449929qac.31 for ; Wed, 01 Oct 2014 09:01:31 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1412174646.4861.38.camel@citrix.com> 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> Date: Wed, 1 Oct 2014 09:01:31 -0700 Message-ID: From: Anthony Liguori Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [Xen-devel] [PATCH 1/1] xen-hvm.c: Add support for Xen access to vmport List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 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