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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 25/08/14 14:09, Jan Beulich wrote:
>>>> 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.

Indeed - NMIs are not necessarily severe problems, but the handlers are
very specifically short and touch very little.  There is no reason for
the NMI handler to ever touch data which might be mapped read-only.

Furthermore, as soon as you take a fault in the NMI handler, we are back
into re-entrant NMI territory (which I still havn't gotten around to
fixing) which will certainly cause irreparable problems for Xen.

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

I am sorry, but I don't follow this train of logic.  Has it got
something to do with the subsections used to generate the .ex_table
redirection information?

~Andrew

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