Re: [RFT] mmu optimizations branch

Avi Kivity
2007-01-02T17:09:01Z

Ingo Molnar wrote:
> * Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>
>
>>> unfortunately 0xc011f7f3 is in native_write_msr(), which isnt very
>>> helpful. (i have CONFIG_PARAVIRT enabled in the -rt guest and host
>>> kernels) But the MSR values suggest that this is the NMI watchdog
>>> thing again, trying to program MSR_ARCH_PERFMON_EVENTSEL0 and
>>> MSR_ARCH_PERFMON_PERFCTR0, but this time Linux recovered due to a
>>> more robust MSR handling. The guest disabled the NMI watchdog with:
>>>
>>> Testing NMI watchdog ... CPU#0: NMI appears to be stuck (0->0)!
>>>
>>> the FC6 installer hang that i saw with earlier MMU-branch snapshots
>>> is fixed.
>>>
>> Good. Handling the counter well would have been very difficult,
>> especially if attempting to support cross migration.
>>
>
> as far as the NMI watchdog goes, it's in fact better to keep it disabled
> this way - it's not like the guest context could 'lock up' in an
> undebuggable way. Any NMI activity in the guest context would be pretty
> pointless. I'd suggest simulating a non-working performance counter:
> i.e. dont inject a #GPF when doing the wrmsr, and maybe preserve the
> values that were written into the MSR register, but otherwise dont try
> to implement the functionality by injecting NMIs. Worst-case this could
> result in user-space debugging tools seeing non-working
> performance-counter functionality.
>
>

My worry is that when emulating an msr incorrectly, software can fail
without any clue as to what went wrong. I'll add the emulation as you
suggest bug with a printk() to warn that we're bending the rules.