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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

~Andrew

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