Re: [Xen-devel] [PATCH] VMX: don't crash processing 'd' debug key

[Tim Deegan <tim@xxxxxxx>]

At 16:09 +0000 on 08 Nov (1383923399), Andrew Cooper wrote:
> On 08/11/13 16:04, Jan Beulich wrote:
> >>>> On 07.11.13 at 20:08, Tim Deegan <tim@xxxxxxx> wrote:
> >> At 10:44 +0000 on 07 Nov (1383817496), Jan Beulich wrote:
> >>> @@ -675,7 +675,17 @@ void vmx_get_segment_register(struct vcp
> >>>  {
> >>>      unsigned long attr = 0, sel = 0, limit;
> >>>  
> >>> -    vmx_vmcs_enter(v);
> >>> +    /*
> >>> +     * We may get here in the context of dump_execstate(), which may have
> >>> +     * interrupted context switching between setting "current" and
> >>> +     * vmx_do_resume() reaching the end of vmx_load_vmcs(). That would 
> >>> make
> >>> +     * all the VMREADs below fail if we don't bail right away.
> >>> +     */
> >>> +    if ( unlikely(!vmx_vmcs_enter(v)) )
> >>> +    {
> >>> +        memset(reg, 0, sizeof(*reg));
> >>> +        return;
> >> It would be nice to print something here, at least on the first
> >> instance.  Otherwise someone looking at bizarre debugkey output would
> >> have to know (and remember) about this path.
> > Did this.
> >
> >> I'd also be inclined to ASSERT that, e.g. interrupts are disabled here
> >> -- if for any reason this function ever starts corrupting register
> >> state on other paths, we'll want to know about it quickly!
> > But I'm rather hesitant to do this. If anything, we'd need per-CPU
> > state tracking whether we're in do_invalid_op()'s main switch.
> >
> > Jan
> >
> 
> I agree - the debug keys are hardly normal operation, and we don't want
> to ASSERT() in a debugkey.

But this code is also (and mode commonly) called from non-debugkey
paths, which are what the ASSERT would be guarding.

An alternative would be to plumb a 'tolerate failure' flag down the
stack and use that only from the debugkey handler.  

That kind of protection might be nice for vmx_vmcs_enter() too: make
it into vmx_vmcs_enter_try() and have vmx_vmcs_enter() be a wrapper
taht ASSERT()s success.

Tim.

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