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

["Aravindh Puthiyaparambil (aravindp)" <aravindp@xxxxxxxxx>]

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

Just to be certain as to where we stand:

1. The "page table RW bit flipping" solution is not viable because pausing the 
domain synchronously takes too long for many vcpus domains. Plus there is the 
added issue of vcpu vs domain heuristics. This is the case even after solving 
the page boundary and multiple page copy issues.

2. The "CR0.WP with interrupts disabled" solution is not viable because of 
NMIs. Or did I misunderstand?

Thanks,
Aravindh



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