The trace crate is a minimal container for dependencies of tracepoints
(so that they do not have to be imported in all the crates that use
tracepoints); it also contains a macro called "include_trace!" that is
able to find the right include file from the trace/ directory.
[Write commit message, add #[allow()]. - Paolo]
Signed-off-by: Tanish Desai <tanishdesai37@gmail.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20250929154938.594389-10-pbonzini@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The attrs crate is a simple combinator-based for Rust attributes. It
will be used instead of a handwritten parser.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The crate purpose is only to provide integration tests at this point,
that can't easily be moved to a specific crate.
It's also often a good practice to have a single integration test crate
(see for ex https://github.com/rust-lang/cargo/issues/4867)
Drop README.md, use docs/devel/rust.rst instead.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Link: https://lore.kernel.org/r/20250827104147.717203-20-marcandre.lureau@redhat.com
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Unfortunately, an example had to be compile-time disabled, since it
relies on higher level crates (qdev, irq etc). The alternative is
probably to move that code to an example in qemu-api or elsewere and
make a link to it, or include_str.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Link: https://lore.kernel.org/r/20250827104147.717203-12-marcandre.lureau@redhat.com
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Once qemu-api is split in multiple crates, each of them will have
its own invocation of bindgen. There cannot be only one, because
there are occasional "impl" blocks for the bindgen-generated
structs (e.g. VMStateFlags or QOM classes) that have to
reside in the same crate as the bindgen-generated code.
For now, prepare for this new organization by invoking bindgen
within the qemu-api crate's build definitions; it's also a
much better place to list enums that need specific treatment
from bindgen.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When splitting the QEMU Rust bindings into multiple crates, the
bindgen-generated structs also have to be split so that it's
possible to add "impl" blocks (e.g. for Sync/Send or Default,
or even for utility methods in cases such as VMStateFlags).
Tweak various variable definitions in meson.build, to avoid naming
conflicts once there will be multiple bindgen invocations.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This is a standard replacement for Box<dyn Error> which is more efficient (it only
occcupies one word) and provides a backtrace of the error. This could be plumbed
into &error_abort in the future.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
One common thing that device emulation does is manipulate bitmasks, for example
to check whether two bitmaps have common bits. One example in the pl011 crate
is the checks for pending interrupts, where an interrupt cause corresponds to
at least one interrupt source from a fixed set.
Unfortunately, this is one case where Rust *can* provide some kind of
abstraction but it does so with a rather Perl-ish There Is More Way To
Do It. It is not something where a crate like "bilge" helps, because
it only covers the packing of bits in a structure; operations like "are
all bits of Y set in X" almost never make sense for bit-packed structs;
you need something else, there are several crates that do it and of course
we're going to roll our own.
In particular I examined three:
- bitmask (https://docs.rs/bitmask/0.5.0/bitmask/) does not support const
at all. This is a showstopper because one of the ugly things in the
current pl011 code is the ugliness of code that defines interrupt masks
at compile time:
pub const E: Self = Self(Self::OE.0 | Self::BE.0 | Self::PE.0 | Self::FE.0);
or even worse:
const IRQMASK: [u32; 6] = [
Interrupt::E.0 | Interrupt::MS.0 | Interrupt::RT.0 | Interrupt::TX.0 | Interrupt::RX.0,
...
}
You would have to use roughly the same code---"bitmask" only helps with
defining the struct.
- bitmask_enum (https://docs.rs/bitmask-enum/2.2.5/bitmask_enum/) does not
have a good separation of "valid" and "invalid" bits, so for example "!x"
will invert all 16 bits if you choose u16 as the representation -- even if
you only defined 10 bits. This makes it easier to introduce subtle bugs
in comparisons.
- bitflags (https://docs.rs/bitflags/2.6.0/bitflags/) is generally the most
used such crate and is the one that I took most inspiration from with
respect to the syntax. It's a pretty sophisticated implementation,
with a lot of bells and whistles such as an implementation of "Iter"
that returns the bits one at a time.
The main thing that all of them lack, however, is a way to simplify the
ugly definitions like the above. "bitflags" includes const methods that
perform AND/OR/XOR of masks (these are necessary because Rust operator
overloading does not support const yet, and therefore overloaded operators
cannot be used in the definition of a "static" variable), but they become
even more verbose and unmanageable, like
Interrupt::E.union(Interrupt::MS).union(Interrupt::RT).union(Interrupt::TX).union(Interrupt::RX)
This was the main reason to create "bits", which allows something like
bits!(Interrupt: E | MS | RT | TX | RX)
and expands it 1) add "Interrupt::" in front of all identifiers 2) convert
operators to the wordy const functions like "union". It supports boolean
operators "&", "|", "^", "!" and parentheses, with a relatively simple
recursive descent parser that's implemented in qemu_api_macros.
Since I don't remember exactly how the macro was developed, I cannot exclude
that it contains code from "bitflags". Therefore, I am conservatively leaving
in the MIT and Apache 2.0 licenses from bitflags. In fact, I think there
would be a benefit in being able to push code back to "bitflags" anyway
whenever applicable, so that the two libraries do not diverge too much,
so that's another reason to use this.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Meson has support for invoking clippy and rustdoc on all crates (1.7.0 for
clippy, 1.8.0 for rustdoc). Use it instead of the homegrown version; this
requires disabling the multiple_crate_versions lint (the only one that was
enabled from the "cargo" group)---which was not particularly useful anyway
because all dependencies are converted by hand into Meson subprojects.
rustfmt is still not supported.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
libqemuutil is not meant be linked as a whole; if modules are enabled, doing
so results in undefined symbols (corresponding to QMP commands) in
rust/qemu-api/rust-qemu-api-integration.
Support for "objects" in Rust executables is available in Meson 1.8.0; use it
to switching to the same dependencies that C targets use: link_with for
libqemuutil, and objects for everything else.
Reported-by: Bernhard Beschow <shentey@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Crates like "bilge" and "libc" can be shared by more than one directory,
so declare them directly in rust/meson.build. While at it, make their
variable names end with "_rs" and always add a subproject() statement
(as that pinpoints the error better if the subproject is missing and
cannot be downloaded).
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Abstract common invocations of "cargo", that do not require copying
the generated bindgen file or setting up MESON_BUILD_ROOT.
In the future these could also do completely without cargo and invoke
the underlying programs directly.
Reviewed-by: Junjie Mao <junjie.mao@hotmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This commit adds a re-implementation of hw/char/pl011.c in Rust.
How to build:
1. Configure a QEMU build with:
--enable-system --target-list=aarch64-softmmu --enable-rust
2. Launching a VM with qemu-system-aarch64 should use the Rust version
of the pl011 device
Co-authored-by: Junjie Mao <junjie.mao@intel.com>
Co-authored-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Link: https://lore.kernel.org/r/20241024-rust-round-2-v1-2-051e7a25b978@linaro.org
Patch was applied with invalid authorship by accident, which confuses
git tooling that look at git blame for contributors etc.
Patch will be re-applied with correct authorship right after this
commit.
This reverts commit d0f0cd5b1f.
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Link: https://lore.kernel.org/r/20241024-rust-round-2-v1-1-051e7a25b978@linaro.org
This commit adds a re-implementation of hw/char/pl011.c in Rust.
How to build:
1. Configure a QEMU build with:
--enable-system --target-list=aarch64-softmmu --enable-rust
2. Launching a VM with qemu-system-aarch64 should use the Rust version
of the pl011 device
Co-authored-by: Junjie Mao <junjie.mao@intel.com>
Co-authored-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Link: https://lore.kernel.org/r/6ec1d4fb8db2a1d7ba94c73e65d9770371b7857d.1727961605.git.manos.pitsidianakis@linaro.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This commit adds a helper crate library, qemu-api-macros for derive (and
other procedural) macros to be used along qemu-api.
It needs to be a separate library because in Rust, procedural macros, or
macros that can generate arbitrary code, need to be special separate
compilation units.
Only one macro is introduced in this patch, #[derive(Object)]. It
generates a constructor to register a QOM TypeInfo on init and it must
be used on types that implement qemu_api::definitions::ObjectImpl trait.
Reviewed-by: Junjie Mao <junjie.mao@hotmail.com>
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Link: https://lore.kernel.org/r/dd645642406a6dc2060c6f3f17db2bc77ed67b59.1727961605.git.manos.pitsidianakis@linaro.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add rust/qemu-api, which exposes rust-bindgen generated FFI bindings and
provides some declaration macros for symbols visible to the rest of
QEMU.
Co-authored-by: Junjie Mao <junjie.mao@intel.com>
Co-authored-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Link: https://lore.kernel.org/r/0fb23fbe211761b263aacec03deaf85c0cc39995.1727961605.git.manos.pitsidianakis@linaro.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add bindings_rs target for generating rust bindings to target-independent
qemu C APIs.
The bindings need be created before any rust crate that uses them is
compiled.
The bindings.rs file will end up in BUILDDIR/bindings.rs and have the
same name as a target:
ninja bindings.rs
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Link: https://lore.kernel.org/r/1be89a27719049b7203eaf2eca8bbb75b33f18d4.1727961605.git.manos.pitsidianakis@linaro.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
https://www.python.org/dev/peps/pep-0561/#specification
Create 'py.typed' files in each subpackage that indicate to mypy that
this is a typed module, so that users of any of these packages can use
mypy to check their code as well.
Note: Theoretically it's possible to ditch MANIFEST.in in favor of using
package_data in setup.cfg, but I genuinely could not figure out how to
get it to include things from the *source root* into the *package root*;
only how to include things from each subpackage. I tried!
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Willian Rampazzo <willianr@redhat.com>
Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
Message-id: 20210629214323.1329806-3-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
This started as a simple script that scanned for regular
expressions, but became more and more complex when exceptions to
the rules were found.
I don't know if this should be maintained in the QEMU source tree
long term (maybe it can be reused for other code transformations
that Coccinelle can't handle). In either case, this is included
as part of the patch series to document how exactly the automated
code transformations in the next patches were done.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20200831210740.126168-7-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Whenever qapi-schema.json changes, we run six programs eleven times to
update eleven files. Similar for qga/qapi-schema.json. This is
silly. Replace the six programs by a single program that spits out
all eleven files.
The programs become modules in new Python package qapi, along with the
helper library. This requires moving them to scripts/qapi/. While
moving them, consistently drop executable mode bits.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20180211093607.27351-9-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
[eblake: move change to one-line 'blurb' earlier in series, mention mode
bit change as intentional, update qapi-code-gen.txt to match actual
generated events.c file]
Signed-off-by: Eric Blake <eblake@redhat.com>
When searching for modules to load, python will ignore any
sub-directory which does not contain __init__.py. This means
that both scripts and scripts/qmp/ have to be explicitly added
to the python path. By adding a __init__.py file to scripts/qmp,
we only need add scripts/ to the python path and can then simply
do 'from qmp import qmp' to load scripts/qmp/qmp.py.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <1469020993-29426-2-git-send-email-berrange@redhat.com>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Add tcg and cpu model initialization.
Add gen_intermediate_code function.
Activate target in configure and add softmmu config.
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
Message-id: 1409572800-4116-5-git-send-email-kbastian@mail.uni-paderborn.de
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Changes v1 -> v2:
- userconfig variable is now bool, not int
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch addes a Bulldozer-based Opteron_G4 CPU model.
This version has the ffxsr bit actually disabled, to match what was
documented below. Thanks to Andre Przywara for spotting the bug.
I am trying to be conservative with the new model, so I am enabling only
features known to be useful to guests, and not enabling anything that
was not tested or found to be useful to a guest.
List of missing flags in comparison to real hardware:
- vme: host-specific feature.
- osxsave: it is not set here because it is set by the guest OS, not by KVM
- monitor: this is filtered out by the KVM module, so no point in
enabling it.
- mmxext: untested, so not enabled.
- Perf*, Topology*, lwp, ibs: not emulated by KVM.
- wdt, skinit, osvw, altmovcr8, extapicspace, cmplegacy: untested,
so not enabled.
List of new flags, in comparison to the Opteron_G3 model:
- xsave: xsave feature, already implemented by Qemu
- avx, aes, sse4.x, ssse3, pclmulqdq: all new state the new instructions
could use is handled by the xsave state loading/saving code on Qemu.
- pdpe1gb: 1GB pages, supported by the KVM kernel module.
- ffxsr: untested, so not enabled
- fma4, xop: all new state the new instructions could use is handled by
the xsave loading/saving code on Qemu.
- 3dnowprefetch: safe to pass through, though the flag is not used by
Linux guests, at least.
Below is the comparison between the current Opteron_G3 model
and the new model being added.
- The "full" line contains the flags found on actual hardware.
- The "missing" line shows the flags that are present on actual
hardware, but not on the added Opteron_G4 model.
- The "new" line shows the flags that were not on the Opteron_G3 model
but are on Opteron_G4.
feature_edx:
Opteron_G3: sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep apic cx8 mce pae msr tsc pse de fpu
full: sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep apic cx8 mce pae msr tsc pse de vme fpu
Opteron_G4: sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep apic cx8 mce pae msr tsc pse de fpu
missing: vme
feature_ecx:
Opteron_G3: popcnt cx16 monitor sse3
full: avx osxsave xsave aes popcnt sse4.2 sse4.1 cx16 ssse3 monitor pclmulqdq sse3
Opteron_G4: avx xsave aes popcnt sse4.2 sse4.1 cx16 ssse3 pclmulqdq sse3
missing: osxsave monitor
new: avx xsave aes sse4.2 sse4.1 ssse3 pclmulqdq
extfeature_edx:
Opteron_G3: lm rdtscp fxsr mmx nx pse36 pat cmov mca pge mtrr syscall apic cx8 mce pae msr tsc pse de fpu
full: lm rdtscp pdpe1gb ffxsr fxsr mmx mmxext nx pse36 pat cmov mca pge mtrr syscall apic cx8 mce pae msr tsc pse de vme fpu
Opteron_G4: lm rdtscp pdpe1gb fxsr mmx nx pse36 pat cmov mca pge mtrr syscall apic cx8 mce pae msr tsc pse de fpu
missing: mmxext vme
new: pdpe1gb
extfeature_ecx:
Opteron_G3: misalignsse sse4a abm svm lahf_lm
full: Perf* Topology* fma4 lwp wdt skinit xop ibs osvw 3dnowprefetch misalignsse sse4a abm altmovcr8 extapicspace svm cmplegacy lahf_lm
Opteron_G4: fma4 xop 3dnowprefetch misalignsse sse4a abm svm lahf_lm
new: fma4 xop 3dnowprefetch
missing: Perf* Topology* lwp wdt skinit ibs osvw altmovcr8 extapicspace cmplegacy
Changes v1 -> v2:
- Actually disable ffxsr bit
Cc: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patches add the definition of a SandyBridge CPU model.
Summary of differences:
Flags present on actual hardware, but not on the added model definition:
- pbe, tm, ht, ss, acpi, vme, xTPR, tm2, eist, smx: host-specific
features, not exposed to guest.
- ds, ds-cpl, dtes64, pdcm: emulation not supported by KVM (although it
may be added in the future if implementing PMU virtualization)
- pcid, vmx, monitor: not emulated by Qemu/KVM right now.
- osxsave: set by the guest OS, not by Qemu.
Flags added, that were not present on Westmere model:
- xsave: already supported by Qemu
- avx, pclmulqdq: all new state the new instructions could use is
handled by xsave state loading/saving code.
- tsc-deadline, x2apic, rdtscp: already supported by Qemu/KVM.
Below there's a comparison of the features on the current Westmere CPU
model, and the SandyBridge CPU model.
- The "full" line contains the flags found on actual hardware.
- The "missing" line shows the flags that are present on actual
hardware, but not on the added SandyBridge model.
- The "new" line shows the flags that were not on the Westmere model,
but are on SandyBridge.
feature_edx:
Westmere: sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep apic cx8 mce pae msr tsc pse de fpu
full: pbe tm ht ss sse2 sse fxsr mmx ds acpi clflush pse36 pat cmov mca pge mtrr sep apic cx8 mce pge msr tsc pse de vme fpu
SandyBridge: sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep apic cx8 mce pae msr tsc pse de fpu
missing: pbe tm ht ss ds acpi vme
feature_ecx:
Westmere: aes popcnt sse4.2 sse4.1 cx16 ssse3 sse3
full: avx osxsave xsave aes tsc-deadline popcnt x2apic sse4.2 sse4.1 pcid pdcm xTPR cx16 ssse3 tm2 eist smx vmx ds-cpl monitor dtes64 pclmulqdq sse3
SandyBridge: avx xsave aes tsc-deadline popcnt x2apic sse4.2 sse4.1 cx16 ssse3 pclmulqdq sse3
missing: osxsave pcid pdcm xTPR tm2 eist smx vmx ds-cpl monitor dtes64
new: avx xsave tsc-deadline x2apic pclmulqdq
extfeature_edx:
Westmere: i64 nx syscall
full: i64 rdtscp nx syscall
SandyBridge: i64 rdtscp nx syscall
new: rdtscp
extfeature_ecx:
Westmere: lahf_lm
full: lahf_lm
SandyBridge: lahf_lm
Cc: "Dugger, Donald D" <donald.d.dugger@intel.com>
Cc: "Zhang, Xiantao" <xiantao.zhang@intel.com>
Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This should have no visible effect, but it should just clean up the
config file a bit.
This is based on a previous patch from John Cooper where this was introduced
with many other changes at the same time. Original John's patch submission is
at Message-ID: <4DDAD5E7.2020002@redhat.com>, <http://marc.info/?l=qemu-devel&m=130618871926030>.
Changes v1 -> v2:
- Rebase against latest Qemu git tree
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Version 1 of this patch was:
Message-Id: <1307041990-26194-11-git-send-email-ehabkost@redhat.com
http://marc.info/?l=qemu-devel&m=130704415919346
This version doesn't have the duplicate feature bits on extfeature_edx, though,
as they are being removed from the Intel models (as they are reserved bits on
Intel CPUs).
Version 1 patch description:
This patch adds Westmere as a qemu cpu model. The only
additional guest visible feature of a Westmere relative
to Nehalem is the inclusion of AES instructions. However
as other non-ABI visible modifications exist along with
fabrication changes, the CPUID data of the corresponding
deployed silicon was altered slightly to reflect this.
We've seen isolated cases where apparently unrelated yet
slightly incoherent CPUID data has caused problems, most
notably during guest boot. Providing Westmere as a
model separate fro Nehalem allows us to more easily address
such quirks.
[ehabkost: edited commit message to have a better Subject line]
Signed-off-by: john cooper <john.cooper@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Changes version 1 -> version 2:
- Remove the duplicate feature bits on extfeature_edx, that are
reserved on Intel CPUs
- Reorder feature flags
- Remove x2apic from the definition because x2apic requires some fixes
that have to be resubmitted
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch removes the replicated feature flags from cpuid 8000_0001:edx
(extfeature_edx) from Intel models, as the duplicated feature flags are present
only on AMD CPUs. On Intel models, only the i64, syscall, and xd flags are kept
on extfeature_edx.
This is based on a previous patch from John Cooper where this was introduced
with many other changes at the same time. Original John's patch submission is
at Message-ID: <4DDAD5E7.2020002@redhat.com>, <http://marc.info/?l=qemu-devel&m=130618871926030>.
Original John's patch description was:
cpu model bug fixes and definition corrections
This patch was intended to address the replicated feature
flags in cpuid 8000_0001:edx from cpuid 0000_0001:edx.
This is due to AMD's definition where these flags are
mostly cloned in the 8000_0001:edx cpuid function.
qemu64 attempted to glue together the respective Intel
and AMD nearly disjoint features and this propagated to
the new Intel models as doing so was believed conservative
at the time. However after further soak and test lugging
around this cruft doesn't provide any value, could
conceivably confuse a guest, and has confused users trying
to maintain/add cpu definitions. This also caused issues
for libvirt attempting to track this mis-encoding.
So we've here tossed out the AMD replicated definitions
from the Intel models, added a few replications into AMD
definitions which were missing according to AMD's latest
CPUID document, and reordered the config file flags to
follow intuitive sequential bit ordering. Also two flag
name aliases were added for clarity to Intel models. The
end result being the models definitions now conform to
their respective cpuid specifications sans x2apic which is
emulated by kvm.
This was tested with the following combinations:
[Conroe, Penryn, Nehalem] x [F12-64, win64, win32] -- Intel host
[Opteron_G1, Opteron_G2, Opteron_G3] x [F12-64, win64, win32] -- AMD host
Yielding successful boots in all cases.
Signed-off-by: john cooper <john.cooper@redhat.com>
Changes v1 -> v2:
- Rebase against latest Qemu git tree
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch adds some missing flags to extfeature_edx, that were missing
according to AMD's latest CPUID document.
This is based on a previous patch from John Cooper where this was introduced
with many other changes at the same time. Original John's patch submission is
at Message-ID: <4DDAD5E7.2020002@redhat.com>, <http://marc.info/?l=qemu-devel&m=130618871926030>.
Original John's patch description was:
cpu model bug fixes and definition corrections
This patch was intended to address the replicated feature
flags in cpuid 8000_0001:edx from cpuid 0000_0001:edx.
This is due to AMD's definition where these flags are
mostly cloned in the 8000_0001:edx cpuid function.
qemu64 attempted to glue together the respective Intel
and AMD nearly disjoint features and this propagated to
the new Intel models as doing so was believed conservative
at the time. However after further soak and test lugging
around this cruft doesn't provide any value, could
conceivably confuse a guest, and has confused users trying
to maintain/add cpu definitions. This also caused issues
for libvirt attempting to track this mis-encoding.
So we've here tossed out the AMD replicated definitions
from the Intel models, added a few replications into AMD
definitions which were missing according to AMD's latest
CPUID document, and reordered the config file flags to
follow intuitive sequential bit ordering. Also two flag
name aliases were added for clarity to Intel models. The
end result being the models definitions now conform to
their respective cpuid specifications sans x2apic which is
emulated by kvm.
This was tested with the following combinations:
[Conroe, Penryn, Nehalem] x [F12-64, win64, win32] -- Intel host
[Opteron_G1, Opteron_G2, Opteron_G3] x [F12-64, win64, win32] -- AMD host
Yielding successful boots in all cases.
Signed-off-by: john cooper <john.cooper@redhat.com>
Changes v1 -> v2:
- Rebase against latest Qemu git tree
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Use 'i64' instead of 'lm' and 'xd' instead of 'nx' on Intel models.
The flags have different names on Intel docs, so use those names for clarity.
This is based on a previous patch from John Cooper where this was introduced
with many other changes at the same time. Original John's patch submission is
at Message-ID: <4DDAD5E7.2020002@redhat.com>, <http://marc.info/?l=qemu-devel&m=130618871926030>.
Changes v1 -> v2:
- Rebase patch against latest Qemu git tree
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This will make it easier to review and change the flag list in the future.
No behaviour change should be introduced by this, as it is just changing
the flag order on the config file.
To make sure the flag sets are really not changed by this patch, I have
used the following stupid script to compare the flag values in the
config files:
https://gist.github.com/1004885
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This is a reimplementation of prior versions which adds
the ability to define cpu models for contemporary processors.
The added models are likewise selected via -cpu <name>,
and are intended to displace the existing convention
of "-cpu qemu64" augmented with a series of feature flags.
A primary motivation was determination of a least common
denominator within a given processor class to simplify guest
migration. It is still possible to modify an arbitrary model
via additional feature flags however the goal here was to
make doing so unnecessary in typical usage. The other
consideration was providing models names reflective of
current processors. Both AMD and Intel have reviewed the
models in terms of balancing generality of migration vs.
excessive feature downgrade relative to released silicon.
This version of the patch replaces the prior hard wired
definitions with a configuration file approach for new
models. Existing models are thus far left as-is but may
easily be transitioned to (or may be overridden by) the
configuration file representation.
Proposed new model definitions are provided here for current
AMD and Intel processors. Each model consists of a name
used to select it on the command line (-cpu <name>), and a
model_id which corresponds to a least common denominator
commercial instance of the processor class.
A table of names/model_ids may be queried via "-cpu ?model":
:
x86 Opteron_G3 AMD Opteron 23xx (Gen 3 Class Opteron)
x86 Opteron_G2 AMD Opteron 22xx (Gen 2 Class Opteron)
x86 Opteron_G1 AMD Opteron 240 (Gen 1 Class Opteron)
x86 Nehalem Intel Core i7 9xx (Nehalem Class Core i7)
x86 Penryn Intel Core 2 Duo P9xxx (Penryn Class Core 2)
x86 Conroe Intel Celeron_4x0 (Conroe/Merom Class Core 2)
:
Also added is "-cpu ?dump" which exhaustively outputs all config
data for all defined models, and "-cpu ?cpuid" which enumerates
all qemu recognized CPUID feature flags.
The pseudo cpuid flag 'check' when added to the feature flag list
will warn when feature flags (either implicit in a cpu model or
explicit on the command line) would have otherwise been quietly
unavailable to a guest:
# qemu-system-x86_64 ... -cpu Nehalem,check
warning: host cpuid 0000_0001 lacks requested flag 'sse4.2|sse4_2' [0x00100000]
warning: host cpuid 0000_0001 lacks requested flag 'popcnt' [0x00800000]
A similar 'enforce' pseudo flag exists which in addition
to the above causes qemu to error exit if requested flags are
unavailable.
Configuration data for a cpu model resides in the target config
file which by default will be installed as:
/usr/local/etc/qemu/target-<arch>.conf
The format of this file should be self explanatory given the
definitions for the above six models and essentially mimics
the structure of the static x86_def_t x86_defs.
Encoding of cpuid flags names now allows aliases for both the
configuration file and the command line which reconciles some
Intel/AMD/Linux/Qemu naming differences.
This patch was tested relative to qemu.git.
Signed-off-by: john cooper <john.cooper@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Tanish Desai
Paolo Bonzini
Marc-André Lureau
Manos Pitsidianakis
John Snow
Eduardo Habkost
Markus Armbruster
Daniel P. Berrange
Bastian Koppelmann
john cooper