qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Don Slutz <dslutz@verizon.com>
To: qemu-devel@nongnu.org, Paul Durrant <Paul.Durrant@citrix.com>
Cc: xen-devel@lists.xensource.com,
	"Marcel Apfelbaum" <marcel.a@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Alexander Graf" <agraf@suse.de>,
	"Don Slutz" <dslutz@verizon.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Anthony Liguori" <aliguori@amazon.com>,
	"Andreas Färber" <afaerber@suse.de>,
	"Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
Subject: [Qemu-devel] [PATCH v6 0/1] Add support for Xen access to vmport
Date: Mon, 20 Oct 2014 08:47:03 -0400	[thread overview]
Message-ID: <1413809224-28433-1-git-send-email-dslutz@verizon.com> (raw)

Changes v5 to v6:
  Paul Durrant
    Do we need a forward declaration?
      Nope. Drooped.
    Added Reviewed-by.

Changes v4 to v5:
  Paul Durrant
    vmware_ioreq_t struct is not really a request any more. Maybe
    vmware_regs_t?
      Renamed various parts from vmware_ioreq to vmware_regs.  Also
      HVM_PARAM_VMPORT_IOREQ_PFN to HVM_PARAM_VMPORT_REGS_PFN.
    cpu_by_ioreq_id name implies the array is indexed by an id
    carries in the ioreq.
      Renamed cpu_by_ioreq_id to cpu_by_vcpu_id.
    Is cpu_get_vmport_ioreq_from_shared_memory worth its own
    function?
      Moved in-line.
    I don't think you need the barrier anyway.
      Dropped the barrier.
    Oh, I now realize you mean the same theoretical rather than
    actual limit, in which case this can be a build time check
    anyway.
      Switch to build time check, move to a better place.
    You could avoid passing state to both of them by setting
    current_cpu here couldn't you?
      Yes, moved state usage to handle_vmport_ioreq().

  Stefano Stabellini
    Error out if it fails with error != -ENOSYS.
      Done.

Changes RFC-v2x to v4:
  Stefano Stabellini
    Please try to get rid of the #ifdefs.
      Moved 2 #ifdefs into hw/xen/xen_common.h

Changes v2 to RFC-v2x:
  Paul Durrant
    Use a 2nd shared page.
      Added HVM_PARAM_VMPORT_IOREQ_PFN usage.

Changes v1 to v2:
   More info in commit message.

  Stefano Stabellini
    the registers being passes explicitely by Xen rather than
    "hiding" them into other ioreq fields.
       Added vmware_ioreq_t
  Paolo Bonzini & Alexander Graf
    Fixup env access
      Added cpu_by_ioreq_id.
      Set current_cpu in regs_to_cpu(), clear in regs_from_cpu().
      Drop all changes to vmport.c

Note: to use this with Xen either a version of:

[Qemu-devel] [PATCH] -machine vmport=off: Allow disabling of VMWare ioport emulation

or

>From f70663d9fb86914144ba340b6186cb1e67ac6eec Mon Sep 17 00:00:00 2001
From: Don Slutz <dslutz@verizon.com>
Date: Fri, 26 Sep 2014 08:11:39 -0400
Subject: [PATCH 1/2] hack: force enable vmport

Signed-off-by: Don Slutz <dslutz@verizon.com>
---
 hw/i386/pc_piix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 103d756..b76dfbc 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -234,7 +234,7 @@ static void pc_init1(MachineState *machine,
     pc_vga_init(isa_bus, pci_enabled ? pci_bus : NULL);
 
     /* init basic PC hardware */
-    pc_basic_device_init(isa_bus, gsi, &rtc_state, &floppy, xen_enabled(),
+    pc_basic_device_init(isa_bus, gsi, &rtc_state, &floppy, false,
         0x4);
 
     pc_nic_init(isa_bus, pci_bus);
-- 
1.8.4

needs to be done to QEMU.

And the Xen RFC patch:

[RFC][PATCH v2 1/1] Add IOREQ_TYPE_VMWARE_PORT

needs to be done to Xen.

Don Slutz (1):
  xen-hvm.c: Add support for Xen access to vmport

 include/hw/xen/xen_common.h |  22 +++++++++
 xen-hvm.c                   | 108 ++++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 125 insertions(+), 5 deletions(-)

-- 
1.8.4

             reply	other threads:[~2014-10-20 12:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-20 12:47 Don Slutz [this message]
2014-10-20 12:47 ` [Qemu-devel] [PATCH v6 1/1] xen-hvm.c: Add support for Xen access to vmport Don Slutz
2014-10-20 15:03   ` Stefano Stabellini
2014-10-20 19:26     ` Don Slutz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1413809224-28433-1-git-send-email-dslutz@verizon.com \
    --to=dslutz@verizon.com \
    --cc=Paul.Durrant@citrix.com \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=aliguori@amazon.com \
    --cc=armbru@redhat.com \
    --cc=marcel.a@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).