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
people
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
b/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 @@
-MAGIC IOPORT 0x10 PROTOCOL
-
-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
-drivers):
-
-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
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog
|
Home