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 19:44, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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.

And possibly isn't even worth fixing: We should just make sure NMIs
are what they're supposed to be - non-reentrant.

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

No, simply with the confusion such use of numeric labels causes.
They should - afaic - be limited to strictly local code regions (not
crossing non-numeric labels), and be strictly distinct (not using
the same number twice within the same local code region).

Jan


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