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>
pclmulqdq: /proc/cpuinfo on Linux and all documentation I have seen uses
pclmulqdq as the flag name. As the only document using pclmuldq seems to
be the Intel CPUID documentation (Application Note 485), it looks like a
typo and not the correct name for the flag.
ffxsr: AMD docs refer to fxsr_opt as ffxsr, so allow this named to be
used too.
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 has been the de facto situation for a while now.
Add a tree, too.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Tested-by: Andreas F=E4rber <afaerber@suse.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Make qemu-bridge-helper explicitly depend on $(GENERATED_HEADERS)
so that it doesn't fail to build when we configured for linux-user
targets only. (Build breakage introduced in commit 7b93fad.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Make kernel, initrd, append be machine opts (ie -machine kernel=foo)
with the old plain command line arguments as legacy/convenience
equivalents.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Some simplifications in I/O functions are possible because
Jazz LED only registers one byte of I/O.
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Assert the object is at least sizeof(Object), not sizeof(ObjectClass).
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
As we make upper bits in IO and prefetcheable memory
registers writeable, we should declare support
for 64 bit prefetcheable memory and 32 bit io
in the bridge.
This changes the default for apb, dec, but I'm guessing
they got the defaults wrong by accident.
Alternatively, we could let bridges declare lack of
64 bit support and make the upper bits read-only zero.
With this applied, we can drop these bits
from express code.
Reported-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Could someone familiar with apb,dec ack this please?
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
pci_regs.h specifies many registers by mask +
shifted register values.
There's always some duplication when using such:
for example to override device type, we would need:
pci_word_test_and_clear_mask(cap + PCI_EXP_FLAGS,
PCI_EXP_FLAGS_TYPE);
pci_word_test_and_set_mask(cap + PCI_EXP_FLAGS,
PCI_EXP_TYPE_ENDPOINT << (ffs(PCI_EXP_FLAGS_TYPE) - 1));
Getting such registers also uses some duplication:
word = pci_get_word(cap + PCI_EXP_FLAGS) & PCI_EXP_FLAGS_TYPE;
if ((word >> ffs((PCI_EXP_FLAGS_TYPE) - 1)) == PCI_EXP_TYPE_ENDPOINT)
Add API to access such registers in one line:
pci_set_word_by_mask(cap + PCI_EXP_FLAGS, PCI_EXP_FLAGS_TYPE,
PCI_EXP_TYPE_ENDPOINT)
and
word = pci_get_word_by_mask(cap + PCI_EXP_FLAGS, PCI_EXP_FLAGS_TYPE)
if (word == PCI_EXP_TYPE_ENDPOINT)
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
object_property_add_child() creates a property whose values as a string is
the child object's canonical path.
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Alexander Barabash <alexander_barabash@mentor.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Now, the pc-sysfw:rom_only property will default
to false which enables flash by default.
All pc types below pc-1.1 set rom_only to true.
This prevents flash from being enabled on these
pc machine types.
For pc-1.1 rom_only will use the default (false),
which will allow flash to be used for pc-1.1.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Flash can be enabled by calling pc_system_firmware_init
with the system_flash_enabled parameter being non-zero.
If system_flash_enabled is zero, then the older qemu
rom creation method will be used.
If flash is enabled and a pflash image is found, then
it is used for the system firmware image.
If flash is enabled and a pflash image is not initially
found, then a read-only pflash device is created using
the -bios filename.
KVM cannot execute from a pflash region currently.
Therefore, when KVM is enabled, the old rom based
initialization method is used.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Setup a pc-sysfw device type. It contains a single
property of 'rom_only' which is defaulted to enabled.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
More qdev printers could have been removed in the previous series, and
object_property_parse also made several parsers unnecessary. In fact,
the new code is even more robust with respect to overflows, so clean
them up!
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
object_property_parse lets us drop the legacy setters when their task
is done just as well by the string visitors.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Hex properties are an obstacle to removal of old qdev string parsing, but
even here we can lay down the foundations for future simplification. In
general, they are rarely used and their printed form is more interesting
than the parsing. For example you'd usually set isa-serial.index
instead of isa-serial.iobase. And luckily our main client, libvirt
only cares about few of these, and always sets them with a 0x prefix.
So the series stops accepting bare hexadecimal numbers, preparing for
making legacy properties read-only in 1.3 or so. The read side will
stay as long as "info qtree" is with us.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Visitors allow a limited form of polymorphism. Exploit it to support
setting the non-legacy PCI address property both as a DD.F string
and as an 8-bit integer.
The 8-bit integer form is just too clumsy, it is unlikely that we will
ever drop it.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add generic property accessors that take a string and parse it
appropriately for the property type. All the magic here is done
by the new string-based visitors.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add two properties to specify bar sizes in megabytes instead of bytes,
which is alot more user-friendly.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
There is no reason to require a minimum size of 16 MB for the vram.
Lower the limit to 4096 (one page). Make it disapper completely would
break guests.
With the acceptance of some new APIs to libspice-server.so it
is possible to add support for SPICE to the 'add_client'
monitor command, bringing parity with VNC. Since SPICE can
use TLS or plain connections, the command also gains a new
'tls' parameter to specify whether TLS should be attempted
on the injected client sockets.
This new feature is only enabled if building against a
libspice-server >= 0.10.1
* qmp-commands.hx: Add 'tls' parameter & missing doc for
'skipauth' parameter
* monitor.c: Wire up SPICE for 'add_client' command
* ui/qemu-spice.h, ui/spice-core.c: Add qemu_spice_display_add_client
API to wire up from monitor
[1] http://cgit.freedesktop.org/spice/spice/commit/server/spice.h?id=d55b68b6b44f2499278fa860fb47ff22f5011faahttp://cgit.freedesktop.org/spice/spice/commit/server/spice.h?id=bd07dde530d9504e1cfe7ed5837fc00c26f36716
Changes in v3:
- Added 'optional' flag to new parameters documented
- Added no-op impl of qemu_spice_display_add_client when
SPICE is disabled during build
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
We used to assure the guest surfaces were saved before migration by
setting the whole vram dirty. This patch sets dirty only the areas
that are actually used in the vram.
Signed-off-by: Yonit Halperin <yhalperi@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patch fixes the local qxl renderer to not kick spice-server
in case the vm is stopped. First it is largely pointless because
we ask spice-server to process all not-yet processed commands when
the vm is stopped, so there isn't much do do anyway. Second we
avoid triggering an assert in spice-server.
The patch makes sure we still honor redraw requests, even if we don't
ask spice-server for updates. This is needed to handle displaysurface
changes with a stopped vm correctly.
With this patch applied it is possible to take screen shots (via
screendump monitor command) from a qxl gpu even in case the guest
is stopped.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
String based visitors provide a consistent interface for parsing
strings to C values, as well as consuming C values as strings.
They will be used to parse command-line options.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Trying to interact with a stopped guest will queue up the events,
then send them all at once when the guest continues running, with
a high chance to have them cause unwanted actions.
Avoid that by only injecting the input events only when the guest
is in running state.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
When an input line is handled as level-triggered, it will immediately
raise an IRQ on the output of a PIC again that goes through an init
reset. So only clear the edge-triggered inputs from IRR in that
scenario.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Instead of providing 4 individual query functions for mode, gate, output
and initial counter state, introduce a service that queries all
information at once. This comes with tiny additional costs for
pcspk_callback but with a much cleaner interface. Also, it will simplify
the implementation of the KVM in-kernel PIT model.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Convert the PC speaker device to a qdev ISA model. Move the public
interface to a dedicated header file at this chance.
CC: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
When the HPET enters legacy mode, the IRQ output of the PIT is
suppressed and replaced by the HPET timer 0. But the current code to
emulate this was broken in many ways. It reset the PIT state after
re-enabling, it worked against a stale static PIT structure, and it did
not properly saved/restored the IRQ output mask in the PIT vmstate.
This patch solves the PIT IRQ control in a different way. On x86, it
both redirects the PIT IRQ to the HPET, just like the RTC. But it also
keeps the control line from the HPET to the PIT. This allows to disable
the PIT QEMU timer when it is not needed. The PIT's view on the control
line state is now saved in the same format that qemu-kvm is already
using.
Note that, in contrast to the suppressed RTC IRQ line, we do not need to
save/restore the PIT line state in the HPET. As we trigger a PIT IRQ
update via the control line, the line state is reconstructed on mode
switch.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
