Re: [Xen-devel] [PATCH RFC v2 1/4] x86/mm: Shadow and p2m changes for PV mem_access

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.08.14 at 14:49, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 25/08/14 08:33, Jan Beulich wrote:
>>>>> On 22.08.14 at 22:02, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 22/08/14 20:48, Aravindh Puthiyaparambil (aravindp) wrote:
>>>> Sigh, if only I could bound the CR0.WP solution :-(
>>> I wonder whether, in the case that mem_access is enabled, it would be
>>> reasonable to perform the CR0.WP sections with interrupts disabled?
>> Which still wouldn't cover NMIs (albeit we might be able to live with
>> that).
> 
> NMIs and MCEs are short, possibly raise softirqs, or call panic().  We
> have much larger problems in general if the lack of CR0.WP would
> adversely affect the NMI or MCE paths.

I agree for MCEs, but NMIs don't necessarily mean severe problems.

>> But what's worse - taking faults with interrupts disabled
>> requires extra care, and annotating code normally run with
>> interrupts enabled with the special .ex_table.pre annotations
>> doesn't seem like a very nice route, as that could easily hide other
>> problems in the future.
> 
> Does it?  In exception_with_ints_disabled, if the .ex_table.pre search
> fails, we jump back into the regular handler after the sti label and
> continue with the regular handler.
> 
> This requires no more careful handling than existing constructs such as
> wrmsr_safe() inside a spinlock_irq{,save}() region.

Oh, indeed. Which points out that one shouldn't
- use the same numeric label twice in a row, and even inside the
  same function
- jump to a numeric label across one or more non-numeric ones

Jan


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