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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.08.18 at 13:24, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> On 8/27/18 12:11 PM, Jan Beulich wrote:
>>>>> On 24.08.18 at 20:47, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>> 619 /* EPT violation qualifications definitions */
>>> 620 typedef union ept_qual {
>>> 621     unsigned long raw;
>>> 622     struct {
>>> 623         bool read:1, write:1, fetch:1,
>>> 624             eff_read:1, eff_write:1, eff_exec:1, /* eff_user_exec */:1,
>>> 625             gla_valid:1,
>>> 626             gla_fault:1; /* Valid iff gla_valid. */
>>> 627         unsigned long /* pad */:55;
>>> 628     };
>>> 629 } __transparent__ ept_qual_t;
>>>
>>> Unfortunately, I've been told that that's not the way to go since those
>>> fields will be relevant only on newer architectures, and we'd like to be
>>> able to support even older ones. And, of course, the other thing is that
>>> they're VMX / EPT specific, and we were hoping to be able to get SVM
>>> support for free like that.
>> 
>> If this was the case (I didn't check, and you didn't provide a
>> pointer along with the "I've been told"), at the very least on
>> newer hardware correct behavior should be implemented.
> 
> Sorry for being unclear. If the question is who told me, it's been
> decided internally that the product should support older processors. If
> the question is what does "older" mean, we've checked a random Skylake
> CPU with the "if bit 22 is read as 1, the processor reports advanced
> VM-exit information for EPT violations (see Section 27.2.1). This
> reporting is done only if this bit is read as 1" method, and the
> respective bit was not set.

Thanks. If this information was indeed supplied by Intel only
after the original introduction of EPT, then - as said - when this
is available it should be used, but an alternative approach is
needed when the hardware doesn't supply the bits.

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

Jan



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