[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3dab0fd6-be64-2c72-1ee9-ecd040fd43b5@redhat.com>
Date: Fri, 3 Aug 2018 22:17:02 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Peter Shier <pshier@...gle.com>, tglx@...utronix.de
Cc: mingo@...hat.com, hpa@...or.com, x86@...nel.org, bp@...e.de,
konrad.wilk@...cle.com, dwmw@...zon.co.uk,
Jim Mattson <jmattson@...gle.com>,
linux-kernel@...r.kernel.org, Peter Feiner <pfeiner@...gle.com>,
kvm@...r.kernel.org
Subject: Re: [PATCH] proc: added ept_ad flag to /proc/cpuinfo
On 02/08/2018 21:33, Peter Shier wrote:
>
>> > The Intel Haswell architecture has an EPT feature whereby the access &
>> > dirty bits in EPT entries are updated without taking a guest exit.
>>
>> Why would this be Haswell specific?
>>
>> Aside of that I don't see what this has to do with exits. From the SDM:
>>
>> " * If bit 21 is read as 1, accessed and dirty flags for EPT are
>> supported (see Section 28.2.4)"
>>
>> And nothing in 28.2.4 says anything about exits. It's all about whether the
>> feature is supported or not. If it is supported it can be enabled in EPTP.
Right, if it's not supported KVM instead has to use the R/W/X permission
bits to emulate accessed and dirty bits, taking an exit on every update.
But then it seems to me that you're more interested in the KVM behavior
than the processor behavior, and then the information you need is
already in the /sys/modules/kvm_intel/parameters directory. (Most
processor features have a parameter so that it's possible to test code
paths for old processors). I don't particularly see a need to add them
in /proc/cpuinfo.
Paolo
> Thank you Thomas. I missed what I think is your fundamental point
> regarding duplication created by this patch between CPU feature bits
> and KVM's consumption of the IA32_VMX_EPT_VPID_CAP MSR.
>
> Should all the features in this MSR be exposed via CPU feature bits
> and should KVM consume only from there rather than reading the MSR
> directly? There are 16 feature bits in the MSR per SDM Vol 3d section
> A.10.
>
Powered by blists - more mailing lists