This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-changelog] [qemu-xen-unstable] qemu-xen: remove i386-dm/README.hvm-

To: xen-changelog@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-changelog] [qemu-xen-unstable] qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
From: patchbot@xxxxxxx
Date: Wed, 02 Nov 2011 16:11:06 +0000
Delivery-date: Wed, 02 Nov 2011 09:13:11 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-changelog-request@lists.xensource.com?subject=help>
List-id: BK change log <xen-changelog.lists.xensource.com>
List-post: <mailto:xen-changelog@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=unsubscribe>
Reply-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-changelog-bounces@xxxxxxxxxxxxxxxxxxx
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where 
    look for docs, plus we are transitioning to upstream qemu.
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
 i386-dm/README.hvm-pv-magic-ioport-disable |   70 ----------------------------
 1 files changed, 0 insertions(+), 70 deletions(-)

diff --git a/i386-dm/README.hvm-pv-magic-ioport-disable 
deleted file mode 100644
index 142394a..0000000
--- a/i386-dm/README.hvm-pv-magic-ioport-disable
+++ /dev/null
@@ -1,70 +0,0 @@
-The protocol covers three basic things:
--- Disconnecting emulated devices.
--- Getting log messages out of the drivers and into dom0.
--- Allowing dom0 to block the loading of specific drivers.  This is
-   intended as a backwards-compatibility thing: if we discover a bug
-   in some old version of the drivers, then rather than working around
-   it in Xen, we have the option of just making those drivers fall
-   back to emulated mode.
-The current protocol works like this (from the point of view of
-1) When the drivers first come up, they check whether the unplug logic
-   is available by reading a two-byte magic number from IO port 0x10.
-   These should be 0x49d2.  If the magic number doesn't match, the
-   drivers don't do anything.
-2) The drivers read a one-byte protocol version from IO port 0x12.  If
-   this is 0, skip to 6.
-3) The drivers write a two-byte product number to IO port 0x12.  At
-   the moment, the only drivers using this protocol are our
-   closed-source ones, which use product number 1.
-4) The drivers write a four-byte build number to IO port 0x10.
-5) The drivers check the magic number by reading two bytes from 0x10
-   again.  If it's changed from 0x49d2 to 0xd249, the drivers are
-   blacklisted and should not load.
-6) The drivers write a two-byte bitmask of devices to unplug to IO
-   port 0x10.  The defined fields are:
-   1 -- All IDE disks (not including CD drives)
-   2 -- All emulated NICs
-   4 -- All IDE disks except for the primary master (not including CD
-       drives)
-   The relevant emulated devices then disappear from the relevant
-   buses.  For most guest operating systems, you want to do this
-   before device enumeration happens.
-...) Once the drivers have checked the magic number, they can send log
-     messages to qemu which will be logged to wherever qemu's logs go
-     (/var/log/xen/qemu-dm.log on normal Xen, dom0 syslog on
-     XenServer).  These messages are written to IO port 0x12 a byte at
-     a time, and are terminated by newlines.  There's a fairly
-     aggressive rate limiter on these messages, so they shouldn't be
-     used for anything even vaguely high-volume, but they're rather
-     useful for debugging and support.
-     It is still permitted for a driver to use this logging feature if
-     it is blacklisted, but ONLY if it has checked the magic number
-     and found it to be 0x49d2 or 0xd249.
-This isn't exactly a pretty protocol, but it does solve the problem.
-The blacklist is, from qemu's point of view, handled mostly through
-xenstore.  A driver version is considered to be blacklisted if
-/mh/driver-blacklist/{product_name}/{build_number} exists and is
-readable, where {build_number} is the build number from step 4 as a
-decimal number.  {product_name} is a string corresponding to the
-product number in step 3.
-The master registry of product names and numbers is in
-qemu-xen-unstable's xenstore.c.
generated by git-patchbot for /home/xen/git/qemu-xen-unstable.git

Xen-changelog mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-changelog] [qemu-xen-unstable] qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable, patchbot <=