Reviving an old thread here.
On Wed, Jul 06, 2016 at 11:27:16PM +0200, Paolo Bonzini wrote:
> On 06/07/2016 19:34, Eduardo Habkost wrote:
> >> > Nothing is needed in the kernel actually. You can skip the intercept
> >> > by running the guest with MSR_TSC_AUX set to the guest's expected value.
> >> > Which KVM does, except that it's botched so I need to apply the
> >> > patch in https://lkml.org/lkml/2016/4/13/802.
> > Do you mean -cpu Opteron_G*,+rdtscp will be buggy on Linux v4.5?
> > (v4.5 reports rdtscp as supported in GET_SUPPORTED_CPUID)
> >
> > Can we do something to make QEMU detect the buggy kernel before
> > allowing rdtscp to be enabled, or should we just tell people to
> > upgrade their kernel?
>
> We usually just tell people to use the latest stable kernel.
>
> Adding new CPU models is not a big deal, in fact it's almost easier than
> getting compat properties right. :)
Ok, can we finally revert
33b5e8c03ae7 ("target-i386: Disable rdtscp on Opteron_G* CPU models")
in the qemu tree?
Three years should be enough by now for
46896c73c1a4 ("KVM: svm: add support for RDTSCP")
to have percolated downstream.
Btw, its commit message talks about Linux not using RDTSCP but that will
change soon. :-)
Oh, and the EPYC qemu CPU model has CPUID_EXT2_RDTSCP and works just
fine when patching in RDTSCP:
[ 0.543197] apply_alternatives: feat: 3*32+18, old: (read_tsc+0x0/0x10 (ffffffff8101d1c0) len: 5), repl: (ffffffff824e6d33, len: 5), pad: 3
[ 0.544448] ffffffff8101d1c0: old_insn: 0f 31 90 90 90
[ 0.545023] ffffffff824e6d33: rpl_insn: 0f ae e8 0f 31
[ 0.545598] ffffffff8101d1c0: final_insn: 0f ae e8 0f 31
[ 0.546193] apply_alternatives: feat: 1*32+27, old: (read_tsc+0x0/0x10 (ffffffff8101d1c0) len: 5), repl: (ffffffff824e6d38, len: 3), pad: 3
[ 0.547195] ffffffff8101d1c0: old_insn: 0f ae e8 0f 31
[ 0.547775] ffffffff824e6d38: rpl_insn: 0f 01 f9
[ 0.548307] ffffffff8101d1c0: final_insn: 0f 01 f9 66 90
That final_insn which gets patched to by the alternatives is
ffffffff8101d1c0: 0f 01 f9 rdtscp
ffffffff8101d1c3: 66 90 xchg %ax,%ax
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Mon, Dec 10, 2018 at 04:37:30PM -0200, Eduardo Habkost wrote:
> It isn't as simply as reverting commit 33b5e8c03ae7, but we can
> surely re-add RDTSCP on pc-*-4.0 and newer.
Sure. If you could only point me to an example how to add that to
pc-*-4.0 and newer, I'll gladly cook up a patch and test it.
> I thought we added documentation mentioning the minimum kernel
> version required by QEMU, but I can't find it. In either case,
> it seems reasonable to require Linux 4.5 or newer on newer
> machine-types.
When you say "require" does that mean, one puts it in a text file
somewhere in the qemu sources or do we enforce it somehow?
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Mon, Dec 10, 2018 at 07:13:28PM +0100, Borislav Petkov wrote:
> Reviving an old thread here.
>
> On Wed, Jul 06, 2016 at 11:27:16PM +0200, Paolo Bonzini wrote:
> > On 06/07/2016 19:34, Eduardo Habkost wrote:
> > >> > Nothing is needed in the kernel actually. You can skip the intercept
> > >> > by running the guest with MSR_TSC_AUX set to the guest's expected value.
> > >> > Which KVM does, except that it's botched so I need to apply the
> > >> > patch in https://lkml.org/lkml/2016/4/13/802.
> > > Do you mean -cpu Opteron_G*,+rdtscp will be buggy on Linux v4.5?
> > > (v4.5 reports rdtscp as supported in GET_SUPPORTED_CPUID)
> > >
> > > Can we do something to make QEMU detect the buggy kernel before
> > > allowing rdtscp to be enabled, or should we just tell people to
> > > upgrade their kernel?
> >
> > We usually just tell people to use the latest stable kernel.
> >
> > Adding new CPU models is not a big deal, in fact it's almost easier than
> > getting compat properties right. :)
>
> Ok, can we finally revert
>
> 33b5e8c03ae7 ("target-i386: Disable rdtscp on Opteron_G* CPU models")
>
> in the qemu tree?
>
> Three years should be enough by now for
>
> 46896c73c1a4 ("KVM: svm: add support for RDTSCP")
>
> to have percolated downstream.
That's Linux v4.5, released in March 2016.
It isn't as simply as reverting commit 33b5e8c03ae7, but we can
surely re-add RDTSCP on pc-*-4.0 and newer.
I thought we added documentation mentioning the minimum kernel
version required by QEMU, but I can't find it. In either case,
it seems reasonable to require Linux 4.5 or newer on newer
machine-types.
--
Eduardo
On Mon, Dec 10, 2018 at 05:06:00PM -0200, Eduardo Habkost wrote:
> I mean documenting it. We already have code that will print
> warnings if a feature isn't available.
>
> See my previous attempt to document the minimum kernel version
> at <https://www.mail-archive.com/[email protected]/msg486559.html>.
Something like this?
I still have no clue how to add RDTSCP on pc-*-4.0 and newer.
Thx.
---
diff --git a/qemu-doc.texi b/qemu-doc.texi
index f7ad1dfe4b69..913b2ef68d54 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -37,6 +37,7 @@
* QEMU System emulator for non PC targets::
* QEMU Guest Agent::
* QEMU User space emulator::
+* System requirements::
* Implementation notes::
* Deprecated features::
* Supported build platforms::
@@ -2813,6 +2814,13 @@ Act as if the host page size was 'pagesize' bytes
Run the emulation in single step mode.
@end table
+@node System requirements
+@chapter System requirements
+
+@section KVM kernel module
+
+On x86_64 hosts, the default set of CPU features enabled by the KVM accelerator
+require the host to be running Linux v4.5 or newer.
@include qemu-tech.texi
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index f81d35e1f914..34bb5b74136d 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2706,7 +2706,6 @@ static X86CPUDefinition builtin_x86_defs[] = {
CPUID_DE | CPUID_FP87,
.features[FEAT_1_ECX] =
CPUID_EXT_CX16 | CPUID_EXT_SSE3,
- /* Missing: CPUID_EXT2_RDTSCP */
.features[FEAT_8000_0001_EDX] =
CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
.features[FEAT_8000_0001_ECX] =
@@ -2730,9 +2729,9 @@ static X86CPUDefinition builtin_x86_defs[] = {
.features[FEAT_1_ECX] =
CPUID_EXT_POPCNT | CPUID_EXT_CX16 | CPUID_EXT_MONITOR |
CPUID_EXT_SSE3,
- /* Missing: CPUID_EXT2_RDTSCP */
.features[FEAT_8000_0001_EDX] =
- CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
+ CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL |
+ CPUID_EXT2_RDTSCP,
.features[FEAT_8000_0001_ECX] =
CPUID_EXT3_MISALIGNSSE | CPUID_EXT3_SSE4A |
CPUID_EXT3_ABM | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
@@ -2757,10 +2756,9 @@ static X86CPUDefinition builtin_x86_defs[] = {
CPUID_EXT_POPCNT | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 |
CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ |
CPUID_EXT_SSE3,
- /* Missing: CPUID_EXT2_RDTSCP */
.features[FEAT_8000_0001_EDX] =
CPUID_EXT2_LM | CPUID_EXT2_PDPE1GB | CPUID_EXT2_NX |
- CPUID_EXT2_SYSCALL,
+ CPUID_EXT2_SYSCALL | CPUID_EXT2_RDTSCP,
.features[FEAT_8000_0001_ECX] =
CPUID_EXT3_FMA4 | CPUID_EXT3_XOP |
CPUID_EXT3_3DNOWPREFETCH | CPUID_EXT3_MISALIGNSSE |
@@ -2788,10 +2786,9 @@ static X86CPUDefinition builtin_x86_defs[] = {
CPUID_EXT_AES | CPUID_EXT_POPCNT | CPUID_EXT_SSE42 |
CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_FMA |
CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3,
- /* Missing: CPUID_EXT2_RDTSCP */
.features[FEAT_8000_0001_EDX] =
CPUID_EXT2_LM | CPUID_EXT2_PDPE1GB | CPUID_EXT2_NX |
- CPUID_EXT2_SYSCALL,
+ CPUID_EXT2_SYSCALL | CPUID_EXT2_RDTSCP,
.features[FEAT_8000_0001_ECX] =
CPUID_EXT3_TBM | CPUID_EXT3_FMA4 | CPUID_EXT3_XOP |
CPUID_EXT3_3DNOWPREFETCH | CPUID_EXT3_MISALIGNSSE |
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Mon, Dec 10, 2018 at 07:41:53PM +0100, Borislav Petkov wrote:
> On Mon, Dec 10, 2018 at 04:37:30PM -0200, Eduardo Habkost wrote:
> > It isn't as simply as reverting commit 33b5e8c03ae7, but we can
> > surely re-add RDTSCP on pc-*-4.0 and newer.
>
> Sure. If you could only point me to an example how to add that to
> pc-*-4.0 and newer, I'll gladly cook up a patch and test it.
Sorry, I forgot to reply to this part.
See commit 33b5e8c03ae7 for reference. The differences will be:
* Instead of removing RDTSCP from builtin_x86_defs, you'll be adding it.
* Instead of adding rdtscp=on entries to PC_COMPAT_2_4, you'll
be adding rdtscp=off entries to PC_COMPAT_3_1.
PC_COMPAT_3_1 is added by the patch that creates the 4.0
machine-types. You can find it on my machine-next branch at:
http://github.com/ehabkost/qemu
--
Eduardo
On Mon, Dec 10, 2018 at 08:42:58PM +0100, Borislav Petkov wrote:
> On Mon, Dec 10, 2018 at 05:06:00PM -0200, Eduardo Habkost wrote:
> > I mean documenting it. We already have code that will print
> > warnings if a feature isn't available.
> >
> > See my previous attempt to document the minimum kernel version
> > at <https://www.mail-archive.com/[email protected]/msg486559.html>.
>
> Something like this?
>
> I still have no clue how to add RDTSCP on pc-*-4.0 and newer.
qemu.git master have no PC_COMPAT_3_1 and pc-*-4.0 machine-types
yet. I've sent another reply with additional pointers.
>
> Thx.
>
> ---
> diff --git a/qemu-doc.texi b/qemu-doc.texi
> index f7ad1dfe4b69..913b2ef68d54 100644
> --- a/qemu-doc.texi
> +++ b/qemu-doc.texi
> @@ -37,6 +37,7 @@
> * QEMU System emulator for non PC targets::
> * QEMU Guest Agent::
> * QEMU User space emulator::
> +* System requirements::
> * Implementation notes::
> * Deprecated features::
> * Supported build platforms::
> @@ -2813,6 +2814,13 @@ Act as if the host page size was 'pagesize' bytes
> Run the emulation in single step mode.
> @end table
>
> +@node System requirements
> +@chapter System requirements
> +
> +@section KVM kernel module
> +
> +On x86_64 hosts, the default set of CPU features enabled by the KVM accelerator
> +require the host to be running Linux v4.5 or newer.
>
Sounds good, but it would be nice to document what exactly makes
Linux 4.5+ necessary. e.g.:
| On x86_64 hosts, it is recommended to run Linux 4.5 or newer on
| the host when using the KVM accelerator.
|
| The Opteron_G2, OpteronG3, Opteron_G4, and Opteron_G5 CPU
| models require KVM support for RDTSCP, which was added on
| Linux 4.5.
I'm CCing some people who may help review English grammar and
style.
--
Eduardo
On Mon, Dec 10, 2018 at 05:47:25PM -0200, Eduardo Habkost wrote:
> On Mon, Dec 10, 2018 at 07:41:53PM +0100, Borislav Petkov wrote:
> > On Mon, Dec 10, 2018 at 04:37:30PM -0200, Eduardo Habkost wrote:
> > > It isn't as simply as reverting commit 33b5e8c03ae7, but we can
> > > surely re-add RDTSCP on pc-*-4.0 and newer.
> >
> > Sure. If you could only point me to an example how to add that to
> > pc-*-4.0 and newer, I'll gladly cook up a patch and test it.
>
> Sorry, I forgot to reply to this part.
>
> See commit 33b5e8c03ae7 for reference. The differences will be:
> * Instead of removing RDTSCP from builtin_x86_defs, you'll be adding it.
> * Instead of adding rdtscp=on entries to PC_COMPAT_2_4, you'll
> be adding rdtscp=off entries to PC_COMPAT_3_1.
>
> PC_COMPAT_3_1 is added by the patch that creates the 4.0
> machine-types. You can find it on my machine-next branch at:
>
> http://github.com/ehabkost/qemu
Thanks for the patient explanation, diff below ontop of your branch.
It is notable to point out that Opteron_G2 - it being family 0xf, model
6 - should not deal with RDTSCP as it doesn't have it.
Although looking at the docs, they say it does but I *have* a K8 laptop
which I just checked and it *doesn't* have RDTSCP in CPUID. So lemme
clarify that aspect first with folks. :)
---
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 9d29c4b1df2a..ebc28e816b04 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -296,6 +296,19 @@ bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
#define PC_COMPAT_3_1 \
HW_COMPAT_3_1 \
+ {\
+ .driver = "Opteron_G3" "-" TYPE_X86_CPU,\
+ .property = "rdtscp",\
+ .value = "off",\
+ },{\
+ .driver = "Opteron_G4" "-" TYPE_X86_CPU,\
+ .property = "rdtscp",\
+ .value = "off",\
+ },{\
+ .driver = "Opteron_G5" "-" TYPE_X86_CPU,\
+ .property = "rdtscp",\
+ .value = "off",\
+ },
#define PC_COMPAT_3_0 \
HW_COMPAT_3_0 \
@@ -527,10 +540,6 @@ bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
.driver = "qemu32" "-" TYPE_X86_CPU,\
.property = "popcnt",\
.value = "on",\
- },{\
- .driver = "Opteron_G2" "-" TYPE_X86_CPU,\
- .property = "rdtscp",\
- .value = "on",\
},{\
.driver = "Opteron_G3" "-" TYPE_X86_CPU,\
.property = "rdtscp",\
diff --git a/qemu-doc.texi b/qemu-doc.texi
index f7ad1dfe4b69..913b2ef68d54 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -37,6 +37,7 @@
* QEMU System emulator for non PC targets::
* QEMU Guest Agent::
* QEMU User space emulator::
+* System requirements::
* Implementation notes::
* Deprecated features::
* Supported build platforms::
@@ -2813,6 +2814,13 @@ Act as if the host page size was 'pagesize' bytes
Run the emulation in single step mode.
@end table
+@node System requirements
+@chapter System requirements
+
+@section KVM kernel module
+
+On x86_64 hosts, the default set of CPU features enabled by the KVM accelerator
+require the host to be running Linux v4.5 or newer.
@include qemu-tech.texi
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index f81d35e1f914..a7def11b27cd 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2706,7 +2706,6 @@ static X86CPUDefinition builtin_x86_defs[] = {
CPUID_DE | CPUID_FP87,
.features[FEAT_1_ECX] =
CPUID_EXT_CX16 | CPUID_EXT_SSE3,
- /* Missing: CPUID_EXT2_RDTSCP */
.features[FEAT_8000_0001_EDX] =
CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
.features[FEAT_8000_0001_ECX] =
@@ -2730,9 +2729,9 @@ static X86CPUDefinition builtin_x86_defs[] = {
.features[FEAT_1_ECX] =
CPUID_EXT_POPCNT | CPUID_EXT_CX16 | CPUID_EXT_MONITOR |
CPUID_EXT_SSE3,
- /* Missing: CPUID_EXT2_RDTSCP */
.features[FEAT_8000_0001_EDX] =
- CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
+ CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL |
+ CPUID_EXT2_RDTSCP,
.features[FEAT_8000_0001_ECX] =
CPUID_EXT3_MISALIGNSSE | CPUID_EXT3_SSE4A |
CPUID_EXT3_ABM | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
@@ -2757,10 +2756,9 @@ static X86CPUDefinition builtin_x86_defs[] = {
CPUID_EXT_POPCNT | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 |
CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ |
CPUID_EXT_SSE3,
- /* Missing: CPUID_EXT2_RDTSCP */
.features[FEAT_8000_0001_EDX] =
CPUID_EXT2_LM | CPUID_EXT2_PDPE1GB | CPUID_EXT2_NX |
- CPUID_EXT2_SYSCALL,
+ CPUID_EXT2_SYSCALL | CPUID_EXT2_RDTSCP,
.features[FEAT_8000_0001_ECX] =
CPUID_EXT3_FMA4 | CPUID_EXT3_XOP |
CPUID_EXT3_3DNOWPREFETCH | CPUID_EXT3_MISALIGNSSE |
@@ -2788,10 +2786,9 @@ static X86CPUDefinition builtin_x86_defs[] = {
CPUID_EXT_AES | CPUID_EXT_POPCNT | CPUID_EXT_SSE42 |
CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_FMA |
CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3,
- /* Missing: CPUID_EXT2_RDTSCP */
.features[FEAT_8000_0001_EDX] =
CPUID_EXT2_LM | CPUID_EXT2_PDPE1GB | CPUID_EXT2_NX |
- CPUID_EXT2_SYSCALL,
+ CPUID_EXT2_SYSCALL | CPUID_EXT2_RDTSCP,
.features[FEAT_8000_0001_ECX] =
CPUID_EXT3_TBM | CPUID_EXT3_FMA4 | CPUID_EXT3_XOP |
CPUID_EXT3_3DNOWPREFETCH | CPUID_EXT3_MISALIGNSSE |
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Mon, Dec 10, 2018 at 07:41:53PM +0100, Borislav Petkov wrote:
> On Mon, Dec 10, 2018 at 04:37:30PM -0200, Eduardo Habkost wrote:
> > It isn't as simply as reverting commit 33b5e8c03ae7, but we can
> > surely re-add RDTSCP on pc-*-4.0 and newer.
>
> Sure. If you could only point me to an example how to add that to
> pc-*-4.0 and newer, I'll gladly cook up a patch and test it.
>
> > I thought we added documentation mentioning the minimum kernel
> > version required by QEMU, but I can't find it. In either case,
> > it seems reasonable to require Linux 4.5 or newer on newer
> > machine-types.
>
> When you say "require" does that mean, one puts it in a text file
> somewhere in the qemu sources or do we enforce it somehow?
I mean documenting it. We already have code that will print
warnings if a feature isn't available.
See my previous attempt to document the minimum kernel version
at <https://www.mail-archive.com/[email protected]/msg486559.html>.
--
Eduardo
On Mon, Dec 10, 2018 at 06:08:43PM -0200, Eduardo Habkost wrote:
> | The Opteron_G2, OpteronG3, Opteron_G4, and Opteron_G5 CPU
> | models require KVM support for RDTSCP, which was added on
> | Linux 4.5.
I've added that to the current diff:
"The OpteronG[345] CPU models require KVM support for RDTSCP, which was
added with Linux 4.5."
In the meantime, I tried executing RDTSCP on a K8 laptop and it gave
SIGILL so I'd say the AMD docs have a typo and family 0xf - at least the
A-E revisions of which model 6 is a part of - doesn't have RDTSCP.
But let's see...
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Mon, Dec 10, 2018 at 06:08:43PM -0200, Eduardo Habkost wrote:
> On Mon, Dec 10, 2018 at 08:42:58PM +0100, Borislav Petkov wrote:
> > On Mon, Dec 10, 2018 at 05:06:00PM -0200, Eduardo Habkost wrote:
> > > I mean documenting it. We already have code that will print
> > > warnings if a feature isn't available.
> > >
> > > See my previous attempt to document the minimum kernel version
> > > at <https://www.mail-archive.com/[email protected]/msg486559.html>.
> >
> > Something like this?
> >
> > I still have no clue how to add RDTSCP on pc-*-4.0 and newer.
>
> qemu.git master have no PC_COMPAT_3_1 and pc-*-4.0 machine-types
> yet. I've sent another reply with additional pointers.
>
> >
> > Thx.
> >
> > ---
> > diff --git a/qemu-doc.texi b/qemu-doc.texi
> > index f7ad1dfe4b69..913b2ef68d54 100644
> > --- a/qemu-doc.texi
> > +++ b/qemu-doc.texi
> > @@ -37,6 +37,7 @@
> > * QEMU System emulator for non PC targets::
> > * QEMU Guest Agent::
> > * QEMU User space emulator::
> > +* System requirements::
> > * Implementation notes::
> > * Deprecated features::
> > * Supported build platforms::
> > @@ -2813,6 +2814,13 @@ Act as if the host page size was 'pagesize' bytes
> > Run the emulation in single step mode.
> > @end table
> >
> > +@node System requirements
> > +@chapter System requirements
> > +
> > +@section KVM kernel module
> > +
> > +On x86_64 hosts, the default set of CPU features enabled by the KVM accelerator
> > +require the host to be running Linux v4.5 or newer.
> >
>
> Sounds good, but it would be nice to document what exactly makes
> Linux 4.5+ necessary. e.g.:
>
> | On x86_64 hosts, it is recommended to run Linux 4.5 or newer on
> | the host when using the KVM accelerator.
> |
> | The Opteron_G2, OpteronG3, Opteron_G4, and Opteron_G5 CPU
> | models require KVM support for RDTSCP, which was added on
> | Linux 4.5.
>
> I'm CCing some people who may help review English grammar and
> style.
Note that QEMU has a declared supported platform list which is used to
set the minimum software versions required.
https://qemu.weilnetz.de/doc/qemu-doc.html#Linux-OS
Based on that policy, the Linux distros we aim to support have the
following kernel versions:
- Debian Jessie: 4.5
- Debian Stretch: 4.5
- RHEL-7: 3.10
- Ubuntu LTS (Xenial): 4.5
- OpenSUSE Leap 15: 4.12.14
So we can't require Linux 4.5 as a minimum version at this time.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, Dec 11, 2018 at 10:38:39AM +0000, Daniel P. Berrang? wrote:
> On Mon, Dec 10, 2018 at 06:08:43PM -0200, Eduardo Habkost wrote:
> > On Mon, Dec 10, 2018 at 08:42:58PM +0100, Borislav Petkov wrote:
> > > On Mon, Dec 10, 2018 at 05:06:00PM -0200, Eduardo Habkost wrote:
> > > > I mean documenting it. We already have code that will print
> > > > warnings if a feature isn't available.
> > > >
> > > > See my previous attempt to document the minimum kernel version
> > > > at <https://www.mail-archive.com/[email protected]/msg486559.html>.
> > >
> > > Something like this?
> > >
> > > I still have no clue how to add RDTSCP on pc-*-4.0 and newer.
> >
> > qemu.git master have no PC_COMPAT_3_1 and pc-*-4.0 machine-types
> > yet. I've sent another reply with additional pointers.
> >
> > >
> > > Thx.
> > >
> > > ---
> > > diff --git a/qemu-doc.texi b/qemu-doc.texi
> > > index f7ad1dfe4b69..913b2ef68d54 100644
> > > --- a/qemu-doc.texi
> > > +++ b/qemu-doc.texi
> > > @@ -37,6 +37,7 @@
> > > * QEMU System emulator for non PC targets::
> > > * QEMU Guest Agent::
> > > * QEMU User space emulator::
> > > +* System requirements::
> > > * Implementation notes::
> > > * Deprecated features::
> > > * Supported build platforms::
> > > @@ -2813,6 +2814,13 @@ Act as if the host page size was 'pagesize' bytes
> > > Run the emulation in single step mode.
> > > @end table
> > >
> > > +@node System requirements
> > > +@chapter System requirements
> > > +
> > > +@section KVM kernel module
> > > +
> > > +On x86_64 hosts, the default set of CPU features enabled by the KVM accelerator
> > > +require the host to be running Linux v4.5 or newer.
> > >
> >
> > Sounds good, but it would be nice to document what exactly makes
> > Linux 4.5+ necessary. e.g.:
> >
> > | On x86_64 hosts, it is recommended to run Linux 4.5 or newer on
> > | the host when using the KVM accelerator.
> > |
> > | The Opteron_G2, OpteronG3, Opteron_G4, and Opteron_G5 CPU
> > | models require KVM support for RDTSCP, which was added on
> > | Linux 4.5.
> >
> > I'm CCing some people who may help review English grammar and
> > style.
>
> Note that QEMU has a declared supported platform list which is used to
> set the minimum software versions required.
>
> https://qemu.weilnetz.de/doc/qemu-doc.html#Linux-OS
>
> Based on that policy, the Linux distros we aim to support have the
> following kernel versions:
>
> - Debian Jessie: 4.5
> - Debian Stretch: 4.5
> - RHEL-7: 3.10
> - Ubuntu LTS (Xenial): 4.5
> - OpenSUSE Leap 15: 4.12.14
>
> So we can't require Linux 4.5 as a minimum version at this time.
I'd like us to take a step back and consider what exactly
"support" means here. QEMU will still work on older kernels if
we add RDTSCP to the CPU models, but at the same time I would
like to document that our strict runnability guarantees may not
be kept if running Linux < 4.5.
--
Eduardo
On Tue, Dec 11, 2018 at 09:55:46AM -0200, Eduardo Habkost wrote:
> On Tue, Dec 11, 2018 at 10:38:39AM +0000, Daniel P. Berrangé wrote:
> > On Mon, Dec 10, 2018 at 06:08:43PM -0200, Eduardo Habkost wrote:
> > > On Mon, Dec 10, 2018 at 08:42:58PM +0100, Borislav Petkov wrote:
> > > > On Mon, Dec 10, 2018 at 05:06:00PM -0200, Eduardo Habkost wrote:
> > > > > I mean documenting it. We already have code that will print
> > > > > warnings if a feature isn't available.
> > > > >
> > > > > See my previous attempt to document the minimum kernel version
> > > > > at <https://www.mail-archive.com/[email protected]/msg486559.html>.
> > > >
> > > > Something like this?
> > > >
> > > > I still have no clue how to add RDTSCP on pc-*-4.0 and newer.
> > >
> > > qemu.git master have no PC_COMPAT_3_1 and pc-*-4.0 machine-types
> > > yet. I've sent another reply with additional pointers.
> > >
> > > >
> > > > Thx.
> > > >
> > > > ---
> > > > diff --git a/qemu-doc.texi b/qemu-doc.texi
> > > > index f7ad1dfe4b69..913b2ef68d54 100644
> > > > --- a/qemu-doc.texi
> > > > +++ b/qemu-doc.texi
> > > > @@ -37,6 +37,7 @@
> > > > * QEMU System emulator for non PC targets::
> > > > * QEMU Guest Agent::
> > > > * QEMU User space emulator::
> > > > +* System requirements::
> > > > * Implementation notes::
> > > > * Deprecated features::
> > > > * Supported build platforms::
> > > > @@ -2813,6 +2814,13 @@ Act as if the host page size was 'pagesize' bytes
> > > > Run the emulation in single step mode.
> > > > @end table
> > > >
> > > > +@node System requirements
> > > > +@chapter System requirements
> > > > +
> > > > +@section KVM kernel module
> > > > +
> > > > +On x86_64 hosts, the default set of CPU features enabled by the KVM accelerator
> > > > +require the host to be running Linux v4.5 or newer.
> > > >
> > >
> > > Sounds good, but it would be nice to document what exactly makes
> > > Linux 4.5+ necessary. e.g.:
> > >
> > > | On x86_64 hosts, it is recommended to run Linux 4.5 or newer on
> > > | the host when using the KVM accelerator.
> > > |
> > > | The Opteron_G2, OpteronG3, Opteron_G4, and Opteron_G5 CPU
> > > | models require KVM support for RDTSCP, which was added on
> > > | Linux 4.5.
> > >
> > > I'm CCing some people who may help review English grammar and
> > > style.
> >
> > Note that QEMU has a declared supported platform list which is used to
> > set the minimum software versions required.
> >
> > https://qemu.weilnetz.de/doc/qemu-doc.html#Linux-OS
> >
> > Based on that policy, the Linux distros we aim to support have the
> > following kernel versions:
> >
> > - Debian Jessie: 4.5
> > - Debian Stretch: 4.5
> > - RHEL-7: 3.10
> > - Ubuntu LTS (Xenial): 4.5
> > - OpenSUSE Leap 15: 4.12.14
> >
> > So we can't require Linux 4.5 as a minimum version at this time.
>
> I'd like us to take a step back and consider what exactly
> "support" means here. QEMU will still work on older kernels if
> we add RDTSCP to the CPU models, but at the same time I would
> like to document that our strict runnability guarantees may not
> be kept if running Linux < 4.5.
I've just noticed that this thread is not in fact on qemu-devel. So
rather than debating the meaning of support here, lets discuss it
once the patch adding rdtscp to OpteronG* CPU model is posted to
qemu-devel.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 11/12/18 12:55, Eduardo Habkost wrote:
>> - Debian Jessie: 4.5
>> - Debian Stretch: 4.5
>> - RHEL-7: 3.10
>> - Ubuntu LTS (Xenial): 4.5
>> - OpenSUSE Leap 15: 4.12.14
>>
>> So we can't require Linux 4.5 as a minimum version at this time.
> I'd like us to take a step back and consider what exactly
> "support" means here. QEMU will still work on older kernels if
> we add RDTSCP to the CPU models, but at the same time I would
> like to document that our strict runnability guarantees may not
> be kept if running Linux < 4.5.
Anyway RHEL does have RDTSC support for AMD, and a bunch of other stuff.
The frankenkernel's KVM is somewhere between 4.5 and 4.10, with a dash
of 4.20 of course. :)
Paolo
On Tue, Dec 11, 2018 at 04:23:51PM +0100, Paolo Bonzini wrote:
> On 11/12/18 12:55, Eduardo Habkost wrote:
> >> - Debian Jessie: 4.5
> >> - Debian Stretch: 4.5
> >> - RHEL-7: 3.10
> >> - Ubuntu LTS (Xenial): 4.5
> >> - OpenSUSE Leap 15: 4.12.14
> >>
> >> So we can't require Linux 4.5 as a minimum version at this time.
> > I'd like us to take a step back and consider what exactly
> > "support" means here. QEMU will still work on older kernels if
> > we add RDTSCP to the CPU models, but at the same time I would
> > like to document that our strict runnability guarantees may not
> > be kept if running Linux < 4.5.
>
> Anyway RHEL does have RDTSC support for AMD, and a bunch of other stuff.
> The frankenkernel's KVM is somewhere between 4.5 and 4.10, with a dash
> of 4.20 of course. :)
Great, then, this is a non-issue - we just need to mention that fact
in the commit that sets the min version for the kernel
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
+ qemu-devel.
On Tue, Dec 11, 2018 at 03:30:17PM +0000, Daniel P. Berrangé wrote:
> Great, then, this is a non-issue - we just need to mention that fact
> in the commit that sets the min version for the kernel
Ok, here's a first draft ontop of Eduardo's machine-next branch from
http://github.com/ehabkost/qemu
Also, thanks for the help Eduardo! :-)
---
From: Borislav Petkov <[email protected]>
Date: Tue, 11 Dec 2018 17:01:00 +0100
The missing functionality was added ~3 years ago with the Linux commit
46896c73c1a4 ("KVM: svm: add support for RDTSCP")
so reenable RDTSCP support on those CPU models.
Opteron_G2 - being family 15, model 6, doesn't have RDTSCP support
(the real hardware doesn't have it. K8 got RDTSCP support with the NPT
models, i.e., models >= 0x40).
Document the host's minimum required kernel version, while at it.
Signed-off-by: Borislav Petkov <[email protected]>
---
include/hw/i386/pc.h | 17 +++++++++++++----
qemu-doc.texi | 13 +++++++++++++
target/i386/cpu.c | 11 ++++-------
3 files changed, 30 insertions(+), 11 deletions(-)
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 9d29c4b1df2a..ebc28e816b04 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -296,6 +296,19 @@ bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
#define PC_COMPAT_3_1 \
HW_COMPAT_3_1 \
+ {\
+ .driver = "Opteron_G3" "-" TYPE_X86_CPU,\
+ .property = "rdtscp",\
+ .value = "off",\
+ },{\
+ .driver = "Opteron_G4" "-" TYPE_X86_CPU,\
+ .property = "rdtscp",\
+ .value = "off",\
+ },{\
+ .driver = "Opteron_G5" "-" TYPE_X86_CPU,\
+ .property = "rdtscp",\
+ .value = "off",\
+ },
#define PC_COMPAT_3_0 \
HW_COMPAT_3_0 \
@@ -527,10 +540,6 @@ bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
.driver = "qemu32" "-" TYPE_X86_CPU,\
.property = "popcnt",\
.value = "on",\
- },{\
- .driver = "Opteron_G2" "-" TYPE_X86_CPU,\
- .property = "rdtscp",\
- .value = "on",\
},{\
.driver = "Opteron_G3" "-" TYPE_X86_CPU,\
.property = "rdtscp",\
diff --git a/qemu-doc.texi b/qemu-doc.texi
index f7ad1dfe4b69..16b955cbf985 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -37,6 +37,7 @@
* QEMU System emulator for non PC targets::
* QEMU Guest Agent::
* QEMU User space emulator::
+* System requirements::
* Implementation notes::
* Deprecated features::
* Supported build platforms::
@@ -2813,6 +2814,18 @@ Act as if the host page size was 'pagesize' bytes
Run the emulation in single step mode.
@end table
+@node System requirements
+@chapter System requirements
+
+@section KVM kernel module
+
+On x86_64 hosts, the default set of CPU features enabled by the KVM accelerator
+require the host to be running Linux v4.5 or newer.
+
+The OpteronG[345] CPU models require KVM support for RDTSCP, which was
+added with Linux 4.5 which is supported by the major distros. And even
+if RHEL7 has kernel 3.10, KVM there has the required functionality there
+to make it close to a 4.5 or newer kernel.
@include qemu-tech.texi
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index f81d35e1f914..a7def11b27cd 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2706,7 +2706,6 @@ static X86CPUDefinition builtin_x86_defs[] = {
CPUID_DE | CPUID_FP87,
.features[FEAT_1_ECX] =
CPUID_EXT_CX16 | CPUID_EXT_SSE3,
- /* Missing: CPUID_EXT2_RDTSCP */
.features[FEAT_8000_0001_EDX] =
CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
.features[FEAT_8000_0001_ECX] =
@@ -2730,9 +2729,9 @@ static X86CPUDefinition builtin_x86_defs[] = {
.features[FEAT_1_ECX] =
CPUID_EXT_POPCNT | CPUID_EXT_CX16 | CPUID_EXT_MONITOR |
CPUID_EXT_SSE3,
- /* Missing: CPUID_EXT2_RDTSCP */
.features[FEAT_8000_0001_EDX] =
- CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
+ CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL |
+ CPUID_EXT2_RDTSCP,
.features[FEAT_8000_0001_ECX] =
CPUID_EXT3_MISALIGNSSE | CPUID_EXT3_SSE4A |
CPUID_EXT3_ABM | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
@@ -2757,10 +2756,9 @@ static X86CPUDefinition builtin_x86_defs[] = {
CPUID_EXT_POPCNT | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 |
CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ |
CPUID_EXT_SSE3,
- /* Missing: CPUID_EXT2_RDTSCP */
.features[FEAT_8000_0001_EDX] =
CPUID_EXT2_LM | CPUID_EXT2_PDPE1GB | CPUID_EXT2_NX |
- CPUID_EXT2_SYSCALL,
+ CPUID_EXT2_SYSCALL | CPUID_EXT2_RDTSCP,
.features[FEAT_8000_0001_ECX] =
CPUID_EXT3_FMA4 | CPUID_EXT3_XOP |
CPUID_EXT3_3DNOWPREFETCH | CPUID_EXT3_MISALIGNSSE |
@@ -2788,10 +2786,9 @@ static X86CPUDefinition builtin_x86_defs[] = {
CPUID_EXT_AES | CPUID_EXT_POPCNT | CPUID_EXT_SSE42 |
CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_FMA |
CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3,
- /* Missing: CPUID_EXT2_RDTSCP */
.features[FEAT_8000_0001_EDX] =
CPUID_EXT2_LM | CPUID_EXT2_PDPE1GB | CPUID_EXT2_NX |
- CPUID_EXT2_SYSCALL,
+ CPUID_EXT2_SYSCALL | CPUID_EXT2_RDTSCP,
.features[FEAT_8000_0001_ECX] =
CPUID_EXT3_TBM | CPUID_EXT3_FMA4 | CPUID_EXT3_XOP |
CPUID_EXT3_3DNOWPREFETCH | CPUID_EXT3_MISALIGNSSE |
--
2.19.1
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Tue, Dec 11, 2018 at 05:14:40PM +0100, Borislav Petkov wrote:
> + qemu-devel.
>
> On Tue, Dec 11, 2018 at 03:30:17PM +0000, Daniel P. Berrang? wrote:
> > Great, then, this is a non-issue - we just need to mention that fact
> > in the commit that sets the min version for the kernel
>
> Ok, here's a first draft ontop of Eduardo's machine-next branch from
> http://github.com/ehabkost/qemu
>
> Also, thanks for the help Eduardo! :-)
>
> ---
> From: Borislav Petkov <[email protected]>
> Date: Tue, 11 Dec 2018 17:01:00 +0100
>
> The missing functionality was added ~3 years ago with the Linux commit
>
> 46896c73c1a4 ("KVM: svm: add support for RDTSCP")
>
> so reenable RDTSCP support on those CPU models.
>
> Opteron_G2 - being family 15, model 6, doesn't have RDTSCP support
> (the real hardware doesn't have it. K8 got RDTSCP support with the NPT
> models, i.e., models >= 0x40).
>
> Document the host's minimum required kernel version, while at it.
>
> Signed-off-by: Borislav Petkov <[email protected]>
> ---
> include/hw/i386/pc.h | 17 +++++++++++++----
> qemu-doc.texi | 13 +++++++++++++
> target/i386/cpu.c | 11 ++++-------
> 3 files changed, 30 insertions(+), 11 deletions(-)
>
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index 9d29c4b1df2a..ebc28e816b04 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -296,6 +296,19 @@ bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
>
> #define PC_COMPAT_3_1 \
> HW_COMPAT_3_1 \
> + {\
> + .driver = "Opteron_G3" "-" TYPE_X86_CPU,\
> + .property = "rdtscp",\
> + .value = "off",\
> + },{\
> + .driver = "Opteron_G4" "-" TYPE_X86_CPU,\
> + .property = "rdtscp",\
> + .value = "off",\
> + },{\
> + .driver = "Opteron_G5" "-" TYPE_X86_CPU,\
> + .property = "rdtscp",\
> + .value = "off",\
> + },
This looks correct.
>
> #define PC_COMPAT_3_0 \
> HW_COMPAT_3_0 \
> @@ -527,10 +540,6 @@ bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
> .driver = "qemu32" "-" TYPE_X86_CPU,\
> .property = "popcnt",\
> .value = "on",\
> - },{\
> - .driver = "Opteron_G2" "-" TYPE_X86_CPU,\
> - .property = "rdtscp",\
> - .value = "on",\
Why did you remove this entry from PC_COMPAT_2_4?
We must keep compatibility with old behavior of Opteron_G2 on
pc-2.4, even if the old behavior was incorrect.
> },{\
> .driver = "Opteron_G3" "-" TYPE_X86_CPU,\
> .property = "rdtscp",\
> diff --git a/qemu-doc.texi b/qemu-doc.texi
> index f7ad1dfe4b69..16b955cbf985 100644
> --- a/qemu-doc.texi
> +++ b/qemu-doc.texi
> @@ -37,6 +37,7 @@
> * QEMU System emulator for non PC targets::
> * QEMU Guest Agent::
> * QEMU User space emulator::
> +* System requirements::
> * Implementation notes::
> * Deprecated features::
> * Supported build platforms::
> @@ -2813,6 +2814,18 @@ Act as if the host page size was 'pagesize' bytes
> Run the emulation in single step mode.
> @end table
>
> +@node System requirements
> +@chapter System requirements
> +
> +@section KVM kernel module
> +
> +On x86_64 hosts, the default set of CPU features enabled by the KVM accelerator
> +require the host to be running Linux v4.5 or newer.
> +
> +The OpteronG[345] CPU models require KVM support for RDTSCP, which was
> +added with Linux 4.5 which is supported by the major distros. And even
> +if RHEL7 has kernel 3.10, KVM there has the required functionality there
> +to make it close to a 4.5 or newer kernel.
>
> @include qemu-tech.texi
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index f81d35e1f914..a7def11b27cd 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -2706,7 +2706,6 @@ static X86CPUDefinition builtin_x86_defs[] = {
> CPUID_DE | CPUID_FP87,
> .features[FEAT_1_ECX] =
> CPUID_EXT_CX16 | CPUID_EXT_SSE3,
> - /* Missing: CPUID_EXT2_RDTSCP */
This is Opteron_G2, and feature is not being added. Looks
correct.
> .features[FEAT_8000_0001_EDX] =
> CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
> .features[FEAT_8000_0001_ECX] =
> @@ -2730,9 +2729,9 @@ static X86CPUDefinition builtin_x86_defs[] = {
> .features[FEAT_1_ECX] =
> CPUID_EXT_POPCNT | CPUID_EXT_CX16 | CPUID_EXT_MONITOR |
> CPUID_EXT_SSE3,
> - /* Missing: CPUID_EXT2_RDTSCP */
> .features[FEAT_8000_0001_EDX] =
> - CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
> + CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL |
> + CPUID_EXT2_RDTSCP,
This is Opteron_G3. Looks correct.
> .features[FEAT_8000_0001_ECX] =
> CPUID_EXT3_MISALIGNSSE | CPUID_EXT3_SSE4A |
> CPUID_EXT3_ABM | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
> @@ -2757,10 +2756,9 @@ static X86CPUDefinition builtin_x86_defs[] = {
> CPUID_EXT_POPCNT | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 |
> CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ |
> CPUID_EXT_SSE3,
> - /* Missing: CPUID_EXT2_RDTSCP */
> .features[FEAT_8000_0001_EDX] =
> CPUID_EXT2_LM | CPUID_EXT2_PDPE1GB | CPUID_EXT2_NX |
> - CPUID_EXT2_SYSCALL,
> + CPUID_EXT2_SYSCALL | CPUID_EXT2_RDTSCP,
This is Opteron_G4. Looks correct.
> .features[FEAT_8000_0001_ECX] =
> CPUID_EXT3_FMA4 | CPUID_EXT3_XOP |
> CPUID_EXT3_3DNOWPREFETCH | CPUID_EXT3_MISALIGNSSE |
> @@ -2788,10 +2786,9 @@ static X86CPUDefinition builtin_x86_defs[] = {
> CPUID_EXT_AES | CPUID_EXT_POPCNT | CPUID_EXT_SSE42 |
> CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_FMA |
> CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3,
> - /* Missing: CPUID_EXT2_RDTSCP */
> .features[FEAT_8000_0001_EDX] =
> CPUID_EXT2_LM | CPUID_EXT2_PDPE1GB | CPUID_EXT2_NX |
> - CPUID_EXT2_SYSCALL,
> + CPUID_EXT2_SYSCALL | CPUID_EXT2_RDTSCP,
This is Opteron_G5. Looks correct.
> .features[FEAT_8000_0001_ECX] =
> CPUID_EXT3_TBM | CPUID_EXT3_FMA4 | CPUID_EXT3_XOP |
> CPUID_EXT3_3DNOWPREFETCH | CPUID_EXT3_MISALIGNSSE |
> --
> 2.19.1
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
--
Eduardo
On Wed, Dec 12, 2018 at 05:52:35PM -0200, Eduardo Habkost wrote:
> Why did you remove this entry from PC_COMPAT_2_4?
>
> We must keep compatibility with old behavior of Opteron_G2 on
> pc-2.4, even if the old behavior was incorrect.
Ok, hunk reverted. v2 below.
Thx.
---
From: Borislav Petkov <[email protected]>
The missing functionality was added ~3 years ago with the Linux commit
46896c73c1a4 ("KVM: svm: add support for RDTSCP")
so reenable RDTSCP support on those CPU models.
Opteron_G2 - being family 15, model 6, doesn't have RDTSCP support
(the real hardware doesn't have it. K8 got RDTSCP support with the NPT
models, i.e., models >= 0x40).
Document the host's minimum required kernel version, while at it.
Signed-off-by: Borislav Petkov <[email protected]>
---
v2: Keep Opteron_G2 in PC_COMPAT_2_4 unchanged.
include/hw/i386/pc.h | 13 +++++++++++++
qemu-doc.texi | 13 +++++++++++++
target/i386/cpu.c | 11 ++++-------
3 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 9d29c4b1df2a..236d962d2547 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -296,6 +296,19 @@ bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
#define PC_COMPAT_3_1 \
HW_COMPAT_3_1 \
+ {\
+ .driver = "Opteron_G3" "-" TYPE_X86_CPU,\
+ .property = "rdtscp",\
+ .value = "off",\
+ },{\
+ .driver = "Opteron_G4" "-" TYPE_X86_CPU,\
+ .property = "rdtscp",\
+ .value = "off",\
+ },{\
+ .driver = "Opteron_G5" "-" TYPE_X86_CPU,\
+ .property = "rdtscp",\
+ .value = "off",\
+ },
#define PC_COMPAT_3_0 \
HW_COMPAT_3_0 \
diff --git a/qemu-doc.texi b/qemu-doc.texi
index f7ad1dfe4b69..16b955cbf985 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -37,6 +37,7 @@
* QEMU System emulator for non PC targets::
* QEMU Guest Agent::
* QEMU User space emulator::
+* System requirements::
* Implementation notes::
* Deprecated features::
* Supported build platforms::
@@ -2813,6 +2814,18 @@ Act as if the host page size was 'pagesize' bytes
Run the emulation in single step mode.
@end table
+@node System requirements
+@chapter System requirements
+
+@section KVM kernel module
+
+On x86_64 hosts, the default set of CPU features enabled by the KVM accelerator
+require the host to be running Linux v4.5 or newer.
+
+The OpteronG[345] CPU models require KVM support for RDTSCP, which was
+added with Linux 4.5 which is supported by the major distros. And even
+if RHEL7 has kernel 3.10, KVM there has the required functionality there
+to make it close to a 4.5 or newer kernel.
@include qemu-tech.texi
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index f81d35e1f914..a7def11b27cd 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2706,7 +2706,6 @@ static X86CPUDefinition builtin_x86_defs[] = {
CPUID_DE | CPUID_FP87,
.features[FEAT_1_ECX] =
CPUID_EXT_CX16 | CPUID_EXT_SSE3,
- /* Missing: CPUID_EXT2_RDTSCP */
.features[FEAT_8000_0001_EDX] =
CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
.features[FEAT_8000_0001_ECX] =
@@ -2730,9 +2729,9 @@ static X86CPUDefinition builtin_x86_defs[] = {
.features[FEAT_1_ECX] =
CPUID_EXT_POPCNT | CPUID_EXT_CX16 | CPUID_EXT_MONITOR |
CPUID_EXT_SSE3,
- /* Missing: CPUID_EXT2_RDTSCP */
.features[FEAT_8000_0001_EDX] =
- CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
+ CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL |
+ CPUID_EXT2_RDTSCP,
.features[FEAT_8000_0001_ECX] =
CPUID_EXT3_MISALIGNSSE | CPUID_EXT3_SSE4A |
CPUID_EXT3_ABM | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
@@ -2757,10 +2756,9 @@ static X86CPUDefinition builtin_x86_defs[] = {
CPUID_EXT_POPCNT | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 |
CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ |
CPUID_EXT_SSE3,
- /* Missing: CPUID_EXT2_RDTSCP */
.features[FEAT_8000_0001_EDX] =
CPUID_EXT2_LM | CPUID_EXT2_PDPE1GB | CPUID_EXT2_NX |
- CPUID_EXT2_SYSCALL,
+ CPUID_EXT2_SYSCALL | CPUID_EXT2_RDTSCP,
.features[FEAT_8000_0001_ECX] =
CPUID_EXT3_FMA4 | CPUID_EXT3_XOP |
CPUID_EXT3_3DNOWPREFETCH | CPUID_EXT3_MISALIGNSSE |
@@ -2788,10 +2786,9 @@ static X86CPUDefinition builtin_x86_defs[] = {
CPUID_EXT_AES | CPUID_EXT_POPCNT | CPUID_EXT_SSE42 |
CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_FMA |
CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3,
- /* Missing: CPUID_EXT2_RDTSCP */
.features[FEAT_8000_0001_EDX] =
CPUID_EXT2_LM | CPUID_EXT2_PDPE1GB | CPUID_EXT2_NX |
- CPUID_EXT2_SYSCALL,
+ CPUID_EXT2_SYSCALL | CPUID_EXT2_RDTSCP,
.features[FEAT_8000_0001_ECX] =
CPUID_EXT3_TBM | CPUID_EXT3_FMA4 | CPUID_EXT3_XOP |
CPUID_EXT3_3DNOWPREFETCH | CPUID_EXT3_MISALIGNSSE |
--
2.19.1
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Wed, Dec 12, 2018 at 09:08:03PM +0100, Borislav Petkov wrote:
> On Wed, Dec 12, 2018 at 05:52:35PM -0200, Eduardo Habkost wrote:
> > Why did you remove this entry from PC_COMPAT_2_4?
> >
> > We must keep compatibility with old behavior of Opteron_G2 on
> > pc-2.4, even if the old behavior was incorrect.
>
> Ok, hunk reverted. v2 below.
>
> Thx.
>
> ---
> From: Borislav Petkov <[email protected]>
>
> The missing functionality was added ~3 years ago with the Linux commit
>
> 46896c73c1a4 ("KVM: svm: add support for RDTSCP")
>
> so reenable RDTSCP support on those CPU models.
>
> Opteron_G2 - being family 15, model 6, doesn't have RDTSCP support
> (the real hardware doesn't have it. K8 got RDTSCP support with the NPT
> models, i.e., models >= 0x40).
>
> Document the host's minimum required kernel version, while at it.
>
> Signed-off-by: Borislav Petkov <[email protected]>
Queued, thanks.
--
Eduardo