From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Shier <pshier@google.com>, tglx@linutronix.de
Cc: mingo@redhat.com, hpa@zytor.com, x86@kernel.org, bp@suse.de,
konrad.wilk@oracle.com, dwmw@amazon.co.uk,
Jim Mattson <jmattson@google.com>,
linux-kernel@vger.kernel.org, Peter Feiner <pfeiner@google.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH] proc: added ept_ad flag to /proc/cpuinfo
Date: Fri, 3 Aug 2018 22:17:02 +0200 [thread overview]
Message-ID: <3dab0fd6-be64-2c72-1ee9-ecd040fd43b5@redhat.com> (raw)
In-Reply-To: <CACwOFJSta=jM7LDiEtT-V_UnCwhggurDa4B+dViqLcdyPvYGxQ@mail.gmail.com>
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.
>
prev parent reply other threads:[~2018-08-03 20:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-30 21:12 Peter Shier
2018-07-30 22:12 ` Thomas Gleixner
2018-08-01 17:44 ` Peter Shier
2018-08-01 18:07 ` Thomas Gleixner
2018-08-02 19:33 ` Peter Shier
2018-08-03 10:02 ` Thomas Gleixner
2018-08-03 20:17 ` Paolo Bonzini [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3dab0fd6-be64-2c72-1ee9-ecd040fd43b5@redhat.com \
--to=pbonzini@redhat.com \
--cc=bp@suse.de \
--cc=dwmw@amazon.co.uk \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=konrad.wilk@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pfeiner@google.com \
--cc=pshier@google.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®