[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: Questions about current panic/BUG_ON/BUG usage in XEN



On 22/9/08 09:01, "Ke, Liping" <liping.ke@xxxxxxxxx> wrote:

> 1) Lots of parameter's checking using BUG_ON where it would be nicer if we use
> ASSERT instead?

I tend to use ASSERT() where I think the error condition is *really*
unlikely or could incur an unwanted overhead on non-debug builds. I don't
use it where I have an inkling that a BUG_ON() might fire when I don't want
it to.

> 2) Some errors which only impact a device/domain cause whole machine panic
> such as
> I8254.c (c:\upstream\xen\xen\arch\x86\hvm):    BUG_ON(bytes != 1);
> Hvm.c (c:\upstream\xen\xen\arch\x86\hvm):    BUG_ON(bytes != 1);

Both valid because they are handlers for a single I/O port, and code in
intercept.c will prevent multi-byte I/O port accesses from reaching the
handler.

> Just want to know whether we need to do some clean up jobs and made some panic
> criteria?

No, if you are seeing BUG_ON()s firing then we only remove the BUG_ON() or
panic() if its assumptions are invalid. Also panic/BUG_ON is not great if we
are relying on correct BIOS tables or timely operation of asynchronous
hardware (I'm thinking programming of VT-d engines, for example).
Assertion/BUG_ON/panic about self-consistency of the hypervisor itself
should absolutely stay as they are.

 -- Keir



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.