aboutsummaryrefslogtreecommitdiff
path: root/hw/i386/pc_q35.c
AgeCommit message (Collapse)Author
2014-11-04Merge remote-tracking branch 'remotes/afaerber/tags/qom-cpu-for-peter' into ↵Peter Maydell
staging QOM CPUState and X86CPU * Cleanups for -cpu ...,enforce * remotes/afaerber/tags/qom-cpu-for-peter: target-i386: Disable SVM by default in KVM mode target-i386: Don't enable nested VMX by default target-i386: Remove unsupported bits from all CPU models target-i386: Disable CPUID_ACPI by default in KVM mode target-i386: Rename KVM auto-feature-enable compat function pc: Create pc_compat_2_1() functions Conflicts: hw/i386/pc_piix.c hw/i386/pc_q35.c [PMM: Fixed minor textual conflicts] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2014-11-04target-i386: Disable SVM by default in KVM modeEduardo Habkost
Make SVM be disabled by default on all CPU models when in KVM mode. Nested SVM is enabled by default in the KVM kernel module, but it is probably less stable than nested VMX (which is already disabled by default). Add a new compat function, x86_cpu_compat_kvm_no_autodisable(), to keep compatibility on previous machine-types. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
2014-11-04target-i386: Don't enable nested VMX by defaultEduardo Habkost
TCG doesn't support VMX, and nested VMX is not enabled by default in the KVM kernel module. So, there's no reason to have VMX enabled by default on the core2duo and coreduo CPU models, today. Even the newer Intel CPU model definitions don't have it enabled. In this case, we need machine-type compat code, as people may be running the older machine-types on hosts that had VMX nesting enabled. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
2014-11-03target-i386: Rename KVM auto-feature-enable compat functionEduardo Habkost
The x86_cpu_compat_disable_kvm_features() name was a bit confusing, as it won't forcibly disable the feature for all CPU models (i.e. add it to kvm_default_unset_features), but it will instead turn off the KVM auto-enabling of the feature (i.e. remove it from kvm_default_features), meaning the feature may still be enabled by default in some CPU models). Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
2014-11-03pc: Create pc_compat_2_1() functionsEduardo Habkost
We will need new compat code for the 2.1 machine-types. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
2014-11-03vga: flip qemu 2.2 pc machine types from cirrus to stdvgaGerd Hoffmann
This patch switches the default display from cirrus to vga for the new (qemu 2.2+) machine types. Old machines types stay as-is for compatibility reasons. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-11-02smbios: Encode UUID according to SMBIOS specificationEduardo Habkost
Differently from older versions, SMBIOS version 2.6 is explicit about the encoding of UUID fields: > Although RFC 4122 recommends network byte order for all fields, the PC > industry (including the ACPI, UEFI, and Microsoft specifications) has > consistently used little-endian byte encoding for the first three fields: > time_low, time_mid, time_hi_and_version. The same encoding, also known as > wire format, should also be used for the SMBIOS representation of the UUID. > > The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented > as 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF. The dmidecode tool implements this and decodes the above "wire format" when SMBIOS version >= 2.6. We moved from SMBIOS version 2.4 to 2.8 when we started building the SMBIOS entry point inside QEMU, on commit c97294ec1b9e36887e119589d456557d72ab37b5. Change smbios_build_type_1_table() to encode the UUID as specified. To make sure we won't change the guest-visible UUID when upgrading to a newer QEMU version, keep the old behavior on pc-*-2.1 and older. 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>
2014-11-02pc: Add pc_compat_2_1() functionEduardo 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>
2014-11-02-machine vmport=off: Allow disabling of VMWare ioport emulationDr. David Alan Gilbert
This is a pc & q35 only machine opt. VMWare apparently doesn't like running under QEMU due to our incomplete emulation of it's special IO Port. This adds a pc & q35 property to allow it to be turned off. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Don Slutz <dslutz@verizon.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
2014-11-02pc: Update rtc_cmos in pc_cpu_plugGu Zheng
Update rtc_cmos in pc_cpu_plug() directly, instead of the notifier. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2014-11-02virtio-pci: fix migration for pci bus masterMichael S. Tsirkin
Current support for bus master (clearing OK bit) together with the need to support guests which do not enable PCI bus mastering, leads to extra state in VIRTIO_PCI_FLAG_BUS_MASTER_BUG bit, which isn't robust in case of cross-version migration for the case when guests use the device before setting DRIVER_OK. Rip out this code, and replace it: - Modern QEMU doesn't need VIRTIO_PCI_FLAG_BUS_MASTER_BUG so just drop it for latest machine type. - For compat machine types, set PCI_COMMAND if DRIVER_OK is set. As this is needed for 2.1 for both pc and ppc, move PC_COMPAT macros from pc.h to a new common header. Cc: Greg Kurz <gkurz@linux.vnet.ibm.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Alexander Graf <agraf@suse.de>
2014-11-02i386/pc: add piix and q35 machtypes to sorting families for -M \?Laszlo Ersek
With this patch applied, the output of -M \? is > Supported machines are: > pc Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.2) > pc-i440fx-2.2 Standard PC (i440FX + PIIX, 1996) (default) > pc-i440fx-2.1 Standard PC (i440FX + PIIX, 1996) > pc-i440fx-2.0 Standard PC (i440FX + PIIX, 1996) > pc-i440fx-1.7 Standard PC (i440FX + PIIX, 1996) > pc-i440fx-1.6 Standard PC (i440FX + PIIX, 1996) > pc-i440fx-1.5 Standard PC (i440FX + PIIX, 1996) > pc-i440fx-1.4 Standard PC (i440FX + PIIX, 1996) > pc-1.3 Standard PC (i440FX + PIIX, 1996) > pc-1.2 Standard PC (i440FX + PIIX, 1996) > pc-1.1 Standard PC (i440FX + PIIX, 1996) > pc-1.0 Standard PC (i440FX + PIIX, 1996) > pc-0.15 Standard PC (i440FX + PIIX, 1996) > pc-0.14 Standard PC (i440FX + PIIX, 1996) > pc-0.13 Standard PC (i440FX + PIIX, 1996) > pc-0.12 Standard PC (i440FX + PIIX, 1996) > pc-0.11 Standard PC (i440FX + PIIX, 1996) > pc-0.10 Standard PC (i440FX + PIIX, 1996) > q35 Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.2) > pc-q35-2.2 Standard PC (Q35 + ICH9, 2009) > pc-q35-2.1 Standard PC (Q35 + ICH9, 2009) > pc-q35-2.0 Standard PC (Q35 + ICH9, 2009) > pc-q35-1.7 Standard PC (Q35 + ICH9, 2009) > pc-q35-1.6 Standard PC (Q35 + ICH9, 2009) > pc-q35-1.5 Standard PC (Q35 + ICH9, 2009) > pc-q35-1.4 Standard PC (Q35 + ICH9, 2009) > isapc ISA-only PC > none empty machine RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1145042 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: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel.a@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au>
2014-10-31-machine vmport=off: Allow disabling of VMWare ioport emulationDr. David Alan Gilbert
This is a pc & q35 only machine opt. VMWare apparently doesn't like running under QEMU due to our incomplete emulation of it's special IO Port. This adds a pc & q35 property to allow it to be turned off. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Don Slutz <dslutz@verizon.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2014-10-22hw/i386/pc_q35.c: Avoid g_assert_cmpint() as it is not in glib 2.12Peter Maydell
The function g_assert_cmpint() is not in glib 2.12, which is our current minimum requirement. Rephrase the recently added assertion to avoid it. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Gonglei <arei.gonglei@huawei.com>
2014-10-03q35/ahci: Pick up -cdrom and -hda optionsJohn Snow
This patch implements the backend for the Q35 board for us to be able to pick up and use drives defined by the -cdrom, -hda, or -drive if=ide shorthand options. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 1412187569-23452-7-git-send-email-jsnow@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-10-03pc/vl: Add units-per-default-bus propertyJohn Snow
This patch adds the 'units_per_default_bus' property which allows individual boards to declare their desired index => (bus,unit) mapping for their default HBA, so that boards such as Q35 can specify that its default if_ide HBA, AHCI, only accepts one unit per bus. This property only overrides the mapping for drives matching the block_default_type interface. This patch also adds this property to *all* past and present Q35 machine types. This retroactive addition is justified because the previous erroneous index=>(bus,unit) mappings caused by lack of such a property were not utilized due to lack of initialization code in the Q35 init routine. Further, semantically, the Q35 board type has always had the property that its default HBA, AHCI, only accepts one unit per bus. The new code added to add devices to drives relies upon the accuracy of this mapping. Thus, the property is applied retroactively to reduce complexity of allowing IDE HBAs with different units per bus. Examples: Prior to this patch, all IDE HBAs were assumed to use 2 units per bus (Master, Slave). When using Q35 and AHCI, however, we only allow one unit per bus. -hdb foo.qcow2 would become index=1, or bus=0,unit=1. -hdd foo.qcow2 would become index=3, or bus=1,unit=1. -drive file=foo.qcow2,index=5 becomes bus=2,unit=1. These are invalid for AHCI. They now become, under Q35 only: -hdb foo.qcow2 --> index=1, bus=1, unit=0. -hdd foo.qcow2 --> index=3, bus=3, unit=0. -drive file=foo.qcow2,index=5 --> bus=5,unit=0. The mapping is adjusted based on the fact that the default IF for the Q35 machine type is IF_IDE, and units-per-default-bus overrides the IDE mapping from its default of 2 units per bus to just 1 unit per bus. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 1412187569-23452-4-git-send-email-jsnow@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-08-25pc: reserve more memory for ACPI for new machine typesMichael S. Tsirkin
commit 868270f23d8db2cce83e4f082fe75e8625a5fbf9 acpi-build: tweak acpi migration limits broke kernel loading with -kernel/-initrd: it doubled the size of ACPI tables but did not reserve enough memory. As a result, issues on boot and halt are observed. Fix this up by doubling reserved memory for new machine types. Cc: qemu-stable@nongnu.org Reported-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-08-18Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into ↵Peter Maydell
staging Block pull request # gpg: Signature made Fri 15 Aug 2014 18:04:23 BST using RSA key ID 81AB73C8 # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" # gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>" * remotes/stefanha/tags/block-pull-request: (55 commits) qcow2: fix new_blocks double-free in alloc_refcount_block() image-fuzzer: Reduce number of generator functions in __init__ image-fuzzer: Add generators of L1/L2 tables image-fuzzer: Add fuzzing functions for L1/L2 table entries docs: Expand the list of supported image elements with L1/L2 tables image-fuzzer: Public API for image-fuzzer/runner/runner.py image-fuzzer: Generator of fuzzed qcow2 images image-fuzzer: Fuzzing functions for qcow2 images image-fuzzer: Tool for fuzz tests execution docs: Specification for the image fuzzer ide: only constrain read/write requests to drive size, not other types virtio-blk: Correct bug in support for flexible descriptor layout libqos: Change free function called in malloc libqos: Correct mask to align size to PAGE_SIZE in malloc-pc libqtest: add QTEST_LOG for debugging qtest testcases ide: Fix segfault when flushing a device that doesn't exist qemu-options: add missing -drive discard option to cmdline help parallels: 2TB+ parallels images support parallels: split check for parallels format in parallels_open parallels: replace tabs with spaces in block/parallels.c ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2014-08-15q35: Enable the ioapic device to be seen by qtest.John Snow
Currently, the ioapic device can not be found in a qtest environment when requesting "irq_interrupt_in ioapic" via the qtest socket. By mirroring how the ioapic is added in i44ofx (hw/i440/pc_piix.c), as a child of "q35," the device is able to be seen by qtest. Signed-off-by: John Snow <jsnow@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-08-14pc: Get rid of pci-info leftoversMarkus Armbruster
pc_fw_cfg_guest_info() never does anything, because has_pci_info is always false. Introduced in commit f8c457b "pc: pass PCI hole ranges to Guests", disabled in commit 9604f70 "pc: disable pci-info for 1.6", and hasn't been enabled since. Obviously a dead end. Get of it. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-08-14pc: Create 2.2 machine typeJan Kiszka
Yet identical to 2.1. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-07-28pc: hack for migration compatibility from QEMU 2.0Paolo Bonzini
Changing the ACPI table size causes migration to break, and the memory hotplug work opened our eyes on how horribly we were breaking things in 2.0 already. The ACPI table size is rounded to the next 4k, which one would think gives some headroom. In practice this is not the case, because the user can control the ACPI table size (each CPU adds 97 bytes to the SSDT and 8 to the MADT) and so some "-smp" values will break the 4k boundary and fail to migrate. Similarly, PCI bridges add ~1870 bytes to the SSDT. This patch concerns itself with fixing migration from QEMU 2.0. It computes the payload size of QEMU 2.0 and always uses that one. The previous patch shrunk the ACPI tables enough that the QEMU 2.0 size should always be enough; non-AML tables can change depending on the configuration (especially MADT, SRAT, HPET) but they remain the same between QEMU 2.0 and 2.1, so we only compute our padding based on the sizes of the SSDT and DSDT. Migration from QEMU 1.7 should work for guests that have a number of CPUs other than 12, 13, 14, 54, 55, 56, 97, 98, 139, 140. It was already broken from QEMU 1.7 to QEMU 2.0 in the same way, though. Even with this patch, QEMU 1.7 and 2.0 have two different ideas of "-M pc-i440fx-2.0" when there are PCI bridges. Igor sent a patch to adopt the QEMU 1.7 definition. I think distributions should apply it if they move directly from QEMU 1.7 to 2.1+ without ever packaging version 2.0. Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-07-18Fix new typos in comments (found by codespell)Stefan Weil
arbitary -> arbitrary basicly -> basically Signed-off-by: Stefan Weil <sw@weilnetz.de> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2014-06-29pc: Move q35 compat props to PC_COMPAT_*Eduardo Habkost
For each compat property on PC_Q35_COMPAT_*, there are only two possibilities: * If the device is never instantiated when using a machine other than pc-q35, then the compat property can be safely added to PC_COMPAT_*; * If the device can be instantiated when using a machine other than pc-q35, that means the other machines also need the compat property to be set. That means we don't need separate PC_Q35_COMPAT_* macros at all, today. The hpet.hpet-intcap case is interesting: piix and q35 do have something that emulates different defaults, but the machine-specific default is applied _after_ compat_props are applied, by simply checking if the property is zero (which is the real default on the hpet code). The hpet.hpet-intcap=0x4 compat property can (should?) be applied to piix too, because 0x4 was the default on both piix and q35 before the hpet-intcap property was introduced. Now, if one day we change the default HPET intcap on one of the PC machine-types again, we may want to introduce PC_{Q35,I440FX}_COMPAT macros. But while we don't need that, we can keep the code simple. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Cc: Liu Ping Fan <pingfank@linux.vnet.ibm.com> Cc: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-06-23pc & q35: Add new machine opt max-ram-below-4gDon Slutz
This is a pc & q35 only machine opt. If you add enough PCI devices then all mmio for them will not fit below 4G which may not be the layout the user wanted. This allows you to increase the below 4G address space that PCI devices can use (aka decrease ram below 4G) and therefore in more cases not have any mmio that is above 4G. For example using "-machine pc,max-ram-below-4g=2G" on the command line will limit the amount of ram that is below 4G to 2G. Note: this machine option cannot be used to increase the amount of ram below 4G. Signed-off-by: Don Slutz <dslutz@verizon.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> MST: fix 32 bit
2014-06-23xen-hvm: Fix xen_hvm_init() to adjust pc memory layoutDon Slutz
This is just below_4g_mem_size and above_4g_mem_size which is used later in QEMU. Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Don Slutz <dslutz@verizon.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-06-23q35: Use PC_Q35_COMPAT_1_4 on pc-q35-1.4 compat_propsEduardo Habkost
pc-q35-1.4 was incorrectly using PC_COMPAT_1_4 instead of PC_Q35_COMPAT_1_4. The only side-effect was that the hpet compat property (inherited from PC_Q35_COMPAT_1_7) was missing. Without this patch, pc-q35-1.4 inicorrectly initializes hpet-intcap to 0xff0104 (behavior introduced in QEMU 2.0, by commit 7a10ef51c2397ac4323bc786af02c58b413b5cd2). 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> Reviewed-by: Markus Armbruster <armbru@redhat.com>
2014-06-19pc: pass MachineState to pc_memory_initPaolo Bonzini
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-By: Igor Mammedov <imammedo@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-06-19pc: add acpi-device link to PCMachineStateIgor Mammedov
the link will used later to access device implementing ACPI functions instead of adhoc lookup in QOM tree. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-06-19pc: add 'etc/reserved-memory-end' fw_cfg interface for SeaBIOSIgor Mammedov
'etc/reserved-memory-end' will allow QEMU to tell BIOS where PCI BARs mapping could safely start in high memory. Allowing BIOS to start mapping 64-bit PCI BARs at address where it wouldn't conflict with other mappings QEMU might place before it. That permits QEMU to reserve extra address space before 64-bit PCI hole for memory hotplug. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-06-18pc: create custom generic PC machine typeIgor Mammedov
it will be used for PC specific options/variables Signed-off-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-05-28machine: Conversion of QEMUMachineInitArgs to MachineStateMarcel Apfelbaum
Total removal of QEMUMachineInitArgs struct. QEMUMachineInitArgs's fields are copied into MachineState. Removed duplicated fields from MachineState. All the other changes are only mechanical refactoring, no semantic changes. Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> (s390) Reviewed-by: Michael S. Tsirkin <mst@redhat.com> (PC) [AF: Renamed ms -> machine, use MACHINE_GET_CLASS()] Signed-off-by: Andreas Färber <afaerber@suse.de>
2014-05-07pc: add compat_props placeholder for 2.0 machine typeGabriel L. Somlo
Add the "boilerplate" necessary for subsequent patches to simply drop in compat_props for pc machines 2.0 and older. This patch contains no functional changes. Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Acked-by: Alexander Graf <agraf@suse.de> Reviewed-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-05-05SMBIOS: Build aggregate smbios tables and entry pointGabriel L. Somlo
Build an aggregate set of smbios tables and an entry point structure. Insert tables and entry point into fw_cfg respectively under "etc/smbios/smbios-tables" and "etc/smbios/smbios-anchor". Machine types <= 2.0 will for now continue using field-by-field overrides to SeaBIOS defaults, but for machine types 2.1 and up we expect the BIOS to look for and use the aggregate tables generated by this patch. Signed-off-by: Gabriel Somlo <somlo@cmu.edu> [ kraxel: fix 32bit build ] Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-05-05SMBIOS: Rename symbols to better reflect future useGabriel L. Somlo
Rename the following symbols: - smbios_set_type1_defaults() to the more general smbios_set_defaults(); - bool smbios_type1_defaults to the more general smbios_defaults; - smbios_get_table() to smbios_get_table_legacy(); This patch contains no functional changes. Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-05-05pc: add 2.1 machine typeMichael S. Tsirkin
At the moment, 2.1 and 2.0 machines are identical. As several people are working on incompatible changes to the PC machine, collaboration will be made easier by merging this place-holder. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-03-13target-i386: Enable x2apic by default on KVMEduardo Habkost
When on KVM mode, enable x2apic by default on all CPU models. Normally we try to keep the CPU model definitions as close as the real CPUs as possible, but x2apic can be emulated by KVM without host CPU support for x2apic, and it improves performance by reducing APIC access overhead. x2apic emulation is available on KVM since 2009 (Linux 2.6.32-rc1), there's no reason for not enabling x2apic by default when running KVM. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
2014-03-11pc: avoid duplicate names for ROM MRsMichael S. Tsirkin
Since commit 04920fc0faa4760f9c4fc0e73b992b768099be70 loader: store FW CFG ROM files in RAM RAM MRs including ROM files in FW CFGs are created and named using the file basename. This becomes problematic if these names are supplied by user, since the basename might not be unique. There are two cases we care about: - option-rom flag. - option ROM for devices. This triggers e.g. when using rombar=0. At the moment we get an assert. E.g qemu -option-rom /usr/share/ipxe/8086100e.rom -option-rom /usr/share/ipxe.efi/8086100e.rom RAMBlock "/rom@genroms/8086100e.rom" already registered, abort! This is a regression from 1.6. For now let's keep it simple and just avoid creating the MRs in case of option ROMs. when using 1.7 machine types, enable option ROMs in RAM to match that version. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-03-09loader: rename in_ram/has_mrMichael S. Tsirkin
we put copy of ROMs in MR for migration. but the name rom_in_ram makes one think we load it in guest RAM. Rename has_mr to make intent clearer. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-01-26q35: document gigabyte_alignMichael S. Tsirkin
Document the logic behind the below/above 4G split. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-01-26q35: gigabyte alignment for ramGerd Hoffmann
Map 2G (q35) of memory below 4G, so the RAM pieces are nicely aligned to gigabyte borders. Keep old memory layout for (a) old machine types and (b) in case all memory fits below 4G and thus we don't have to split RAM into pieces in the first place. The later makes sure this change doesn't take away memory from 32bit guests. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-12-11hpet: enable to entitle more irq pins for hpetLiu Ping Fan
Owning to some different hardware design, piix and q35 need different compat. So making them diverge. On q35, IRQ2/8 can be reserved for hpet timer 0/1. And pin 16~23 can be assigned to hpet as guest chooses. So we introduce intcap property to do that. Consider the compat and piix/q35, we finally have the following value for intcap: For piix, hpet's intcap is hard coded as IRQ2. For pc-q35-1.7 and earlier, we use IRQ2 for compat reason. Otherwise IRQ2, IRQ8, and IRQ16~23 are allowed. Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-12-10smbios: Set system manufacturer, product & version by defaultMarkus Armbruster
Currently, we get SeaBIOS defaults: manufacturer Bochs, product Bochs, no version. Best SeaBIOS can do, but we can provide better defaults: manufacturer QEMU, product & version taken from QEMUMachine desc and name. Take care to do this only for new machine types, of course. Note: Michael Tsirkin doesn't trust us to keep values of QEMUMachine member product stable in the future. Use copies instead, and in a way that makes it obvious that they're guest ABI. Note that we can be trusted to keep values of member name, because that has always been ABI. Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-12-10pc: s/INT64_MAX/UINT64_MAX/Paolo Bonzini
It doesn't make sense for a region to be INT64_MAX in size: memory core uses UINT64_MAX as a special value meaning "all 64 bit" this is what was meant here. While this should never affect the PC system which at the moment always has < 63 bit size, this makes us hit all kind of corner case bugs with sub-pages, so users are probably better off if we just use UINT64_MAX instead. Reported-by: Luiz Capitulino <lcapitulino@redhat.com> Tested-by: Luiz Capitulino <lcapitulino@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-12-06pc: switch 2.0 machine types to large seabios binaryGerd Hoffmann
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2013-12-02add pc-{i440fx,q35}-2.0 machine typesGerd Hoffmann
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2013-11-21pc: get rid of builtin pvpanic for "-M pc-1.5"Paolo Bonzini
This causes two slight backwards-incompatibilities between "-M pc-1.5" and 1.5's "-M pc": (1) a fw_cfg file is removed with this patch. This is only a problem if migration stops the virtual machine exactly during fw_cfg enumeration. (2) after migration, a VM created without an explicit "-device pvpanic" will stop reporting panics to management. The first problem only occurs if migration is done at a very, very early point (and I'm not sure it can happen in practice for reasonable-size VMs, since it will likely take more time to send the RAM to destination, than it will take for BIOS to scan fw_cfg). The second problem only occurs if the guest panics _and_ has a guest driver _and_ management knows to look at the crash event, so it is mostly theoretical at this point in time. Thus keep the code simple, and pretend it was never broken. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-11-14pc: disable pci-infoIgor Mammedov
The BIOS that we ship in 1.7 does not use pci info from host and so far isn't going to use it. Taking in account problems it caused see 9604f70fdf and to avoid future incompatibility issues, it's safest to disable that interface by default for all machine types including 1.7 as it was never exposed/used by guest. And properly remove/cleanup it during 1.8 development cycle. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-10-14i386: ACPI table generation code from seabiosMichael S. Tsirkin
This adds C code for generating ACPI tables at runtime, imported from seabios git tree commit 51684b7ced75fb76776e8ee84833fcfb6ecf12dd Although ACPI tables come from a system BIOS on real hw, it makes sense that the ACPI tables are coupled with the virtual machine, since they have to abstract the x86 machine to the OS's. This is widely desired as a way to avoid the churn and proliferation of QEMU-specific interfaces associated with ACPI tables in bios code. Notes: As BIOS can reprogram devices prior to loading ACPI tables, we pre-format ACPI tables but defer loading hardware configuration there until tables are loaded. The code structure was intentionally kept as close to the seabios original as possible, to simplify comparison and making sure we didn't lose anything in translation. Minor code duplication results, to help ensure there are no functional regressions, I think it's better to merge it like this and do more code changes in follow-up patches. Cross-version compatibility concerns have been addressed: ACPI tables are exposed to guest as FW_CFG entries. When running with -M 1.5 and older, this patch disables ACPI table generation, and doesn't expose ACPI tables to guest. As table content is likely to change over time, the following measures are taken to simplify cross-version migration: - All tables besides the RSDP are packed in a single FW CFG entry. This entry size is currently 23K. We round it up to 64K to avoid too much churn there. - Tables are placed in special ROM blob (not mapped into guest memory) which is automatically migrated together with the guest, same as BIOS code. - Offsets where hardware configuration is loaded in ACPI tables are also migrated, this is in case future ACPI changes make us rearrange the tables in memory. This patch reuses some code from SeaBIOS, which was originally under LGPLv2 and then relicensed to GPLv3 or LGPLv3, in QEMU under GPLv2+. This relicensing has been acked by all contributors that had contributed to the code since the v2->v3 relicense. ACKs approving the v2+ relicensing are listed below. The list might include ACKs from people not holding copyright on any parts of the reused code, but it's better to err on the side of caution and include them. Affected SeaBIOS files (GPLv2+ license headers added) <http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5949>: src/acpi-dsdt-cpu-hotplug.dsl src/acpi-dsdt-dbug.dsl src/acpi-dsdt-hpet.dsl src/acpi-dsdt-isa.dsl src/acpi-dsdt-pci-crs.dsl src/acpi.c src/acpi.h src/ssdt-misc.dsl src/ssdt-pcihp.dsl src/ssdt-proc.dsl tools/acpi_extract.py tools/acpi_extract_preprocess.py Each one of the listed people agreed to the following: > If you allow the use of your contribution in QEMU under the > terms of GPLv2 or later as proposed by this patch, > please respond to this mail including the line: > > Acked-by: Name <email address> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jan Kiszka <jan.kiszka@siemens.com> Acked-by: Jason Baron <jbaron@akamai.com> Acked-by: David Woodhouse <David.Woodhouse@intel.com> Acked-by: Gleb Natapov <gleb@redhat.com> Acked-by: Marcelo Tosatti <mtosatti@redhat.com> Acked-by: Dave Frodin <dave.frodin@se-eng.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Kevin O'Connor <kevin@koconnor.net> Acked-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Acked-by: Isaku Yamahata <yamahata@valinux.co.jp> Acked-by: Magnus Christensson <magnus.christensson@intel.com> Acked-by: Hu Tao <hutao@cn.fujitsu.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Tested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-09-11Merge remote-tracking branch 'sstabellini/xen-2013-09-09' into stagingAnthony Liguori
# By Anthony PERARD # Via Stefano Stabellini * sstabellini/xen-2013-09-09: pc_q35: Initialize Xen. pc: Initializing ram_memory under Xen. Message-id: alpine.DEB.2.02.1309091718030.6397@kaball.uk.xensource.com Signed-off-by: Anthony Liguori <anthony@codemonkey.ws>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-06 04:49:48 +0000