|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-changelog] [xen-unstable] merge with xen-unstable.hg
# HG changeset patch
# User Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
# Date 1228459639 -32400
# Node ID 09160c3bd1797fdee111c2837f26a749e0bf9435
# Parent f0a9a58608a08288f554a18758a19e97a51879f2
# Parent 1b173394f815fe772797415c08ffb5360e4bb084
merge with xen-unstable.hg
---
docs/misc/xen-error-handling.txt | 88 ++++++++++++++++++++++++++++++++
tools/python/xen/xend/XendConfig.py | 4 +
tools/python/xen/xend/XendDomainInfo.py | 13 ++++
xen/common/timer.c | 4 -
xen/drivers/char/ns16550.c | 7 ++
5 files changed, 113 insertions(+), 3 deletions(-)
diff -r f0a9a58608a0 -r 09160c3bd179 docs/misc/xen-error-handling.txt
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/misc/xen-error-handling.txt Fri Dec 05 15:47:19 2008 +0900
@@ -0,0 +1,88 @@
+Error handling in Xen
+---------------------
+
+1. domain_crash()
+-----------------
+Crash the specified domain due to buggy or unsupported behaviour of the
+guest. This should not be used where the hypervisor itself is in
+error, even if the scope of that error affects only a single
+domain. BUG() is a more appropriate failure method for hypervisor
+bugs. To repeat: domain_crash() is the correct response for erroneous
+or unsupported *guest* behaviour!
+
+Note that this should be used in most cases in preference to
+domain_crash_synchronous(): domain_crash() returns to the caller,
+allowing the crash to be deferred for the currently executing VCPU
+until certain resources (notably, spinlocks) have been released.
+
+Example usages:
+ * Unrecoverable guest kernel stack overflows
+ * Unsupported corners of HVM device models
+
+2. BUG()
+--------
+Crashes the host system with an informative file/line error message
+and a backtrace. Use this to check consistency assumptions within the
+hypervisor.
+
+Be careful not to use BUG() (or BUG_ON(), or ASSERT()) for failures
+*outside* the hypervisor software -- in particular, guest bugs (where
+domain_crash() is more appropriate) or non-critical BIOS or hardware
+errors (where retry or feature disable are more appropriate).
+
+Example usage: In arch/x86/hvm/i8254.c an I/O port handler includes
+the check BUG_ON(bytes != 1). We choose this extreme reaction to the
+unexpected error case because, although it could be handled by failing
+the I/O access or crashing the domain, it is indicative of an
+unexpected inconsistency in the hypervisor itself (since the I/O
+handler was only registered for single-byte accesses).
+
+
+3. BUG_ON()
+-----------
+BUG_ON(...) is merely a convenient short form for "if (...) BUG()". It
+is most commonly used as an 'always on' alternative to ASSERT().
+
+
+4. ASSERT()
+-----------
+Similar to BUG_ON(), except that it is only enabled for debug builds
+of the hypervisor. Typically ASSERT() is used only where the (usually
+small) overheads of an always-on debug check might be considered
+excessive. A good example might be within inner loops of time-critical
+functions, or where an assertion is extreme paranoia (considered
+*particularly* unlikely ever to fail).
+
+In general, if in doubt, use BUG_ON() in preference to ASSERT().
+
+
+5. panic()
+----------
+Like BUG() and ASSERT() this will crash and reboot the host
+system. However it does this after printing only an error message with
+no extra diagnostic information such as a backtrace. panic() is
+generally used where an unsupported system configuration is detected,
+particularly during boot, and where extra diagnostic information about
+CPU context would not be useful. It may also be used before exception
+handling is enabled during Xen bootstrap (on x86, BUG() and ASSERT()
+depend on Xen's exception-handling capabilities).
+
+Example usage: Most commonly for out-of-memory errors during
+bootstrap. The failure is unexpected since a host should always have
+enough memory to boot Xen, but if the failure does occur then the
+context of the failed memory allocation itself is not very
+interesting.
+
+
+6. Feature disable
+------------------
+A possible approach to dealing with boot-time errors, rather than
+crashing the hypervisor. It's particularly appropriate when parsing
+non-critical BIOS tables and detecting extended hardware features.
+
+
+7. BUILD_BUG_ON()
+-----------------
+Useful for assertions which can be evaluated at compile time. For
+example, making explicit assumptions about size and alignment of C
+structures.
diff -r f0a9a58608a0 -r 09160c3bd179 tools/python/xen/xend/XendConfig.py
--- a/tools/python/xen/xend/XendConfig.py Fri Dec 05 15:43:08 2008 +0900
+++ b/tools/python/xen/xend/XendConfig.py Fri Dec 05 15:47:19 2008 +0900
@@ -256,6 +256,8 @@ LEGACY_CFG_TYPES = {
'on_xend_start': str,
'online_vcpus': int,
'rtc/timeoffset': str,
+ 'bootloader': str,
+ 'bootloader_args': str,
}
# Values that should be stored in xenstore's /vm/<uuid> that is used
@@ -276,6 +278,8 @@ LEGACY_XENSTORE_VM_PARAMS = [
'on_reboot',
'on_xend_start',
'on_xend_stop',
+ 'bootloader',
+ 'bootloader_args',
]
##
diff -r f0a9a58608a0 -r 09160c3bd179 tools/python/xen/xend/XendDomainInfo.py
--- a/tools/python/xen/xend/XendDomainInfo.py Fri Dec 05 15:43:08 2008 +0900
+++ b/tools/python/xen/xend/XendDomainInfo.py Fri Dec 05 15:47:19 2008 +0900
@@ -1018,7 +1018,8 @@ class XendDomainInfo:
sxprs = []
dev_num = 0
for dev_type, dev_info in self.info.all_devices_sxpr():
- if dev_type != deviceClass:
+ if (deviceClass == 'vbd' and dev_type not in ['vbd', 'tap'])
or \
+ (deviceClass != 'vbd' and dev_type != deviceClass):
continue
if deviceClass == 'vscsi':
@@ -1028,6 +1029,16 @@ class XendDomainInfo:
vscsi_devs[1].append(vscsi_dev)
dev_num = int(sxp.child_value(vscsi_dev, 'devid'))
sxprs.append([dev_num, [vscsi_devs]])
+ elif deviceClass == 'vbd':
+ dev = sxp.child_value(dev_info, 'dev')
+ if 'ioemu:' in dev:
+ (_, dev) = dev.split(':', 1)
+ try:
+ (dev_name, _) = dev.split(':', 1) # Remove ":disk" or
":cdrom"
+ except ValueError:
+ dev_name = dev
+ dev_num =
self.getDeviceController('vbd').convertToDeviceNumber(dev_name)
+ sxprs.append([dev_num, dev_info])
else:
sxprs.append([dev_num, dev_info])
dev_num += 1
diff -r f0a9a58608a0 -r 09160c3bd179 xen/common/timer.c
--- a/xen/common/timer.c Fri Dec 05 15:43:08 2008 +0900
+++ b/xen/common/timer.c Fri Dec 05 15:47:19 2008 +0900
@@ -396,7 +396,7 @@ static void timer_softirq_action(void)
/* Execute ready heap timers. */
while ( (GET_HEAP_SIZE(heap) != 0) &&
- ((t = heap[1])->expires_end < now) )
+ ((t = heap[1])->expires < now) )
{
remove_from_heap(heap, t);
t->status = TIMER_STATUS_inactive;
@@ -404,7 +404,7 @@ static void timer_softirq_action(void)
}
/* Execute ready list timers. */
- while ( ((t = ts->list) != NULL) && (t->expires_end < now) )
+ while ( ((t = ts->list) != NULL) && (t->expires < now) )
{
ts->list = t->list_next;
t->status = TIMER_STATUS_inactive;
diff -r f0a9a58608a0 -r 09160c3bd179 xen/drivers/char/ns16550.c
--- a/xen/drivers/char/ns16550.c Fri Dec 05 15:43:08 2008 +0900
+++ b/xen/drivers/char/ns16550.c Fri Dec 05 15:47:19 2008 +0900
@@ -301,6 +301,13 @@ static int check_existence(struct ns1655
static int check_existence(struct ns16550 *uart)
{
unsigned char status, scratch, scratch2, scratch3;
+
+ /*
+ * We can't poke MMIO UARTs until they get I/O remapped later. Assume that
+ * if we're getting MMIO UARTs, the arch code knows what it's doing.
+ */
+ if ( uart->io_base >= 0x10000 )
+ return 1;
/*
* Do a simple existence test first; if we fail this,
_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |