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

["Ke, Liping" <liping.ke@xxxxxxxxx>]

Keir Fraser wrote:
> 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.
>

Hi, Keir
Here you mean that this BUG_ON would never happen?
So would it be better to remove such BUG_ON or replace them with ASSERT?

Another example is
Intercept.c (c:\upstream\xen\xen\arch\x86\hvm):    BUG_ON(num >= 
MAX_IO_HANDLER);

I remember I meet the error when do HVM Sx test. When register same handler 
repeatedly several times,
this bug will be triggered. So just want to know the criteria here: Even if it 
is not good to register repeatedly,
must we panic the whole machine? After all, it is only an error contained in a 
hvm domain, is it?

Thanks a lot for your help -:)
Regards,
Criping

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