ia64/xen-unstable

changeset 18869:09160c3bd179

merge with xen-unstable.hg
author Isaku Yamahata <yamahata@valinux.co.jp>
date Fri Dec 05 15:47:19 2008 +0900 (2008-12-05)
parents f0a9a58608a0 1b173394f815
children dd7ac569579a 99f01b8184c7
files
line diff
     1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/misc/xen-error-handling.txt	Fri Dec 05 15:47:19 2008 +0900
     1.3 @@ -0,0 +1,88 @@
     1.4 +Error handling in Xen
     1.5 +---------------------
     1.6 +
     1.7 +1. domain_crash()
     1.8 +-----------------
     1.9 +Crash the specified domain due to buggy or unsupported behaviour of the
    1.10 +guest. This should not be used where the hypervisor itself is in
    1.11 +error, even if the scope of that error affects only a single
    1.12 +domain. BUG() is a more appropriate failure method for hypervisor
    1.13 +bugs. To repeat: domain_crash() is the correct response for erroneous
    1.14 +or unsupported *guest* behaviour!
    1.15 +
    1.16 +Note that this should be used in most cases in preference to
    1.17 +domain_crash_synchronous(): domain_crash() returns to the caller,
    1.18 +allowing the crash to be deferred for the currently executing VCPU
    1.19 +until certain resources (notably, spinlocks) have been released.
    1.20 +
    1.21 +Example usages:
    1.22 + * Unrecoverable guest kernel stack overflows
    1.23 + * Unsupported corners of HVM device models
    1.24 +
    1.25 +2. BUG()
    1.26 +--------
    1.27 +Crashes the host system with an informative file/line error message
    1.28 +and a backtrace. Use this to check consistency assumptions within the
    1.29 +hypervisor.
    1.30 +
    1.31 +Be careful not to use BUG() (or BUG_ON(), or ASSERT()) for failures
    1.32 +*outside* the hypervisor software -- in particular, guest bugs (where
    1.33 +domain_crash() is more appropriate) or non-critical BIOS or hardware
    1.34 +errors (where retry or feature disable are more appropriate).
    1.35 +
    1.36 +Example usage: In arch/x86/hvm/i8254.c an I/O port handler includes
    1.37 +the check BUG_ON(bytes != 1). We choose this extreme reaction to the
    1.38 +unexpected error case because, although it could be handled by failing
    1.39 +the I/O access or crashing the domain, it is indicative of an
    1.40 +unexpected inconsistency in the hypervisor itself (since the I/O
    1.41 +handler was only registered for single-byte accesses).
    1.42 +
    1.43 +
    1.44 +3. BUG_ON()
    1.45 +-----------
    1.46 +BUG_ON(...) is merely a convenient short form for "if (...) BUG()". It
    1.47 +is most commonly used as an 'always on' alternative to ASSERT().
    1.48 +
    1.49 +
    1.50 +4. ASSERT()
    1.51 +-----------
    1.52 +Similar to BUG_ON(), except that it is only enabled for debug builds
    1.53 +of the hypervisor. Typically ASSERT() is used only where the (usually
    1.54 +small) overheads of an always-on debug check might be considered
    1.55 +excessive. A good example might be within inner loops of time-critical
    1.56 +functions, or where an assertion is extreme paranoia (considered
    1.57 +*particularly* unlikely ever to fail).
    1.58 +
    1.59 +In general, if in doubt, use BUG_ON() in preference to ASSERT().
    1.60 +
    1.61 +
    1.62 +5. panic()
    1.63 +----------
    1.64 +Like BUG() and ASSERT() this will crash and reboot the host
    1.65 +system. However it does this after printing only an error message with
    1.66 +no extra diagnostic information such as a backtrace. panic() is
    1.67 +generally used where an unsupported system configuration is detected,
    1.68 +particularly during boot, and where extra diagnostic information about
    1.69 +CPU context would not be useful. It may also be used before exception
    1.70 +handling is enabled during Xen bootstrap (on x86, BUG() and ASSERT()
    1.71 +depend on Xen's exception-handling capabilities).
    1.72 +
    1.73 +Example usage: Most commonly for out-of-memory errors during
    1.74 +bootstrap. The failure is unexpected since a host should always have
    1.75 +enough memory to boot Xen, but if the failure does occur then the
    1.76 +context of the failed memory allocation itself is not very
    1.77 +interesting.
    1.78 +
    1.79 +
    1.80 +6. Feature disable
    1.81 +------------------
    1.82 +A possible approach to dealing with boot-time errors, rather than
    1.83 +crashing the hypervisor. It's particularly appropriate when parsing
    1.84 +non-critical BIOS tables and detecting extended hardware features.
    1.85 +
    1.86 +
    1.87 +7. BUILD_BUG_ON()
    1.88 +-----------------
    1.89 +Useful for assertions which can be evaluated at compile time. For
    1.90 +example, making explicit assumptions about size and alignment of C
    1.91 +structures.
     2.1 --- a/tools/python/xen/xend/XendConfig.py	Fri Dec 05 15:43:08 2008 +0900
     2.2 +++ b/tools/python/xen/xend/XendConfig.py	Fri Dec 05 15:47:19 2008 +0900
     2.3 @@ -256,6 +256,8 @@ LEGACY_CFG_TYPES = {
     2.4      'on_xend_start': str,
     2.5      'online_vcpus':  int,
     2.6      'rtc/timeoffset': str,
     2.7 +    'bootloader':    str,
     2.8 +    'bootloader_args': str,
     2.9  }
    2.10  
    2.11  # Values that should be stored in xenstore's /vm/<uuid> that is used
    2.12 @@ -276,6 +278,8 @@ LEGACY_XENSTORE_VM_PARAMS = [
    2.13      'on_reboot',
    2.14      'on_xend_start',
    2.15      'on_xend_stop',
    2.16 +    'bootloader',
    2.17 +    'bootloader_args',
    2.18  ]
    2.19  
    2.20  ##
     3.1 --- a/tools/python/xen/xend/XendDomainInfo.py	Fri Dec 05 15:43:08 2008 +0900
     3.2 +++ b/tools/python/xen/xend/XendDomainInfo.py	Fri Dec 05 15:47:19 2008 +0900
     3.3 @@ -1018,7 +1018,8 @@ class XendDomainInfo:
     3.4              sxprs = []
     3.5              dev_num = 0
     3.6              for dev_type, dev_info in self.info.all_devices_sxpr():
     3.7 -                if dev_type != deviceClass:
     3.8 +                if (deviceClass == 'vbd' and dev_type not in ['vbd', 'tap']) or \
     3.9 +                   (deviceClass != 'vbd' and dev_type != deviceClass):
    3.10                      continue
    3.11  
    3.12                  if deviceClass == 'vscsi':
    3.13 @@ -1028,6 +1029,16 @@ class XendDomainInfo:
    3.14                          vscsi_devs[1].append(vscsi_dev)
    3.15                          dev_num = int(sxp.child_value(vscsi_dev, 'devid'))
    3.16                      sxprs.append([dev_num, [vscsi_devs]])
    3.17 +                elif deviceClass == 'vbd':
    3.18 +                    dev = sxp.child_value(dev_info, 'dev')
    3.19 +                    if 'ioemu:' in dev:
    3.20 +                        (_, dev) = dev.split(':', 1)
    3.21 +                    try:
    3.22 +                        (dev_name, _) = dev.split(':', 1)  # Remove ":disk" or ":cdrom"
    3.23 +                    except ValueError:
    3.24 +                        dev_name = dev
    3.25 +                    dev_num = self.getDeviceController('vbd').convertToDeviceNumber(dev_name)
    3.26 +                    sxprs.append([dev_num, dev_info])
    3.27                  else:
    3.28                      sxprs.append([dev_num, dev_info])
    3.29                      dev_num += 1
     4.1 --- a/xen/common/timer.c	Fri Dec 05 15:43:08 2008 +0900
     4.2 +++ b/xen/common/timer.c	Fri Dec 05 15:47:19 2008 +0900
     4.3 @@ -396,7 +396,7 @@ static void timer_softirq_action(void)
     4.4  
     4.5      /* Execute ready heap timers. */
     4.6      while ( (GET_HEAP_SIZE(heap) != 0) &&
     4.7 -            ((t = heap[1])->expires_end < now) )
     4.8 +            ((t = heap[1])->expires < now) )
     4.9      {
    4.10          remove_from_heap(heap, t);
    4.11          t->status = TIMER_STATUS_inactive;
    4.12 @@ -404,7 +404,7 @@ static void timer_softirq_action(void)
    4.13      }
    4.14  
    4.15      /* Execute ready list timers. */
    4.16 -    while ( ((t = ts->list) != NULL) && (t->expires_end < now) )
    4.17 +    while ( ((t = ts->list) != NULL) && (t->expires < now) )
    4.18      {
    4.19          ts->list = t->list_next;
    4.20          t->status = TIMER_STATUS_inactive;
     5.1 --- a/xen/drivers/char/ns16550.c	Fri Dec 05 15:43:08 2008 +0900
     5.2 +++ b/xen/drivers/char/ns16550.c	Fri Dec 05 15:47:19 2008 +0900
     5.3 @@ -303,6 +303,13 @@ static int check_existence(struct ns1655
     5.4      unsigned char status, scratch, scratch2, scratch3;
     5.5  
     5.6      /*
     5.7 +     * We can't poke MMIO UARTs until they get I/O remapped later. Assume that
     5.8 +     * if we're getting MMIO UARTs, the arch code knows what it's doing.
     5.9 +     */
    5.10 +    if ( uart->io_base >= 0x10000 )
    5.11 +        return 1;
    5.12 +
    5.13 +    /*
    5.14       * Do a simple existence test first; if we fail this,
    5.15       * there's no point trying anything else.
    5.16       */