Re: [Xen-devel] [PATCH v2 4/9] xen: arm: correctly handle vtimer traps from userspace

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 25/02/15 14:32, Ian Campbell wrote:
> On Thu, 2015-02-19 at 15:13 +0000, Ian Campbell wrote:
>> On Thu, 2015-02-19 at 14:42 +0000, Julien Grall wrote:
>>>>> Although, I think the debug message in bad_trap is useful to keep. It 
>>>>> may be handy to have the HSR and the guest stack trace printed if Xen 
>>>>> hit the condition.
>>>>
>>>> Doesn't BUG_ON include all that? It should really.
>>>
>>> Not really BUG_ON will jump into the exception mode and therefore print
>>> the HSR of the exception (breakpoint for ARM64 and undef for ARM32).
>>
>> Hrm, good point.
>>
>> Rather than reintroducing the goto idiom what about some form of
>> noreturn panic helper for checking for sane h/w state (since these
>> failures are really of the "buggy hardware" variety) e.g.
>> ASSERT_GUEST_STATE(is_32bit_domain(...)) which would dump the guest
>> state and then panic?
> 
> Here is the sort of thing I was thinking about (only converted one
> BUG_ON so far as an example, there are more candidates).
> 
> Jan, would this be useful for x86 do you think, i.e. would you like me
> to put it in lib.h with regular ASSERT? (Although making it more widely
> available concerns me due to the pretty huge caveat in its use).
> 
> Should it be on for debug=n too? (In which case it might want to become
> GUEST_BUG_ON or similar). The argument for doing so is that it would
> reduce the impact of potential security issues arising from h/w bugs (or
> spec misunderstandings), in which case I would add to the comment:

People may run a binary provided by a distribution on buggy hardware. So
the GUEST_BUG_ON seems better.

Although, I'm wondering what is the overhead of having a check at each
traps? I guess none.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel