aboutsummaryrefslogtreecommitdiff
path: root/hw/i386/pc_q35.c
AgeCommit message (Collapse)Author
2015-11-04pc: Set hw_version on all machine classesEduardo Habkost
In 2012, QEMU had a bug where it exposed QEMU version information to the guest, meaning a QEMU upgrade would expose different hardware to the guest OS even if the same machine-type is being used. The bug was fixed by commit 93bfef4c6e4b23caea9d51e1099d06433d8835a4, on all machines up to pc-1.0. But we kept introducing the same bug on all newer machines since then. That means we are breaking guest ABI every time QEMU was upgraded. Fix this by setting the hw_version on all PC machines, making sure the hardware won't change when upgrading QEMU. Note that QEMU_VERSION was "1.0" in QEMU 1.0, but starting on QEMU 1.1.0, it started following the "x.y.0" pattern. We have to follow it, to make sure we use the right QEMU_VERSION string from each QEMU release. The 2.5 machine classes could have hw_version unset, because the default value for qemu_get_version() is QEMU_VERSION. But I decided to set it explicitly to QEMU_VERSION so we don't forget to update it to "2.5.0" after we release 2.5.0 and create a 2.6 machine class. Reported-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <1446233769-7892-2-git-send-email-ehabkost@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-10-29Revert "pc: memhp: force gaps between DIMM's GPA"Michael S. Tsirkin
This reverts commit aa8580cddf011e8cedcf87f7a0fdea7549fc4704. As described in http://article.gmane.org/gmane.comp.emulators.qemu/371432 that commit causes linux guests to crash on memory hot-unplug. The original problem it's trying to solve has now been addressed within virtio. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-10-22i386: keep cpu_model field in MachineState uptodateZhu Guihua
Update cpu_model in MachineState for i386, so that the field can be used for cpu hotplug, instead of using a static variable. This patch is rebased on the latest master. Signed-off-by: Zhu Guihua <zhugh.fnst@cn.fujitsu.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Acked-by: Andreas Färber <afaerber@suse.de>
2015-10-02cpu/apic: drop icc bus/bridgeChen Fan
After CPU hotplug has been converted to BUS-less hot-plug infrastructure, the only function ICC bus performs is to propagate reset to LAPICs. However LAPIC could be reset by registering its reset handler after all device are initialized. Do so and drop ~30LOC of not needed anymore ICCBus related code. Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com> Signed-off-by: Zhu Guihua <zhugh.fnst@cn.fujitsu.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2015-10-02target-i386: Convert kvm_default_*features to property/value pairsEduardo Habkost
Convert the kvm_default_features and kvm_default_unset_features arrays into a simple list of property/value pairs that will be applied to X86CPU objects when using KVM. Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2015-10-02pc: memhp: force gaps between DIMM's GPAIgor Mammedov
mapping DIMMs non contiguously allows to workaround virtio bug reported earlier: http://lists.nongnu.org/archive/html/qemu-devel/2015-08/msg00522.html in this case guest kernel doesn't allocate buffers that can cross DIMM boundary keeping each buffer local to a DIMM. Suggested-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-10-01pc: Add a comment explaining why pc_compat_2_4() doesn't existEduardo Habkost
pc_compat_2_4() doesn't exist, and we shouldn't create one. Add a comment explaining why the function doesn't exist and why pc_compat_*() functions are deprecated. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-09-24pc: Introduce pc-*-2.5 machine classesEduardo Habkost
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-09-24q35: Move options common to all classes to pc_q35_machine_options()Eduardo Habkost
The existing default_machine_opts, default_display, no_floppy, and no_tco settings will still apply to future machine classes. So it makes sense to move them to pc_q35_machine_options() instead of keeping them in a version-specific machine_options function. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-09-10pc: memhotplug: keep reserved-memory-end broken on 2.4 and earlier machinesIgor Mammedov
it will prevent guests on old machines from seeing inconsistent memory mapping in firmware/ACPI views. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
2015-09-10pc: Remove redundant arguments from xen_hvm_init()Eduardo Habkost
Remove arguments that can be found in PCMachineState. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-09-07smbios: add smbios 3.0 supportWei Huang
This patch adds support for SMBIOS 3.0 entry point. When caller invokes smbios_set_defaults(), it can specify entry point as 2.1 or 3.0. Then smbios_get_tables() will return the entry point table in right format. Acked-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Wei Huang <wei@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-id: 1440615870-9518-2-git-send-email-wei@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-08-13smbios: move smbios code into a common folderWei Huang
To share smbios among different architectures, this patch moves SMBIOS code (smbios.c and smbios.h) from x86 specific folders into new hw/smbios directories. As a result, CONFIG_SMBIOS=y is defined in x86 default config files. Acked-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Wei Huang <wei@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-08-13pc: Remove redundant arguments from pc_memory_init()Eduardo Habkost
Remove arguments that can be found in PCMachineState. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-08-13pc: Remove redundant arguments from pc_cmos_init()Eduardo Habkost
Remove arguments that can be found in PCMachineState. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-08-13pc: Use PCMachineState as pc_guest_info_init() argumentEduardo Habkost
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-08-13pc: Move {above,below}_4g_mem_size variables to PCMachineStateEduardo Habkost
This will make the info readily available for the other initialization functions, and will allow us to simplify their argument list. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-08-13pc: Use PCMachineState for pc_memory_init() argumentEduardo Habkost
pc_memory_init() already expects a PCMachineState object, there's no point in upcasting it to MachineState before calling the function. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-08-13pc: Use PCMachineState for pc_cmos_init() argumentEduardo Habkost
pc_cmos_init() already expects a PCMachineState object, there's no point in upcasting it to MachineState before calling the function. While doing it, reorder the arguments so PCMachineState is the first function argument. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-08-13pc: Eliminate pc_default_machine_options()Eduardo Habkost
The only PC machines that didn't call pc_default_machine_options() were isaps and xenfv. Both were already overwriting max_cpus, and only isapc was not overwriting hot_add_cpu. After making isapc set hot_add_cpu to NULL, we can move the pc_default_machine_options() code the PC common class_init. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-08-13pc: Rename pc_machine variables to pcmsEduardo Habkost
Make the code use the same variable name everywhere. "pcms" is already being used in existing code and it's shorter. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-08-13pc: Use PC_COMPAT_* for CPUID feature compatibilityEduardo Habkost
Now we can use compat_props to keep CPUID feature compatibility, using the boolean QOM properties for CPUID feature flags. This simplifies the compatibility code, and reduces duplication between pc_piix.c and pc_q35.c. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-07-08Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell
pc,virtio,pci: fixes and updates Most notably, this includes the TCO support for ICH: the last feature for 2.4 as we are entering the hard freeze. Bugfixes only from now on. virtio pci also gained cfg access capability - arguably a bugfix since virtio spec makes it mandatory, but it's a big patch. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Wed Jul 8 10:40:07 2015 BST using RSA key ID D28D5469 # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" * remotes/mst/tags/for_upstream: tco-test: fix up config accesses and re-enable virtio fix cfg endian-ness for BE targets virtio-pci: implement cfg capability virtio: define virtio_pci_cfg_cap in header. pcie: Set the "link active" in the link status register pci_regs.h: import from linux virtio_net: reuse constants from linux hw/i386/pc: don't carry FDC from pc_basic_device_init() to pc_cmos_init() hw/i386/pc: reflect any FDC @ ioport 0x3f0 in the CMOS hw/i386/pc: factor out pc_cmos_init_floppy() ich9: implement strap SPKR pin logic tests: add testcase for TCO watchdog emulation ich9: add TCO interface emulation acpi: split out ICH ACPI support Revert "dataplane: allow virtio-1 devices" dataplane: fix cross-endian issues Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-07-08hw/i386/pc: don't carry FDC from pc_basic_device_init() to pc_cmos_init()Laszlo Ersek
Thanks to the last patch, pc_cmos_init() doesn't need the (optional) board-default FDC any longer as an input parameter. Update pc_basic_device_init() not to hand it back to pc_init1() / pc_q35_init(), and update the latter not to carry the FDC to pc_cmos_init(). This simplifies the code. pc_init1() | pc_q35_init() pc_basic_device_init() pc_cmos_init() Cc: Jan Tomko <jtomko@redhat.com> Cc: John Snow <jsnow@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-07-07migration: Add configuration sectionJuan Quintela
It needs to be the first one and it is not optional, that is the reason why it is opencoded. For new machine types, it is required that machine type name is the same in both sides. It is just done right now for pc's. Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2015-07-07global_state: Make section optionalJuan Quintela
This section would be sent: a- for all new machine types b- for old machine types if section state is different form {running,paused} that were the only giving us troubles. So, in new qemus: it is alwasy there. In old qemus: they are only there if it an error has happened, basically stoping on target. Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2015-07-07ich9: add TCO interface emulationPaulo Alcantara
This interface provides some registers within a 32-byte range and can be acessed through PCI-to-LPC bridge interface (PMBASE + 0x60). It's commonly used as a watchdog timer to detect system lockups through SMIs that are generated -- if TCO_EN bit is set -- on every timeout. If NO_REBOOT bit is not set in GCS (General Control and Status register), the system will be resetted upon second timeout if TCO_RLD register wasn't previously written to prevent timeout. This patch adds support to TCO watchdog logic and few other features like mapping NMIs to SMIs (NMI2SMI_EN bit), system intruder detection, etc. are not implemented yet. Signed-off-by: Paulo Alcantara <pcacjr@zytor.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-07-06pc: add SMM propertyPaolo Bonzini
The property can take values on, off or auto. The default is "off" for KVM and pre-2.4 machines, otherwise "auto" (which makes it available on TCG or on new-enough kernels). Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-07-06ich9: add smm_enabled field and argumentsPaolo Bonzini
Q35's ACPI device is hard-coding SMM availability to KVM. Place the logic where the board is created instead, so that it will be possible to override it. Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-06-19q35: Re-enable FDC on pc-q35-2.3 and olderEduardo Habkost
commit ea96bc629cbd52be98b2967a4b4f72e91dfc3ee4 doesn't match the patch submitted by Laszlo to qemu-devel. We reuse pc_q35_2_4_machine_options() inside pc_q35_2_3_machine_options(), so we need to undo the no_floppy change in pc_q35_2_3_machine_options(). (This discrepancy was due to a bad merge.) This restores the previous behavior where all the 2.3 and older machines had no_floppy=0. Reported-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-id: 1434646168-3100-1-git-send-email-ehabkost@redhat.com Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> [PMM: mention that this was a merge issue, not a review issue] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-06-12Disable section footers on older machine typesDr. David Alan Gilbert
The next patch adds section footers; but we don't want to break migration compatibility so disable them on older machine types Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2015-06-03hw/i386/pc: Fix misusing qemu_allocate_irqs for single irqShannon Zhao
Since pc_allocate_cpu_irq only requests one irq, so let it just call qemu_allocate_irq. Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2015-05-31i386: drop FDC in pc-q35-2.4+ if neither it nor floppy drives are wantedLaszlo Ersek
It is Very annoying to carry forward an outdatEd coNtroller with a mOdern Machine type. Hence, let us not instantiate the FDC when all of the following apply: - the machine type is pc-q35-2.4 or later, - "-device isa-fdc" is not passed on the command line (nor in the config file), - no "-drive if=floppy,..." is requested. Cc: Markus Armbruster <armbru@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: John Snow <jsnow@redhat.com> Cc: "Gabriel L. Somlo" <gsomlo@gmail.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: qemu-block@nongnu.org Suggested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
2015-05-31i386/pc_q35: don't insist on board FDC if there's no default floppyLaszlo Ersek
The "no_floppy = 1" machine class setting causes "default_floppy" in main() to become zero. Consequently, default_drive() will not call drive_add() and drive_new() for IF_FLOPPY, index=0, meaning that no default floppy drive will be created for the virtual machine. In that case, board code should also not insist on the creation of the board-default FDC. The board-default FDC will still be created if the user requests a floppy drive with "-drive if=floppy". Additionally, separate FDCs can be specified manually with "-device isa-fdc". They allow the -device isa-fdc,driveA=... syntax that is more flexible than the one required by the board-default FDC: -global isa-fdc.driveA=... This patch doesn't change the behavior observably, as all Q35 machine types have "no_floppy = 0". Cc: Markus Armbruster <armbru@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: John Snow <jsnow@redhat.com> Cc: "Gabriel L. Somlo" <gsomlo@gmail.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: qemu-block@nongnu.org Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
2015-05-31i386/pc: pc_basic_device_init(): delegate FDC creation requestLaszlo Ersek
This patch introduces no observable change, but it allows the callers of pc_basic_device_init(), ie. pc_init1() and pc_q35_init(), to request (or not request) the creation of the FDC explicitly. At the moment both callers pass constant create_fdctrl=true (hence no observable change). Assuming a board passes create_fdctrl=false, "floppy" will be NULL on output, and (beyond the FDC not being created) that NULL will be passed on to pc_cmos_init(). Luckily, pc_cmos_init() already handles that case. Cc: Markus Armbruster <armbru@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: John Snow <jsnow@redhat.com> Cc: "Gabriel L. Somlo" <gsomlo@gmail.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: qemu-block@nongnu.org Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
2015-05-31pc: Generate init functions with a macroEduardo Habkost
All pc-i440fx and pc-q35 init functions simply call the corresponding compat function and then call the main init function. Use a macro to generate that code. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-05-31pc: Don't use QEMUMachine anymoreEduardo Habkost
Now that we have a DEFINE_PC_MACHINE helper macro that just requires an initialization function, it is trivial to convert them to register a QOM machine class directly, instead of using QEMUMachine. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-05-31pc: Move compat_props setting inside *_machine_options() functionsEduardo Habkost
This will simplify the DEFINE_PC_MACHINE macro, and will help us to implement reuse of PC_COMPAT_* macros through class_init function reuse, in the future. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-05-31pc: Convert *_MACHINE_OPTIONS macros into functionsEduardo Habkost
By now the new functions will get QEMUMachine as argument, but they will be later converted to initialize a MachineClass struct directly. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-05-31pc: Define machines using a DEFINE_PC_MACHINE macroEduardo Habkost
This will automatically generate the existing QEMUMachine structs based on the *_MACHINE_OPTIONS macros, and automatically add registration code for them. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-05-31pc: Define MACHINE_OPTIONS macros consistently for all machinesEduardo Habkost
Define a MACHINE_OPTIONS macro for each PC machine, and move every field inside the QEMUMachine structs to the macros, except for name, init, and compat_props. This also ensures that all MACHINE_OPTIONS inherit the fields from the next version, so their definitions carry only the changes that exist between one version and the next one. Comments about specific cases: pc-*-2.1: Existing PC_*_2_1_MACHINE_OPTIONS macros were defined as: PC_*_MACHINE_OPTIONS, .default_machine_opts = "firmware=bios-256k.bin" PC_*_2_2_MACHINE_OPTIONS is: PC_*_2_3_MACHINE_OPTIONS which is expanded to: PC_*_MACHINE_OPTIONS, .default_machine_opts = "firmware=bios-256k.bin", .default_display = "std" The only difference between 2_1 and 2_2 is .default_display, that's why we didn't reuse PC_*_2_2_MACHINE_OPTIONS. The good news is that having multiple initializers for a field is allowed by C99, and the last initializer overrides the previous ones. So we can reuse the 2_2 macro in 2_1 and define PC_*_2_1_MACHINE_OPTIONS as: PC_*_2_2_MACHINE_OPTIONS, .default_display = NULL pc-*-1.7: PC_*_1_7_MACHINE_OPTIONS was defined as: PC_*_MACHINE_OPTIONS PC_*_2_0_MACHINE_OPTIONS is defined as: PC_*_2_1_MACHINE_OPTIONS which is expanded to: PC_*_2_2_MACHINE_OPTIONS, .default_display = NULL which is expanded to: PC_*_2_3_MACHINE_OPTIONS, .default_display = NULL which is expanded to: PC_*_MACHINE_OPTIONS, .default_machine_opts = "firmware=bios-256k.bin", .default_display = "std", .default_display = NULL /* overrides the previous line */ So, the only difference between PC_*_1_7_MACHINE_OPTIONS and PC_*_2_0_MACHINE_OPTIONS is .default_machine_opts (as .default_display is not explicitly set by PC_*_MACHINE_OPTIONS so it is NULL). So we can keep the macro reuse pattern and define PC_*_2_0_MACHINE_OPTIONS as: PC_*_2_0_MACHINE_OPTIONS, .default_machine_opts = NULL pc-*-2.4 (alias and is_default fields): Set alias and is_default fields inside the 2.4 MACHINE_OPTIONS macro, and clear it in the 2.3 macro (that reuses the 2.4 macro). hw_machine: As all the machines older than v1.0 set hw_version explicitly, we can safely move the field to the MACHINE_OPTIONS macros without affecting the other versions that reuse them. init function: Some machines had the init function set inside the MACHINE_OPTIONS macro. Move it to the QEMUMachine declaration, to keep it consistent with the other machines. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-05-31pc: Define PC_COMPAT_2_[123] macrosEduardo Habkost
Once we start adding compat code for pc-2.3, the usage of HW_COMPAT_2_1 in pc-*-2.2 won't be enough, as it also has to include PC_COMPAT_2_3 inside it. To ensure that, define PC_COMPAT_2_3, PC_COMPAT_2_2, and PC_COMPAT_2_1 macros. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-05-31pc: Move commas inside PC_COMPAT_* macrosEduardo Habkost
Changing the convention to include commas inside the macros will allow macros containing empty lists to be defined and used without compilation errors. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-05-31hw: Move commas inside HW_COMPAT_2_1 macroEduardo Habkost
Changing the convention to include commas inside the macros will allow macros containing empty lists to be defined and used without compilation errors. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-04-27pc: add 2.4 machine typesJason Wang
The following patches will limit the following things to legacy machine type: - maximum number of virtqueues for virtio-pci were limited to 64 - auto msix bar size for virtio-net-pci were disabled by default Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-03-19Revert "target-i386: Disable HLE and RTM on Haswell & Broadwell"Eduardo Habkost
This reverts commit 13704e4c455770d500d6b87b117e32f0d01252c9. With the Intel microcode update that removed HLE and RTM, there will be different kinds of Haswell and Broadwell CPUs out there: some that still have the HLE and RTM features, and some that don't have the HLE and RTM features. On both cases people may be willing to use the pc-*-2.3 machine-types. So instead of making the CPU model results confusing by making it depend on the machine-type, keep HLE and RTM on the existing Haswell and Broadwell CPU models. The plan is to introduce "Haswell-noTSX" and "Broadwell-noTSX" CPU models later, for people who have CPUs that don't have TSX feature available. Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2015-03-16pc: Disable vmdesc submission for old machinesAlexander Graf
Older PC machine types might by accident be backwards live migration compatible, but with the new vmdesc self-describing blob in our live migration stream we would break that compatibility. Also users wouldn't expect massive behaviorial differences when updating to a new version of QEMU while retaining their old machine type, especially not potential breakage in tooling around live migration. So disable vmdesc submission for old PC machine types. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2015-02-26acpi: has_immutable_rsdp->!rsdp_in_ramMichael S. Tsirkin
As comment in acpi-build.c notes, RSDP is not really immutable. So it's really a question of whether it's in RAM, name the variable accordingly. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2015-02-26pc: acpi-build: migrate RSDP tableIgor Mammedov
Makes sure that RSDP stays the same /i.e. matches ACPI tables blob in source/ if guest is migrated during RSDP reading or has been already shadowed by firmware. Fix applies only to new machine types starting from 2.3, so it won't break migration for old machine types. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com>
2015-01-26target-i386: Disable HLE and RTM on Haswell & BroadwellEduardo Habkost
All Haswell CPUs and some Broadwell CPUs were updated by Intel to have the HLE and RTM features disabled. This will prevent "-cpu Haswell,enforce" and "-cpu Broadwell,enforce" from running out of the box on those CPUs. Disable those features by default on Broadwell and Haswell CPU models, starting on pc-*-2.3. Users who want to use those features can enable them explicitly on the command-line. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>