[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] ad1839: i386: Resolve CPU models to v1 by def
From: |
Peter Maydell |
Subject: |
[Qemu-commits] [qemu/qemu] ad1839: i386: Resolve CPU models to v1 by default |
Date: |
Mon, 06 Jan 2020 07:00:14 -0800 |
Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: ad18392892c04637fb56956d997f4bc600224356
https://github.com/qemu/qemu/commit/ad18392892c04637fb56956d997f4bc600224356
Author: Eduardo Habkost <address@hidden>
Date: 2019-12-19 (Thu, 19 Dec 2019)
Changed paths:
M qemu-deprecated.texi
M target/i386/cpu.c
Log Message:
-----------
i386: Resolve CPU models to v1 by default
When using `query-cpu-definitions` using `-machine none`,
QEMU is resolving all CPU models to their latest versions. The
actual CPU model version being used by another machine type (e.g.
`pc-q35-4.0`) might be different.
In theory, this was OK because the correct CPU model
version is returned when using the correct `-machine` argument.
Except that in practice, this breaks libvirt expectations:
libvirt always use `-machine none` when checking if a CPU model
is runnable, because runnability is not expected to be affected
when the machine type is changed.
For example, when running on a Haswell host without TSX,
Haswell-v4 is runnable, but Haswell-v1 is not. On those hosts,
`query-cpu-definitions` says Haswell is runnable if using
`-machine none`, but Haswell is actually not runnable using any
of the `pc-*` machine types (because they resolve Haswell to
Haswell-v1). In other words, we're breaking the "runnability
guarantee" we promised to not break for a few releases (see
qemu-deprecated.texi).
To address this issue, change the default CPU model version to v1
on all machine types, so we make `query-cpu-definitions` output
when using `-machine none` match the results when using `pc-*`.
This will change in the future (the plan is to always return the
latest CPU model version if using `-machine none`), but only
after giving libvirt the opportunity to adapt.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1779078
Signed-off-by: Eduardo Habkost <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
Commit: 5275db59aa7ff8a26bd6aa5d07cb4d53de5cfab5
https://github.com/qemu/qemu/commit/5275db59aa7ff8a26bd6aa5d07cb4d53de5cfab5
Author: Igor Mammedov <address@hidden>
Date: 2019-12-19 (Thu, 19 Dec 2019)
Changed paths:
M hw/core/numa.c
Log Message:
-----------
numa: remove not needed check
Currently parse_numa_node() is always called from already numa
enabled context.
Drop unnecessary check if numa is supported.
Signed-off-by: Igor Mammedov <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
Commit: fcd3f2cc124600385dba46c69a80626985c15b50
https://github.com/qemu/qemu/commit/fcd3f2cc124600385dba46c69a80626985c15b50
Author: Igor Mammedov <address@hidden>
Date: 2019-12-19 (Thu, 19 Dec 2019)
Changed paths:
M hw/arm/sbsa-ref.c
M hw/core/machine.c
Log Message:
-----------
numa: properly check if numa is supported
Commit aa57020774b, by mistake used MachineClass::numa_mem_supported
to check if NUMA is supported by machine and also as unrelated change
set it to true for sbsa-ref board.
Luckily change didn't break machines that support NUMA, as the field
is set to true for them.
But the field is not intended for checking if NUMA is supported and
will be flipped to false within this release for new machine types.
Fix it:
- by using previously used condition
!mc->cpu_index_to_instance_props || !mc->get_default_cpu_node_id
the first time and then use MachineState::numa_state down the road
to check if NUMA is supported
- dropping stray sbsa-ref chunk
Fixes: aa57020774b690a22be72453b8e91c9b5a68c516
Signed-off-by: Igor Mammedov <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
Commit: 6fb0dae9efa90c2ef41d8aacef296b8959cf1d61
https://github.com/qemu/qemu/commit/6fb0dae9efa90c2ef41d8aacef296b8959cf1d61
Author: Peter Maydell <address@hidden>
Date: 2020-01-06 (Mon, 06 Jan 2020)
Changed paths:
M hw/arm/sbsa-ref.c
M hw/core/machine.c
M hw/core/numa.c
M qemu-deprecated.texi
M target/i386/cpu.c
Log Message:
-----------
Merge remote-tracking branch
'remotes/ehabkost/tags/x86-and-machine-pull-request' into staging
x86 and machine queue, 2019-12-20
Bug fix:
* Resolve CPU models to v1 by default (Eduardo Habkost)
Cleanup:
* Remove incorrect numa_mem_supported checks (Igor Mammedov)
# gpg: Signature made Fri 20 Dec 2019 19:19:02 GMT
# gpg: using RSA key 5A322FD5ABC4D3DBACCFD1AA2807936F984DC5A6
# gpg: issuer "address@hidden"
# gpg: Good signature from "Eduardo Habkost <address@hidden>" [full]
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6
* remotes/ehabkost/tags/x86-and-machine-pull-request:
numa: properly check if numa is supported
numa: remove not needed check
i386: Resolve CPU models to v1 by default
Signed-off-by: Peter Maydell <address@hidden>
Compare: https://github.com/qemu/qemu/compare/b0b74e1f1750...6fb0dae9efa9
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] ad1839: i386: Resolve CPU models to v1 by default,
Peter Maydell <=