Re: [Xen-devel] [PATCH v1] x86/mm: Suppresses vm_events caused by page-walks

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 8/27/18 3:37 PM, Andrew Cooper wrote:
> On 27/08/18 13:12, Jan Beulich wrote:
>>>> For NPT, isn't there an error code bit telling you whether the
>>>> request was a user or "system" one? If not, some cheating
>>>> would be needed (derive from CPL, accepting that e.g.
>>>> descriptor table accesses would get mis-attributed), but
>>>> that's still not going to involve looking at the PTE flags.
>>> The alternative would be to simply walk (without enforcing any flags,
>>> and so making the pfec walk parameter unnecessary) to the respective
>>> address, and query for _PAGE_ACCESSED and _PAGE_DIRTY only.
>>>
>>> If _PAGE_ACCESSED is not set, set it and exit.
>>> If _PAGE_ACCESSED is set, set _PAGE_DIRTY also and exit.
>> Since it's ambiguous in the NPT case - are you talking about
>> setting the flags in the guest or host page tables? The
>> former, I'm afraid, might not be acceptable (as not always
>> being architecturally correct). In anyway feels as if we'd
>> been here before, in that this reminds me of you meaning
>> to imply from a second walk (with A already set) that it must
>> be a write access. I thought we had settled on such an
>> implication not being generally correct.
> 
> The problem that is trying to be solved is that when operating in
> non-root mode, the cpu pagewalk, when trying to set a guest A/D bit in a
> write-protected EPT page, takes an EPT violation for a write to a
> read-only page.
> 
> Manually setting the A/D bits (as appropriate) and restarting the
> instruction is sufficient for it to complete correctly.
> 
> At the moment, every time this happens, a request is sent to the
> introspection agent, and the agent calculates that it was due to
> pagetable protection, and instructs Xen to emulate the instruction. 
> This accounts for 97% (?) of the VMExits, and is unrelated to any of the
> real protections which introspection is trying to achieve.
> 
> What Razvan is looking to do is to have Xen skip the "send to the
> introspection agent" part as an optimisation, because hardware tells Xen
> (as part of the VMExit) when this condition has occurred, and the
> vm_event logic has already asked Xen to try and fix up this condition
> automatically.
> 
> What can actually be done depends on how A/D bits behave in real hardware.
> 
> Setting access bits for non-leaf entries is definitely fine, and
> speculatively setting the access bit is also explicitly permitted by the
> spec.  However, I can't find any comment on speculative dirty bits (from
> either Intel or AMD), and I've not encountered such a behaviour with the
> pagetable work I've been doing.

Thanks for the reply!

I've forgotten a piece of information that I really should have written
here: we would only set the D bit if A is already set and either the
page is writable (has _PAGE_RW set) or CR0.WP is 0 (the latter case is
admittedly more tricky).


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel