a device from two guests, or from dom 0 and a guest, can destroy the filesystem,
and this check prevents that. This should ensure that the xm tests
11_block_attach_shared_dom0 and 12_block_attach_shared_domU should pass.
Closes bug #331.
Devices may be shared only if all uses are read-only. If anyone has read-write
access to a device, then no sharing is allowed.
The mode in the config file may now have an exclamation mark appended, to
indicate that devices may be shared (i.e. that this new check should be
bypassed). This supports some network block devices, but is clearly dangerous
and should only be used when you know what you are doing.
The mode specified in the config file is now written explicitly to the store,
To implement this, the blkback driver has been changed to create two entries
in /sys describing each device in use. This means that we can determine which
devices are in use without crawling through the store.
The physical-device node has been changed to give the major and minor of the
device, separated by a colon. This means that we do not need to pack these
numbers into one, removing the restriction to 8 bit minors that we had in place
before.
The mode specified in the config file is now written explicitly to the store,
rather than using the presence or absence of a read-only node. This supports
the write-sharing override above.
If the device is in use, a new hotplug status of "busy" is written to the
store, and a message is written to a new hotplug-error node. Xend uses these
things for diagnosis.
The block scripts do not need to handle online or offline events, so this
support has been removed. These scripts can be called twice, depending upon
the hotplug config, so they now identify the second run and do not attempt to
set up the device again.
The device directories in the store are cleaned out before new details are
written there. This prevents stale information from messing up block device
hotplugging. This will be one cause of "blkback: changing physical device
not supported" messages.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
interface from the bridge when going offline -- the comment stating that
interfaces are auto-removed does not seem to be true, at least some of the
time. Log failure of brctl delif and ifconfig down only at debug level, as
this script may be called more than once, depending upon the hotplug
configuration.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
hotplug config, the offline event may come through to this script twice, and
the iptables -D will fail the second time.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
Xserver will scan pci and the cirrus VGA driver will register
mmio each time, cause mmio array out of space.
Signed-off-by: Xiaofeng Ling <xiaofeng.ling@intel.com>
splicing the strings together manually.
Replace the word "bogus" with the command in question where it appears, as this
shows up in the Usage statements.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
again. Closes bug #397.
To perform this check in the same transaction as the writing of the device
entries has required a little bit of rejigging.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
tries to read it's info from the xenstore. Instead of sending a NULL
pointer for the name the name will be displayed as a ' ' until the next
refresh where xentop will then properly display the name.
Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
emerged as a problem in the field, AFAIK, but it seems that distro scripts
could have brought the device down already by this point (Debian stable's
net.agent does ifdown vifX.Y, and it wouldn't surprise me if someone decided
to do ifconfig vifX.Y down if this failed, for example).
Logging but ignoring the failure seems sensible.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
Valgrind cannot see when a hypercall has initialised entries in a data
structure, so appropriate memsets have been placed before using dom0_op_t,
privcmd_hypercall_t, and a couple of miscellaneous blocks passed into this
layer. This initialises the block so that valgrind considers it to be valid,
but the data therein will be immediately overwritten by the hypercall, all
being well.
These changes are semantically neutral if -DVALGRIND is not set.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
