| Message ID | 20180108205052.24385-1-vincent@bernat.im (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Jan 08, 2018 at 09:50:52PM +0100, Vincent Bernat wrote: > PCID has been introduced in Sandy Bridge and, currently, KVM doesn't > object exposing it to VM as long as it is present on the host. Update > CPU model for both Sandy Bridge and Ivy Bridge accordingly. > > Signed-off-by: Vincent Bernat <vincent@bernat.im> Thanks for your patch. We need two things, though: First, confirming that all hosts where the SandyBridge and IvyBridge CPU models are runnable will support exposing PCID to guests (otherwise updating QEMU can make a runnable VM configuration suddenly stop being runnable). This can happen if the host kernel is too old. One possible way to work around this problem is to declare that QEMU 2.12 with KVM will require Linux v3.6 and newer (because we need Linux kernel commit ad756a1603c5 "KVM: VMX: Implement PCID/INVPCID for guests with EPT"). I have proposed something similar to allow us to enable kvm_pv_eoi by default, some time ago: https://www.mail-archive.com/qemu-devel@nongnu.org/msg486559.html ("qemu-doc: Document minimum kernel version for KVM in x86_64"). Second, we need compatibility entries setting pcid=off on PC_COMPAT_2_10 so we don't break compatibility on older machine-types. > --- > target/i386/cpu.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c > index 3818d7283158..bb2b4bd1b4fe 100644 > --- a/target/i386/cpu.c > +++ b/target/i386/cpu.c > @@ -1109,7 +1109,7 @@ static X86CPUDefinition builtin_x86_defs[] = { > CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_POPCNT | > CPUID_EXT_X2APIC | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 | > CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ | > - CPUID_EXT_SSE3, > + CPUID_EXT_SSE3 | CPUID_EXT_PCID, > .features[FEAT_8000_0001_EDX] = > CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX | > CPUID_EXT2_SYSCALL, > @@ -1140,7 +1140,8 @@ static X86CPUDefinition builtin_x86_defs[] = { > CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_POPCNT | > CPUID_EXT_X2APIC | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 | > CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ | > - CPUID_EXT_SSE3 | CPUID_EXT_F16C | CPUID_EXT_RDRAND, > + CPUID_EXT_SSE3 | CPUID_EXT_F16C | CPUID_EXT_RDRAND | > + CPUID_EXT_PCID, > .features[FEAT_7_0_EBX] = > CPUID_7_0_EBX_FSGSBASE | CPUID_7_0_EBX_SMEP | > CPUID_7_0_EBX_ERMS, > -- > 2.15.1 >
----- Original Message ----- > From: "Eduardo Habkost" <ehabkost@redhat.com> > To: "Vincent Bernat" <vincent@bernat.im> > Cc: "Paolo Bonzini" <pbonzini@redhat.com>, "Richard Henderson" <rth@twiddle.net>, qemu-devel@nongnu.org > Sent: Monday, January 8, 2018 10:16:23 PM > Subject: Re: [PATCH] target-i386: add pcid to both Sandy Bridge and Ivy Bridge > > On Mon, Jan 08, 2018 at 09:50:52PM +0100, Vincent Bernat wrote: > > PCID has been introduced in Sandy Bridge and, currently, KVM doesn't > > object exposing it to VM as long as it is present on the host. Update > > CPU model for both Sandy Bridge and Ivy Bridge accordingly. > > > > Signed-off-by: Vincent Bernat <vincent@bernat.im> > > Thanks for your patch. > > We need two things, though: > > First, confirming that all hosts where the SandyBridge and > IvyBridge CPU models are runnable will support exposing PCID to > guests (otherwise updating QEMU can make a runnable VM > configuration suddenly stop being runnable). This can happen if > the host kernel is too old. I've been reading it's also Westmere. I'll check more carefully tomorrow. The difference between consumer and server SKUs is important too. > One possible way to work around this problem is to declare that > QEMU 2.12 with KVM will require Linux v3.6 and newer (because we > need Linux kernel commit ad756a1603c5 "KVM: VMX: Implement > PCID/INVPCID for guests with EPT"). Note that PCID is still not supported for guests without EPT, so this would break ept=0 with recent "-cpu" models. I'm not sure of a way to fix it; probably it just has to be documented. Paolo
On Mon, Jan 08, 2018 at 05:37:16PM -0500, Paolo Bonzini wrote: > > > ----- Original Message ----- > > From: "Eduardo Habkost" <ehabkost@redhat.com> > > To: "Vincent Bernat" <vincent@bernat.im> > > Cc: "Paolo Bonzini" <pbonzini@redhat.com>, "Richard Henderson" <rth@twiddle.net>, qemu-devel@nongnu.org > > Sent: Monday, January 8, 2018 10:16:23 PM > > Subject: Re: [PATCH] target-i386: add pcid to both Sandy Bridge and Ivy Bridge > > > > On Mon, Jan 08, 2018 at 09:50:52PM +0100, Vincent Bernat wrote: > > > PCID has been introduced in Sandy Bridge and, currently, KVM doesn't > > > object exposing it to VM as long as it is present on the host. Update > > > CPU model for both Sandy Bridge and Ivy Bridge accordingly. > > > > > > Signed-off-by: Vincent Bernat <vincent@bernat.im> > > > > Thanks for your patch. > > > > We need two things, though: > > > > First, confirming that all hosts where the SandyBridge and > > IvyBridge CPU models are runnable will support exposing PCID to > > guests (otherwise updating QEMU can make a runnable VM > > configuration suddenly stop being runnable). This can happen if > > the host kernel is too old. > > I've been reading it's also Westmere. I'll check more carefully tomorrow. > The difference between consumer and server SKUs is important too. > > > One possible way to work around this problem is to declare that > > QEMU 2.12 with KVM will require Linux v3.6 and newer (because we > > need Linux kernel commit ad756a1603c5 "KVM: VMX: Implement > > PCID/INVPCID for guests with EPT"). > > Note that PCID is still not supported for guests without EPT, so > this would break ept=0 with recent "-cpu" models. I'm not sure of > a way to fix it; probably it just has to be documented. GET_SUPPORTED_CPUID seems to still return PCID as supported without EPT, doesn't it? (BTW, is PCID useful for KPTI performance without INVPCID?)
----- Original Message ----- > From: "Eduardo Habkost" <ehabkost@redhat.com> > To: "Paolo Bonzini" <pbonzini@redhat.com> > Cc: "Vincent Bernat" <vincent@bernat.im>, "Richard Henderson" <rth@twiddle.net>, qemu-devel@nongnu.org > Sent: Monday, January 8, 2018 11:56:25 PM > Subject: Re: [PATCH] target-i386: add pcid to both Sandy Bridge and Ivy Bridge > > On Mon, Jan 08, 2018 at 05:37:16PM -0500, Paolo Bonzini wrote: > > > > > > ----- Original Message ----- > > > From: "Eduardo Habkost" <ehabkost@redhat.com> > > > To: "Vincent Bernat" <vincent@bernat.im> > > > Cc: "Paolo Bonzini" <pbonzini@redhat.com>, "Richard Henderson" > > > <rth@twiddle.net>, qemu-devel@nongnu.org > > > Sent: Monday, January 8, 2018 10:16:23 PM > > > Subject: Re: [PATCH] target-i386: add pcid to both Sandy Bridge and Ivy > > > Bridge > > > > > > On Mon, Jan 08, 2018 at 09:50:52PM +0100, Vincent Bernat wrote: > > > > PCID has been introduced in Sandy Bridge and, currently, KVM doesn't > > > > object exposing it to VM as long as it is present on the host. Update > > > > CPU model for both Sandy Bridge and Ivy Bridge accordingly. > > > > > > > > Signed-off-by: Vincent Bernat <vincent@bernat.im> > > > > > > Thanks for your patch. > > > > > > We need two things, though: > > > > > > First, confirming that all hosts where the SandyBridge and > > > IvyBridge CPU models are runnable will support exposing PCID to > > > guests (otherwise updating QEMU can make a runnable VM > > > configuration suddenly stop being runnable). This can happen if > > > the host kernel is too old. > > > > I've been reading it's also Westmere. I'll check more carefully tomorrow. > > The difference between consumer and server SKUs is important too. > > > > > One possible way to work around this problem is to declare that > > > QEMU 2.12 with KVM will require Linux v3.6 and newer (because we > > > need Linux kernel commit ad756a1603c5 "KVM: VMX: Implement > > > PCID/INVPCID for guests with EPT"). > > > > Note that PCID is still not supported for guests without EPT, so > > this would break ept=0 with recent "-cpu" models. I'm not sure of > > a way to fix it; probably it just has to be documented. > > GET_SUPPORTED_CPUID seems to still return PCID as supported > without EPT, doesn't it? Indeed it is! It will also be useful for KPTI performance without INVPCID, but it won't be useful without EPT. Paolo > (BTW, is PCID useful for KPTI performance without INVPCID?)
On Mon, Jan 08, 2018 at 06:09:30PM -0500, Paolo Bonzini wrote: > > > ----- Original Message ----- > > From: "Eduardo Habkost" <ehabkost@redhat.com> > > To: "Paolo Bonzini" <pbonzini@redhat.com> > > Cc: "Vincent Bernat" <vincent@bernat.im>, "Richard Henderson" <rth@twiddle.net>, qemu-devel@nongnu.org > > Sent: Monday, January 8, 2018 11:56:25 PM > > Subject: Re: [PATCH] target-i386: add pcid to both Sandy Bridge and Ivy Bridge > > > > On Mon, Jan 08, 2018 at 05:37:16PM -0500, Paolo Bonzini wrote: > > > > > > > > > ----- Original Message ----- > > > > From: "Eduardo Habkost" <ehabkost@redhat.com> > > > > To: "Vincent Bernat" <vincent@bernat.im> > > > > Cc: "Paolo Bonzini" <pbonzini@redhat.com>, "Richard Henderson" > > > > <rth@twiddle.net>, qemu-devel@nongnu.org > > > > Sent: Monday, January 8, 2018 10:16:23 PM > > > > Subject: Re: [PATCH] target-i386: add pcid to both Sandy Bridge and Ivy > > > > Bridge > > > > > > > > On Mon, Jan 08, 2018 at 09:50:52PM +0100, Vincent Bernat wrote: > > > > > PCID has been introduced in Sandy Bridge and, currently, KVM doesn't > > > > > object exposing it to VM as long as it is present on the host. Update > > > > > CPU model for both Sandy Bridge and Ivy Bridge accordingly. > > > > > > > > > > Signed-off-by: Vincent Bernat <vincent@bernat.im> > > > > > > > > Thanks for your patch. > > > > > > > > We need two things, though: > > > > > > > > First, confirming that all hosts where the SandyBridge and > > > > IvyBridge CPU models are runnable will support exposing PCID to > > > > guests (otherwise updating QEMU can make a runnable VM > > > > configuration suddenly stop being runnable). This can happen if > > > > the host kernel is too old. > > > > > > I've been reading it's also Westmere. I'll check more carefully tomorrow. > > > The difference between consumer and server SKUs is important too. > > > > > > > One possible way to work around this problem is to declare that > > > > QEMU 2.12 with KVM will require Linux v3.6 and newer (because we > > > > need Linux kernel commit ad756a1603c5 "KVM: VMX: Implement > > > > PCID/INVPCID for guests with EPT"). > > > > > > Note that PCID is still not supported for guests without EPT, so > > > this would break ept=0 with recent "-cpu" models. I'm not sure of > > > a way to fix it; probably it just has to be documented. > > > > GET_SUPPORTED_CPUID seems to still return PCID as supported > > without EPT, doesn't it? > > Indeed it is! It will also be useful for KPTI performance without > INVPCID, but it won't be useful without EPT. Well, I can live with "not useful without EPT", as long as it doesn't mean "broken without EPT". It looks like we can safely enable it, as long as: 2) we confirm if all Intel Westmere/SandyBridge/IvyBridge CPUs have PCID; 1) QEMU documentation states that it requires Linux v3.6 or newer for KVM.
❦ 8 janvier 2018 17:37 -0500, Paolo Bonzini <pbonzini@redhat.com> : >> One possible way to work around this problem is to declare that >> QEMU 2.12 with KVM will require Linux v3.6 and newer (because we >> need Linux kernel commit ad756a1603c5 "KVM: VMX: Implement >> PCID/INVPCID for guests with EPT"). > > Note that PCID is still not supported for guests without EPT, so > this would break ept=0 with recent "-cpu" models. I'm not sure of > a way to fix it; probably it just has to be documented. From the above patch, it seems only INVPCID needs EPT. KVM exposes PCID whenever it is present on the host.
❦ 8 janvier 2018 20:56 -0200, Eduardo Habkost <ehabkost@redhat.com> :
> (BTW, is PCID useful for KPTI performance without INVPCID?)
It seems it is:
https://mail-archive.com/linux-kernel@vger.kernel.org/msg1576774.html
❦ 8 janvier 2018 21:19 -0200, Eduardo Habkost <ehabkost@redhat.com> : >> > GET_SUPPORTED_CPUID seems to still return PCID as supported >> > without EPT, doesn't it? >> >> Indeed it is! It will also be useful for KPTI performance without >> INVPCID, but it won't be useful without EPT. > > Well, I can live with "not useful without EPT", as long as it > doesn't mean "broken without EPT". It looks like we can safely > enable it, as long as: > > 2) we confirm if all Intel Westmere/SandyBridge/IvyBridge CPUs > have PCID; I didn't find an authoritative information about that on Intel website. Various sites indeed says the feature was introduced in Westmere. And Greg KH mentions Westmere here too: https://mail-archive.com/linux-kernel@vger.kernel.org/msg1576774.html > 1) QEMU documentation states that it requires Linux v3.6 or newer > for KVM. I have updated the patch and sent it in a new thread. It's now based on x86-next.
diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 3818d7283158..bb2b4bd1b4fe 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -1109,7 +1109,7 @@ static X86CPUDefinition builtin_x86_defs[] = { CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_POPCNT | CPUID_EXT_X2APIC | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ | - CPUID_EXT_SSE3, + CPUID_EXT_SSE3 | CPUID_EXT_PCID, .features[FEAT_8000_0001_EDX] = CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL, @@ -1140,7 +1140,8 @@ static X86CPUDefinition builtin_x86_defs[] = { CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_POPCNT | CPUID_EXT_X2APIC | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ | - CPUID_EXT_SSE3 | CPUID_EXT_F16C | CPUID_EXT_RDRAND, + CPUID_EXT_SSE3 | CPUID_EXT_F16C | CPUID_EXT_RDRAND | + CPUID_EXT_PCID, .features[FEAT_7_0_EBX] = CPUID_7_0_EBX_FSGSBASE | CPUID_7_0_EBX_SMEP | CPUID_7_0_EBX_ERMS,
PCID has been introduced in Sandy Bridge and, currently, KVM doesn't object exposing it to VM as long as it is present on the host. Update CPU model for both Sandy Bridge and Ivy Bridge accordingly. Signed-off-by: Vincent Bernat <vincent@bernat.im> --- target/i386/cpu.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)