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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel