RE: [Xen-devel] [Doc] writeup for error handling usage in XEN

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

Thanks for posting this Criping.  Since you've started this
discussion, I'd like to add a suggestion for future use:

It would be nice if ASSERT could be enabled at runtime rather
than just at compile time.  If there were a global flag
"enable_asserts" that could be enabled by a Xen grub command
line option, and the ASSERT macro always tested that global
flag before testing the assert-condition, then additional
debug/checking code could be easily enabled with a very
small runtime cost.  (The global variable would be checked
frequently enough that it would always be in cache, and
since it only changes once -- at bootime -- there would be
no cache-synchronization costs.)

> -----Original Message-----
> From: Ke, Liping [mailto:liping.ke@xxxxxxxxx]
> Sent: Thursday, December 04, 2008 12:32 AM
> To: Keir Fraser
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] [Doc] writeup for error handling usage in XEN
> 
> 
> Hi, all
> Those days, we spent some efforts to check severe error 
> handling (panic, BUG_ON, BUG, ASSERT) in XEN. We have several 
> round internal discussions as well as several mail threads 
> with Keir. Below is the discussion writeup. 
> 
> If agreed, after review, we want to place it in XEN document 
> folder or XEN wiki since we think it might be helpful to developers.
> 
> Thanks a lot for your help!
> Regards,
> Criping
> 
> [Background]
> We found error handling [Panic/BUG_ON/ASSERT/BUG] greatly impacts VM 
> Running/service time. So we did some investigation on its 
> usage in current XEN.
> Also we have some discussion with Keir. The following writeup 
> logged down them. 
> It might be useful to those who have interest in XEN's error handling.
> 
> [Current error handler in XEN]
> We have five error handlers in XEN. 
> 1) domain_crash
> 2) panic
> 3) BUG_ON
> 4) ASSERT
> 5) BUG
> domain_crash only impact the crashed domain, while other four 
> handlers will cause whole system/machine halt/reboot.
> Panic/BUG_ON/ASSERT/BUG has slight differences:
> 1) ASSERT only takes effect when DEBUG=y while other three 
> handlers takes effect
>    even if DEBUG=y is not used.
> 2) panic will halt or restart machine based on boot_option.
> 3) BUG will give more print information besides panic
> 4) BUG_ON is the "if" added version of BUG
> We can see panic, BUG, BUG_ON actually have similar functions.
> 
> [Error handler usage guideline]
> 1) domain_crash VS BUG_ON?
>    a) We should keep bug severity/scope in mind. If the bug 
> only affects 
>       one domain, use domain_crash to kill the domain instead 
> of panic 
>       whole machine.
>    b) When one error impacts the HV's overall consistency, 
> even if it only impact
>       one domain, we prefer to use BUG_ON instead. Use 
> [Panic/BUG_ON/ASSERT/BUG] 
>       will help different linked software modules to be aware 
>  of the HV's 
>       consistency constraints. Below is an example we 
> discussed with Keir 
>       which's illustrative: I8254.c/hvm.c 
> (c:\upstream\xen\xen\arch\x86\hvm):  
>       BUG_ON(bytes != 1); 
>       We want to make sure the handler for a single I/O port 
> never accessed by
>       multi-byte I/O port access. Although the illegal-access 
> is not that fatal, 
>       it still affects HV's consistency constraints. So we 
> choose BUG_ON.
> 2) How to choose between ASSERT and Panic/BUG_ON/BUG?
>    a) In order to collect more error report and save debug 
> effort, ASSERT is 
>       preferred when BUG_ON will cause too much overhead in 
> non-debug build.
>    b) For consistency and simplicity, BUG_ON should be used 
> instead of 
>       panic/BUG as they all have similar behavior
> 3) When decide to use BUG_ON, be cautious. Please add 
> necessary comments if 
>    possible. Only when severe error/HV's consistency 
> constraints broken, 
>    should we use it.
> 4) Don't use BUG_ON for checking expected BIOS 
> issues/settings such as invalid 
>    ACPI table. We can turn off those specific features in VMM 
> instead. For 
>    example,  if VT-d table is incorrect in BIOS, disable VT-d 
> in the VMM instead 
>    of using BUG_ON.
> 
> [Current Status]
> We searched [Panic/BUG_ON/ASSERT/BUG] ocurrences in XEN code 
> (cs 18498),
> agreed current usage is basically reasonable. Keir also 
> mentioned when check 
> in, he tried to make sure that its usage is qualified. Just 
> as Keir's input, XEN 
> is an inter-linked set of software modules, and BUG_ON/ASSERT 
> gives some explicit 
> description and checking of some of the more subtle interface 
> constraints between 
> them. Those error handlers will save us tremendous debug efforts.
> 
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel