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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

Yes, I'll add something about it.

 -- Keir

On 04/12/2008 08:36, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> Would be nice if it also mentioned BUILD_BUG_ON(). Jan
> 
>>>> "Ke, Liping" <liping.ke@xxxxxxxxx> 04.12.08 08:32 >>>
> 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