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

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 8/27/18 3:12 PM, 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

The former (i.e. the guest) - and I agree that it might not be 100%
architecturally correct, however we can't think of a better solution
that will really work on most actual hardware.

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

Right, but the previous attempt had a different problem: for each new
[RIP:GLA] pairs we thought A was being set, and every time we had a
violation where the current [RIP:GLA] matched the previous we thought D
was being set. The main problem there was that an interrupt could have
broken RIP constancy (for lack of a better term).

This new proposal was to check if A is already set on the current
violation - and if it is, set D. While not 100% architecturally correct,
it should work with no ill-effects AFAIK.

Our use case for this is to simply clear that violation, which is not
interesting for the introspection agent - so primarily an optimization.
But also, we'd like to be able to get the violation caused by the actual
guest instruction (if it will cause one). The current patch solves the
first problem, but:

1. It doesn't solve the second problem (we lose a potentially
interesting violation).
2. It's slower to emulate the whole instruction.
3. Emulation can fail, and we end up needing to single-step the current
instruction.

I think what you are saying is that there are scenarios where A is set
already, and the fault is caused by _again_ trying to set A, in which
case we'd set D. I suppose that could happen, but I'm not sure what it
would break.


Thanks,
Razvan

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