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
|
Home