2012-11-14 21:54:06 +01:00
|
|
|
/*
|
|
|
|
* Q35 chipset based pc system emulator
|
|
|
|
*
|
|
|
|
* Copyright (c) 2003-2004 Fabrice Bellard
|
|
|
|
* Copyright (c) 2009, 2010
|
|
|
|
* Isaku Yamahata <yamahata at valinux co jp>
|
|
|
|
* VA Linux Systems Japan K.K.
|
|
|
|
* Copyright (C) 2012 Jason Baron <jbaron@redhat.com>
|
|
|
|
*
|
|
|
|
* This is based on pc.c, but heavily modified.
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
* THE SOFTWARE.
|
|
|
|
*/
|
2013-02-04 15:40:22 +01:00
|
|
|
#include "hw/hw.h"
|
2013-08-19 16:26:55 +02:00
|
|
|
#include "hw/loader.h"
|
2012-12-17 18:20:04 +01:00
|
|
|
#include "sysemu/arch_init.h"
|
2013-02-05 17:06:20 +01:00
|
|
|
#include "hw/i2c/smbus.h"
|
2013-02-04 15:40:22 +01:00
|
|
|
#include "hw/boards.h"
|
2013-02-05 17:06:20 +01:00
|
|
|
#include "hw/timer/mc146818rtc.h"
|
|
|
|
#include "hw/xen/xen.h"
|
2012-12-17 18:20:04 +01:00
|
|
|
#include "sysemu/kvm.h"
|
2013-02-04 15:40:22 +01:00
|
|
|
#include "hw/kvm/clock.h"
|
2013-02-05 17:06:20 +01:00
|
|
|
#include "hw/pci-host/q35.h"
|
2012-12-17 18:19:49 +01:00
|
|
|
#include "exec/address-spaces.h"
|
2013-02-05 17:06:20 +01:00
|
|
|
#include "hw/i386/ich9.h"
|
2013-10-30 13:56:40 +01:00
|
|
|
#include "hw/i386/smbios.h"
|
2012-11-14 21:54:06 +01:00
|
|
|
#include "hw/ide/pci.h"
|
|
|
|
#include "hw/ide/ahci.h"
|
|
|
|
#include "hw/usb.h"
|
2013-04-29 17:02:50 +02:00
|
|
|
#include "hw/cpu/icc_bus.h"
|
2014-06-20 03:40:25 +02:00
|
|
|
#include "qemu/error-report.h"
|
2012-11-14 21:54:06 +01:00
|
|
|
|
|
|
|
/* ICH9 AHCI has 6 ports */
|
|
|
|
#define MAX_SATA_PORTS 6
|
|
|
|
|
i386: ACPI table generation code from seabios
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-07-24 17:56:14 +02:00
|
|
|
static bool has_acpi_build = true;
|
2015-02-17 10:04:40 +01:00
|
|
|
static bool rsdp_in_ram = true;
|
2014-04-23 15:42:38 +02:00
|
|
|
static bool smbios_defaults = true;
|
2014-04-23 15:42:42 +02:00
|
|
|
static bool smbios_legacy_mode;
|
smbios: Encode UUID according to SMBIOS specification
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-10-29 14:26:08 +01:00
|
|
|
static bool smbios_uuid_encoded = true;
|
2013-12-16 12:55:06 +01:00
|
|
|
/* Make sure that guest addresses aligned at 1Gbyte boundaries get mapped to
|
|
|
|
* host addresses aligned at 1Gbyte boundaries. This way we can use 1GByte
|
|
|
|
* pages in the host.
|
|
|
|
*/
|
2013-12-16 10:11:28 +01:00
|
|
|
static bool gigabyte_align = true;
|
2014-06-02 15:25:10 +02:00
|
|
|
static bool has_reserved_memory = true;
|
2013-04-26 05:24:46 +02:00
|
|
|
|
2012-11-14 21:54:06 +01:00
|
|
|
/* PC hardware initialisation */
|
2014-05-07 16:42:57 +02:00
|
|
|
static void pc_q35_init(MachineState *machine)
|
2012-11-14 21:54:06 +01:00
|
|
|
{
|
2014-06-02 15:25:24 +02:00
|
|
|
PCMachineState *pc_machine = PC_MACHINE(machine);
|
2012-11-14 21:54:06 +01:00
|
|
|
ram_addr_t below_4g_mem_size, above_4g_mem_size;
|
|
|
|
Q35PCIHost *q35_host;
|
2013-07-01 12:18:22 +02:00
|
|
|
PCIHostState *phb;
|
2012-11-14 21:54:06 +01:00
|
|
|
PCIBus *host_bus;
|
|
|
|
PCIDevice *lpc;
|
|
|
|
BusState *idebus[MAX_SATA_PORTS];
|
|
|
|
ISADevice *rtc_state;
|
|
|
|
ISADevice *floppy;
|
|
|
|
MemoryRegion *pci_memory;
|
|
|
|
MemoryRegion *rom_memory;
|
|
|
|
MemoryRegion *ram_memory;
|
|
|
|
GSIState *gsi_state;
|
|
|
|
ISABus *isa_bus;
|
|
|
|
int pci_enabled = 1;
|
|
|
|
qemu_irq *cpu_irq;
|
|
|
|
qemu_irq *gsi;
|
|
|
|
qemu_irq *i8259;
|
|
|
|
int i;
|
|
|
|
ICH9LPCState *ich9_lpc;
|
|
|
|
PCIDevice *ahci;
|
2013-04-29 17:02:50 +02:00
|
|
|
DeviceState *icc_bridge;
|
2013-05-30 11:57:26 +02:00
|
|
|
PcGuestInfo *guest_info;
|
2014-06-20 03:40:25 +02:00
|
|
|
ram_addr_t lowmem;
|
2014-10-01 20:19:29 +02:00
|
|
|
DriveInfo *hd[MAX_SATA_PORTS];
|
2013-04-29 17:02:50 +02:00
|
|
|
|
2013-12-16 12:55:06 +01:00
|
|
|
/* Check whether RAM fits below 4G (leaving 1/2 GByte for IO memory
|
|
|
|
* and 256 Mbytes for PCI Express Enhanced Configuration Access Mapping
|
|
|
|
* also known as MMCFG).
|
|
|
|
* If it doesn't, we need to split it in chunks below and above 4G.
|
|
|
|
* In any case, try to make sure that guest addresses aligned at
|
|
|
|
* 1G boundaries get mapped to host addresses aligned at 1G boundaries.
|
|
|
|
* For old machine types, use whatever split we used historically to avoid
|
|
|
|
* breaking migration.
|
|
|
|
*/
|
2014-05-07 16:42:57 +02:00
|
|
|
if (machine->ram_size >= 0xb0000000) {
|
2014-06-20 03:40:25 +02:00
|
|
|
lowmem = gigabyte_align ? 0x80000000 : 0xb0000000;
|
|
|
|
} else {
|
|
|
|
lowmem = 0xb0000000;
|
|
|
|
}
|
|
|
|
|
2014-07-07 21:00:41 +02:00
|
|
|
/* Handle the machine opt max-ram-below-4g. It is basically doing
|
2014-06-20 03:40:25 +02:00
|
|
|
* min(qemu limit, user limit).
|
|
|
|
*/
|
|
|
|
if (lowmem > pc_machine->max_ram_below_4g) {
|
|
|
|
lowmem = pc_machine->max_ram_below_4g;
|
|
|
|
if (machine->ram_size - lowmem > lowmem &&
|
|
|
|
lowmem & ((1ULL << 30) - 1)) {
|
|
|
|
error_report("Warning: Large machine and max_ram_below_4g(%"PRIu64
|
|
|
|
") not a multiple of 1G; possible bad performance.",
|
|
|
|
pc_machine->max_ram_below_4g);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (machine->ram_size >= lowmem) {
|
2014-05-07 16:42:57 +02:00
|
|
|
above_4g_mem_size = machine->ram_size - lowmem;
|
2013-12-16 10:11:28 +01:00
|
|
|
below_4g_mem_size = lowmem;
|
2012-11-14 21:54:06 +01:00
|
|
|
} else {
|
|
|
|
above_4g_mem_size = 0;
|
2014-05-07 16:42:57 +02:00
|
|
|
below_4g_mem_size = machine->ram_size;
|
2012-11-14 21:54:06 +01:00
|
|
|
}
|
|
|
|
|
2014-06-20 03:40:24 +02:00
|
|
|
if (xen_enabled() && xen_hvm_init(&below_4g_mem_size, &above_4g_mem_size,
|
|
|
|
&ram_memory) != 0) {
|
|
|
|
fprintf(stderr, "xen hardware virtual machine initialisation failed\n");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
icc_bridge = qdev_create(NULL, TYPE_ICC_BRIDGE);
|
|
|
|
object_property_add_child(qdev_get_machine(), "icc-bridge",
|
|
|
|
OBJECT(icc_bridge), NULL);
|
|
|
|
|
|
|
|
pc_cpus_init(machine->cpu_model, icc_bridge);
|
|
|
|
pc_acpi_init("q35-acpi-dsdt.aml");
|
|
|
|
|
|
|
|
kvmclock_create();
|
|
|
|
|
2012-11-14 21:54:06 +01:00
|
|
|
/* pci enabled */
|
|
|
|
if (pci_enabled) {
|
|
|
|
pci_memory = g_new(MemoryRegion, 1);
|
2013-11-06 19:18:08 +01:00
|
|
|
memory_region_init(pci_memory, NULL, "pci", UINT64_MAX);
|
2012-11-14 21:54:06 +01:00
|
|
|
rom_memory = pci_memory;
|
|
|
|
} else {
|
|
|
|
pci_memory = NULL;
|
|
|
|
rom_memory = get_system_memory();
|
|
|
|
}
|
|
|
|
|
2013-05-30 11:57:26 +02:00
|
|
|
guest_info = pc_guest_info_init(below_4g_mem_size, above_4g_mem_size);
|
2013-08-09 19:35:02 +02:00
|
|
|
guest_info->isapc_ram_fw = false;
|
i386: ACPI table generation code from seabios
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-07-24 17:56:14 +02:00
|
|
|
guest_info->has_acpi_build = has_acpi_build;
|
2014-06-02 15:25:10 +02:00
|
|
|
guest_info->has_reserved_memory = has_reserved_memory;
|
2015-02-17 10:04:40 +01:00
|
|
|
guest_info->rsdp_in_ram = rsdp_in_ram;
|
2013-05-30 11:57:26 +02:00
|
|
|
|
pc: hack for migration compatibility from QEMU 2.0
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-28 17:34:15 +02:00
|
|
|
/* Migration was not supported in 2.0 for Q35, so do not bother
|
|
|
|
* with this hack (see hw/i386/acpi-build.c).
|
|
|
|
*/
|
|
|
|
guest_info->legacy_acpi_table_size = 0;
|
|
|
|
|
2014-04-23 15:42:38 +02:00
|
|
|
if (smbios_defaults) {
|
2014-05-07 16:42:57 +02:00
|
|
|
MachineClass *mc = MACHINE_GET_CLASS(machine);
|
2013-10-30 13:56:40 +01:00
|
|
|
/* These values are guest ABI, do not change */
|
2014-04-23 15:42:38 +02:00
|
|
|
smbios_set_defaults("QEMU", "Standard PC (Q35 + ICH9, 2009)",
|
smbios: Encode UUID according to SMBIOS specification
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-10-29 14:26:08 +01:00
|
|
|
mc->name, smbios_legacy_mode, smbios_uuid_encoded);
|
2013-10-30 13:56:40 +01:00
|
|
|
}
|
|
|
|
|
2012-11-14 21:54:06 +01:00
|
|
|
/* allocate ram and load rom/bios */
|
|
|
|
if (!xen_enabled()) {
|
2014-06-10 13:15:17 +02:00
|
|
|
pc_memory_init(machine, get_system_memory(),
|
2013-08-21 20:14:41 +02:00
|
|
|
below_4g_mem_size, above_4g_mem_size,
|
2013-05-30 11:57:26 +02:00
|
|
|
rom_memory, &ram_memory, guest_info);
|
2012-11-14 21:54:06 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* irq lines */
|
|
|
|
gsi_state = g_malloc0(sizeof(*gsi_state));
|
|
|
|
if (kvm_irqchip_in_kernel()) {
|
|
|
|
kvm_pc_setup_irq_routing(pci_enabled);
|
|
|
|
gsi = qemu_allocate_irqs(kvm_pc_gsi_handler, gsi_state,
|
|
|
|
GSI_NUM_PINS);
|
|
|
|
} else {
|
|
|
|
gsi = qemu_allocate_irqs(gsi_handler, gsi_state, GSI_NUM_PINS);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* create pci host bus */
|
|
|
|
q35_host = Q35_HOST_DEVICE(qdev_create(NULL, TYPE_Q35_HOST_DEVICE));
|
|
|
|
|
2013-07-29 16:47:54 +02:00
|
|
|
object_property_add_child(qdev_get_machine(), "q35", OBJECT(q35_host), NULL);
|
2012-11-14 21:54:06 +01:00
|
|
|
q35_host->mch.ram_memory = ram_memory;
|
|
|
|
q35_host->mch.pci_address_space = pci_memory;
|
|
|
|
q35_host->mch.system_memory = get_system_memory();
|
2013-05-09 09:53:50 +02:00
|
|
|
q35_host->mch.address_space_io = get_system_io();
|
2012-11-14 21:54:06 +01:00
|
|
|
q35_host->mch.below_4g_mem_size = below_4g_mem_size;
|
|
|
|
q35_host->mch.above_4g_mem_size = above_4g_mem_size;
|
2013-05-30 11:57:26 +02:00
|
|
|
q35_host->mch.guest_info = guest_info;
|
2012-11-14 21:54:06 +01:00
|
|
|
/* pci */
|
|
|
|
qdev_init_nofail(DEVICE(q35_host));
|
2013-07-01 12:18:22 +02:00
|
|
|
phb = PCI_HOST_BRIDGE(q35_host);
|
|
|
|
host_bus = phb->bus;
|
2012-11-14 21:54:06 +01:00
|
|
|
/* create ISA bus */
|
|
|
|
lpc = pci_create_simple_multifunction(host_bus, PCI_DEVFN(ICH9_LPC_DEV,
|
|
|
|
ICH9_LPC_FUNC), true,
|
|
|
|
TYPE_ICH9_LPC_DEVICE);
|
2014-06-02 15:25:24 +02:00
|
|
|
|
|
|
|
object_property_add_link(OBJECT(machine), PC_MACHINE_ACPI_DEVICE_PROP,
|
|
|
|
TYPE_HOTPLUG_HANDLER,
|
|
|
|
(Object **)&pc_machine->acpi_dev,
|
|
|
|
object_property_allow_set_link,
|
|
|
|
OBJ_PROP_LINK_UNREF_ON_RELEASE, &error_abort);
|
|
|
|
object_property_set_link(OBJECT(machine), OBJECT(lpc),
|
|
|
|
PC_MACHINE_ACPI_DEVICE_PROP, &error_abort);
|
|
|
|
|
2012-11-14 21:54:06 +01:00
|
|
|
ich9_lpc = ICH9_LPC_DEVICE(lpc);
|
|
|
|
ich9_lpc->pic = gsi;
|
|
|
|
ich9_lpc->ioapic = gsi_state->ioapic_irq;
|
|
|
|
pci_bus_irqs(host_bus, ich9_lpc_set_irq, ich9_lpc_map_irq, ich9_lpc,
|
|
|
|
ICH9_LPC_NB_PIRQS);
|
2013-01-23 03:11:37 +01:00
|
|
|
pci_bus_set_route_irq_fn(host_bus, ich9_route_intx_pin_to_irq);
|
2012-11-14 21:54:06 +01:00
|
|
|
isa_bus = ich9_lpc->isa_bus;
|
|
|
|
|
|
|
|
/*end early*/
|
|
|
|
isa_bus_irqs(isa_bus, gsi);
|
|
|
|
|
|
|
|
if (kvm_irqchip_in_kernel()) {
|
|
|
|
i8259 = kvm_i8259_init(isa_bus);
|
|
|
|
} else if (xen_enabled()) {
|
|
|
|
i8259 = xen_interrupt_controller_init();
|
|
|
|
} else {
|
|
|
|
cpu_irq = pc_allocate_cpu_irq();
|
|
|
|
i8259 = i8259_init(isa_bus, cpu_irq[0]);
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < ISA_NUM_IRQS; i++) {
|
|
|
|
gsi_state->i8259_irq[i] = i8259[i];
|
|
|
|
}
|
|
|
|
if (pci_enabled) {
|
2014-08-04 23:11:19 +02:00
|
|
|
ioapic_init_gsi(gsi_state, "q35");
|
2012-11-14 21:54:06 +01:00
|
|
|
}
|
2013-04-29 17:02:50 +02:00
|
|
|
qdev_init_nofail(icc_bridge);
|
2012-11-14 21:54:06 +01:00
|
|
|
|
|
|
|
pc_register_ferr_irq(gsi[13]);
|
|
|
|
|
2014-11-21 17:18:52 +01:00
|
|
|
assert(pc_machine->vmport != ON_OFF_AUTO_MAX);
|
|
|
|
if (pc_machine->vmport == ON_OFF_AUTO_AUTO) {
|
|
|
|
pc_machine->vmport = xen_enabled() ? ON_OFF_AUTO_OFF : ON_OFF_AUTO_ON;
|
|
|
|
}
|
|
|
|
|
2012-11-14 21:54:06 +01:00
|
|
|
/* init basic PC hardware */
|
2014-10-03 23:33:37 +02:00
|
|
|
pc_basic_device_init(isa_bus, gsi, &rtc_state, &floppy,
|
2014-11-21 17:18:52 +01:00
|
|
|
(pc_machine->vmport != ON_OFF_AUTO_ON), 0xff0104);
|
2012-11-14 21:54:06 +01:00
|
|
|
|
|
|
|
/* connect pm stuff to lpc */
|
2013-04-24 12:37:22 +02:00
|
|
|
ich9_lpc_pm_init(lpc);
|
2012-11-14 21:54:06 +01:00
|
|
|
|
|
|
|
/* ahci and SATA device, for q35 1 ahci controller is built-in */
|
|
|
|
ahci = pci_create_simple_multifunction(host_bus,
|
|
|
|
PCI_DEVFN(ICH9_SATA1_DEV,
|
|
|
|
ICH9_SATA1_FUNC),
|
|
|
|
true, "ich9-ahci");
|
|
|
|
idebus[0] = qdev_get_child_bus(&ahci->qdev, "ide.0");
|
|
|
|
idebus[1] = qdev_get_child_bus(&ahci->qdev, "ide.1");
|
2014-10-17 20:04:35 +02:00
|
|
|
g_assert(MAX_SATA_PORTS == ICH_AHCI(ahci)->ahci.ports);
|
2014-10-01 20:19:29 +02:00
|
|
|
ide_drive_get(hd, ICH_AHCI(ahci)->ahci.ports);
|
|
|
|
ahci_ide_create_devs(ahci, hd);
|
2012-11-14 21:54:06 +01:00
|
|
|
|
2015-01-06 14:29:14 +01:00
|
|
|
if (usb_enabled()) {
|
2012-11-14 21:54:06 +01:00
|
|
|
/* Should we create 6 UHCI according to ich9 spec? */
|
|
|
|
ehci_create_ich9_with_companions(host_bus, 0x1d);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* TODO: Populate SPD eeprom data. */
|
|
|
|
smbus_eeprom_init(ich9_smb_init(host_bus,
|
|
|
|
PCI_DEVFN(ICH9_SMB_DEV, ICH9_SMB_FUNC),
|
|
|
|
0xb100),
|
|
|
|
8, NULL, 0);
|
|
|
|
|
2014-05-07 16:42:57 +02:00
|
|
|
pc_cmos_init(below_4g_mem_size, above_4g_mem_size, machine->boot_order,
|
2014-10-22 05:24:29 +02:00
|
|
|
machine, floppy, idebus[0], idebus[1], rtc_state);
|
2012-11-14 21:54:06 +01:00
|
|
|
|
|
|
|
/* the rest devices to which pci devfn is automatically assigned */
|
|
|
|
pc_vga_init(isa_bus, host_bus);
|
|
|
|
pc_nic_init(isa_bus, host_bus);
|
|
|
|
if (pci_enabled) {
|
|
|
|
pc_pci_device_init(host_bus);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-04-23 08:21:35 +02:00
|
|
|
static void pc_compat_2_3(MachineState *machine)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2014-12-05 10:51:42 +01:00
|
|
|
static void pc_compat_2_2(MachineState *machine)
|
|
|
|
{
|
2015-04-23 08:21:35 +02:00
|
|
|
pc_compat_2_3(machine);
|
2015-02-17 10:04:40 +01:00
|
|
|
rsdp_in_ram = false;
|
2014-12-10 17:12:41 +01:00
|
|
|
x86_cpu_compat_set_features("kvm64", FEAT_1_EDX, 0, CPUID_VME);
|
|
|
|
x86_cpu_compat_set_features("kvm32", FEAT_1_EDX, 0, CPUID_VME);
|
|
|
|
x86_cpu_compat_set_features("Conroe", FEAT_1_EDX, 0, CPUID_VME);
|
|
|
|
x86_cpu_compat_set_features("Penryn", FEAT_1_EDX, 0, CPUID_VME);
|
|
|
|
x86_cpu_compat_set_features("Nehalem", FEAT_1_EDX, 0, CPUID_VME);
|
|
|
|
x86_cpu_compat_set_features("Westmere", FEAT_1_EDX, 0, CPUID_VME);
|
|
|
|
x86_cpu_compat_set_features("SandyBridge", FEAT_1_EDX, 0, CPUID_VME);
|
|
|
|
x86_cpu_compat_set_features("Haswell", FEAT_1_EDX, 0, CPUID_VME);
|
|
|
|
x86_cpu_compat_set_features("Broadwell", FEAT_1_EDX, 0, CPUID_VME);
|
|
|
|
x86_cpu_compat_set_features("Opteron_G1", FEAT_1_EDX, 0, CPUID_VME);
|
|
|
|
x86_cpu_compat_set_features("Opteron_G2", FEAT_1_EDX, 0, CPUID_VME);
|
|
|
|
x86_cpu_compat_set_features("Opteron_G3", FEAT_1_EDX, 0, CPUID_VME);
|
|
|
|
x86_cpu_compat_set_features("Opteron_G4", FEAT_1_EDX, 0, CPUID_VME);
|
|
|
|
x86_cpu_compat_set_features("Opteron_G5", FEAT_1_EDX, 0, CPUID_VME);
|
2014-12-05 10:52:46 +01:00
|
|
|
x86_cpu_compat_set_features("Haswell", FEAT_1_ECX, 0, CPUID_EXT_F16C);
|
|
|
|
x86_cpu_compat_set_features("Haswell", FEAT_1_ECX, 0, CPUID_EXT_RDRAND);
|
|
|
|
x86_cpu_compat_set_features("Broadwell", FEAT_1_ECX, 0, CPUID_EXT_F16C);
|
|
|
|
x86_cpu_compat_set_features("Broadwell", FEAT_1_ECX, 0, CPUID_EXT_RDRAND);
|
2015-02-23 13:56:43 +01:00
|
|
|
machine->suppress_vmdesc = true;
|
2014-12-05 10:51:42 +01:00
|
|
|
}
|
|
|
|
|
2014-10-29 14:26:07 +01:00
|
|
|
static void pc_compat_2_1(MachineState *machine)
|
|
|
|
{
|
2014-10-31 17:38:39 +01:00
|
|
|
PCMachineState *pcms = PC_MACHINE(machine);
|
|
|
|
|
2014-12-05 10:51:42 +01:00
|
|
|
pc_compat_2_2(machine);
|
2014-10-31 17:38:39 +01:00
|
|
|
pcms->enforce_aligned_dimm = false;
|
smbios: Encode UUID according to SMBIOS specification
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-10-29 14:26:08 +01:00
|
|
|
smbios_uuid_encoded = false;
|
2014-10-03 21:39:50 +02:00
|
|
|
x86_cpu_compat_set_features("coreduo", FEAT_1_ECX, CPUID_EXT_VMX, 0);
|
|
|
|
x86_cpu_compat_set_features("core2duo", FEAT_1_ECX, CPUID_EXT_VMX, 0);
|
2014-10-03 21:39:51 +02:00
|
|
|
x86_cpu_compat_kvm_no_autodisable(FEAT_8000_0001_ECX, CPUID_EXT3_SVM);
|
2014-10-29 14:26:07 +01:00
|
|
|
}
|
|
|
|
|
2014-05-07 16:42:57 +02:00
|
|
|
static void pc_compat_2_0(MachineState *machine)
|
2014-04-24 12:14:53 +02:00
|
|
|
{
|
2014-10-29 14:26:07 +01:00
|
|
|
pc_compat_2_1(machine);
|
2014-04-23 15:42:42 +02:00
|
|
|
smbios_legacy_mode = true;
|
2014-06-02 15:25:10 +02:00
|
|
|
has_reserved_memory = false;
|
2014-08-20 21:58:12 +02:00
|
|
|
pc_set_legacy_acpi_data_size();
|
2014-04-24 12:14:53 +02:00
|
|
|
}
|
|
|
|
|
2014-05-07 16:42:57 +02:00
|
|
|
static void pc_compat_1_7(MachineState *machine)
|
2013-10-30 13:56:40 +01:00
|
|
|
{
|
2014-05-07 16:42:57 +02:00
|
|
|
pc_compat_2_0(machine);
|
2014-04-23 15:42:38 +02:00
|
|
|
smbios_defaults = false;
|
2013-12-16 10:11:28 +01:00
|
|
|
gigabyte_align = false;
|
2014-03-06 13:57:09 +01:00
|
|
|
option_rom_has_mr = true;
|
2014-10-03 21:39:47 +02:00
|
|
|
x86_cpu_compat_kvm_no_autoenable(FEAT_1_ECX, CPUID_EXT_X2APIC);
|
2013-10-30 13:56:40 +01:00
|
|
|
}
|
|
|
|
|
2014-05-07 16:42:57 +02:00
|
|
|
static void pc_compat_1_6(MachineState *machine)
|
2013-05-13 19:00:23 +02:00
|
|
|
{
|
2014-05-07 16:42:57 +02:00
|
|
|
pc_compat_1_7(machine);
|
2014-03-09 17:42:06 +01:00
|
|
|
rom_file_has_mr = false;
|
i386: ACPI table generation code from seabios
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-07-24 17:56:14 +02:00
|
|
|
has_acpi_build = false;
|
2013-05-13 19:00:23 +02:00
|
|
|
}
|
|
|
|
|
2014-05-07 16:42:57 +02:00
|
|
|
static void pc_compat_1_5(MachineState *machine)
|
2013-08-01 14:39:11 +02:00
|
|
|
{
|
2014-05-07 16:42:57 +02:00
|
|
|
pc_compat_1_6(machine);
|
2013-08-01 14:39:11 +02:00
|
|
|
}
|
|
|
|
|
2014-05-07 16:42:57 +02:00
|
|
|
static void pc_compat_1_4(MachineState *machine)
|
pc: Kill the "use flash device for BIOS unless KVM" misfeature
Use of a flash memory device for the BIOS was added in series "[PATCH
v10 0/8] PC system flash support", commit 4732dca..1b89faf, v1.1.
Flash vs. ROM is a guest-visible difference. Thus, flash use had to
be suppressed for machine types pc-1.0 and older. This was
accomplished by adding a dummy device "pc-sysfw" with property
"rom_only":
* Non-zero rom_only means "use ROM". Default for pc-1.0 and older.
* Zero rom_only means "maybe use flash". Default for newer machines.
Not only is the dummy device ugly, it was also retroactively added to
the older machine types! Fortunately, it's not guest-visible (thus no
immediate guest ABI breakage), and has no vmstate (thus no immediate
migration breakage). Breakage occurs only if the user unwisely
enables flash by setting rom_only to zero. Patch review FAIL #1.
Why "maybe use flash"? Flash didn't (and still doesn't) work with
KVM. Therefore, rom_only=0 really means "use flash, except when KVM
is enabled, use ROM". This is a Bad Idea, because it makes enabling/
disabling KVM guest-visible. Patch review FAIL #2.
Aside: it also precludes migrating between KVM on and off, but that's
not possible for other reasons anyway.
Fix as follows:
1. Change the meaning of rom_only=0 to mean "use flash, no ifs, buts,
or maybes" for pc-i440fx-1.5 and pc-q35-1.5. Don't change anything
for older machines (to remain bug-compatible).
2. Change the default value from 0 to 1 for these machines.
Necessary, because 0 doesn't work with KVM. Once it does, we can flip
the default back to 0.
3. Don't revert the retroactive addition of device "pc-sysfw" to older
machine types. Seems not worth the trouble.
4. Add a TODO comment asking for device "pc-sysfw" to be dropped once
flash works with KVM.
Net effect is that you get a BIOS ROM again even when KVM is disabled,
just like for machines predating the introduction of flash.
To get flash instead, use "--global pc-sysfw.rom_only=0".
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-id: 1365780303-26398-4-git-send-email-armbru@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-04-12 17:25:03 +02:00
|
|
|
{
|
2014-05-07 16:42:57 +02:00
|
|
|
pc_compat_1_5(machine);
|
2013-04-25 20:43:04 +02:00
|
|
|
x86_cpu_compat_set_features("n270", FEAT_1_ECX, 0, CPUID_EXT_MOVBE);
|
2013-08-09 16:11:36 +02:00
|
|
|
x86_cpu_compat_set_features("Westmere", FEAT_1_ECX, 0, CPUID_EXT_PCLMULQDQ);
|
2013-08-21 20:14:43 +02:00
|
|
|
}
|
|
|
|
|
2015-04-23 08:21:35 +02:00
|
|
|
static void pc_q35_init_2_3(MachineState *machine)
|
|
|
|
{
|
|
|
|
pc_compat_2_3(machine);
|
|
|
|
pc_q35_init(machine);
|
|
|
|
}
|
|
|
|
|
2014-12-05 10:51:42 +01:00
|
|
|
static void pc_q35_init_2_2(MachineState *machine)
|
|
|
|
{
|
|
|
|
pc_compat_2_2(machine);
|
|
|
|
pc_q35_init(machine);
|
|
|
|
}
|
|
|
|
|
2014-10-29 14:26:07 +01:00
|
|
|
static void pc_q35_init_2_1(MachineState *machine)
|
|
|
|
{
|
|
|
|
pc_compat_2_1(machine);
|
|
|
|
pc_q35_init(machine);
|
|
|
|
}
|
|
|
|
|
2014-05-07 16:42:57 +02:00
|
|
|
static void pc_q35_init_2_0(MachineState *machine)
|
2014-04-24 12:14:53 +02:00
|
|
|
{
|
2014-05-07 16:42:57 +02:00
|
|
|
pc_compat_2_0(machine);
|
|
|
|
pc_q35_init(machine);
|
2014-04-24 12:14:53 +02:00
|
|
|
}
|
|
|
|
|
2014-05-07 16:42:57 +02:00
|
|
|
static void pc_q35_init_1_7(MachineState *machine)
|
2013-10-30 13:56:40 +01:00
|
|
|
{
|
2014-05-07 16:42:57 +02:00
|
|
|
pc_compat_1_7(machine);
|
|
|
|
pc_q35_init(machine);
|
2013-10-30 13:56:40 +01:00
|
|
|
}
|
|
|
|
|
2014-05-07 16:42:57 +02:00
|
|
|
static void pc_q35_init_1_6(MachineState *machine)
|
2013-08-21 20:14:43 +02:00
|
|
|
{
|
2014-05-07 16:42:57 +02:00
|
|
|
pc_compat_1_6(machine);
|
|
|
|
pc_q35_init(machine);
|
2013-08-21 20:14:43 +02:00
|
|
|
}
|
|
|
|
|
2014-05-07 16:42:57 +02:00
|
|
|
static void pc_q35_init_1_5(MachineState *machine)
|
2013-08-21 20:14:43 +02:00
|
|
|
{
|
2014-05-07 16:42:57 +02:00
|
|
|
pc_compat_1_5(machine);
|
|
|
|
pc_q35_init(machine);
|
2013-08-21 20:14:43 +02:00
|
|
|
}
|
|
|
|
|
2014-05-07 16:42:57 +02:00
|
|
|
static void pc_q35_init_1_4(MachineState *machine)
|
2013-08-21 20:14:43 +02:00
|
|
|
{
|
2014-05-07 16:42:57 +02:00
|
|
|
pc_compat_1_4(machine);
|
|
|
|
pc_q35_init(machine);
|
pc: Kill the "use flash device for BIOS unless KVM" misfeature
Use of a flash memory device for the BIOS was added in series "[PATCH
v10 0/8] PC system flash support", commit 4732dca..1b89faf, v1.1.
Flash vs. ROM is a guest-visible difference. Thus, flash use had to
be suppressed for machine types pc-1.0 and older. This was
accomplished by adding a dummy device "pc-sysfw" with property
"rom_only":
* Non-zero rom_only means "use ROM". Default for pc-1.0 and older.
* Zero rom_only means "maybe use flash". Default for newer machines.
Not only is the dummy device ugly, it was also retroactively added to
the older machine types! Fortunately, it's not guest-visible (thus no
immediate guest ABI breakage), and has no vmstate (thus no immediate
migration breakage). Breakage occurs only if the user unwisely
enables flash by setting rom_only to zero. Patch review FAIL #1.
Why "maybe use flash"? Flash didn't (and still doesn't) work with
KVM. Therefore, rom_only=0 really means "use flash, except when KVM
is enabled, use ROM". This is a Bad Idea, because it makes enabling/
disabling KVM guest-visible. Patch review FAIL #2.
Aside: it also precludes migrating between KVM on and off, but that's
not possible for other reasons anyway.
Fix as follows:
1. Change the meaning of rom_only=0 to mean "use flash, no ifs, buts,
or maybes" for pc-i440fx-1.5 and pc-q35-1.5. Don't change anything
for older machines (to remain bug-compatible).
2. Change the default value from 0 to 1 for these machines.
Necessary, because 0 doesn't work with KVM. Once it does, we can flip
the default back to 0.
3. Don't revert the retroactive addition of device "pc-sysfw" to older
machine types. Seems not worth the trouble.
4. Add a TODO comment asking for device "pc-sysfw" to be dropped once
flash works with KVM.
Net effect is that you get a BIOS ROM again even when KVM is disabled,
just like for machines predating the introduction of flash.
To get flash instead, use "--global pc-sysfw.rom_only=0".
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-id: 1365780303-26398-4-git-send-email-armbru@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-04-12 17:25:03 +02:00
|
|
|
}
|
|
|
|
|
2013-08-27 08:48:06 +02:00
|
|
|
#define PC_Q35_MACHINE_OPTIONS \
|
|
|
|
PC_DEFAULT_MACHINE_OPTIONS, \
|
i386/pc: add piix and q35 machtypes to sorting families for -M \?
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-09-22 22:38:36 +02:00
|
|
|
.family = "pc_q35", \
|
2013-08-27 08:48:06 +02:00
|
|
|
.desc = "Standard PC (Q35 + ICH9, 2009)", \
|
pc/vl: Add units-per-default-bus property
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-10-01 20:19:26 +02:00
|
|
|
.hot_add_cpu = pc_hot_add_cpu, \
|
|
|
|
.units_per_default_bus = 1
|
2013-08-27 08:48:06 +02:00
|
|
|
|
2015-04-23 08:21:35 +02:00
|
|
|
#define PC_Q35_2_4_MACHINE_OPTIONS \
|
2013-12-02 12:52:04 +01:00
|
|
|
PC_Q35_MACHINE_OPTIONS, \
|
2014-10-28 10:09:12 +01:00
|
|
|
.default_machine_opts = "firmware=bios-256k.bin", \
|
|
|
|
.default_display = "std"
|
2013-12-02 12:47:29 +01:00
|
|
|
|
2015-04-23 08:21:35 +02:00
|
|
|
static QEMUMachine pc_q35_machine_v2_4 = {
|
|
|
|
PC_Q35_2_4_MACHINE_OPTIONS,
|
|
|
|
.name = "pc-q35-2.4",
|
|
|
|
.alias = "q35",
|
|
|
|
.init = pc_q35_init,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define PC_Q35_2_3_MACHINE_OPTIONS PC_Q35_2_4_MACHINE_OPTIONS
|
|
|
|
|
2014-12-05 10:51:42 +01:00
|
|
|
static QEMUMachine pc_q35_machine_v2_3 = {
|
|
|
|
PC_Q35_2_3_MACHINE_OPTIONS,
|
|
|
|
.name = "pc-q35-2.3",
|
2015-04-23 08:21:35 +02:00
|
|
|
.init = pc_q35_init_2_3,
|
2014-12-05 10:51:42 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
#define PC_Q35_2_2_MACHINE_OPTIONS PC_Q35_2_3_MACHINE_OPTIONS
|
|
|
|
|
2014-07-30 09:02:00 +02:00
|
|
|
static QEMUMachine pc_q35_machine_v2_2 = {
|
|
|
|
PC_Q35_2_2_MACHINE_OPTIONS,
|
|
|
|
.name = "pc-q35-2.2",
|
2014-12-05 10:51:42 +01:00
|
|
|
.init = pc_q35_init_2_2,
|
2014-07-30 09:02:00 +02:00
|
|
|
};
|
|
|
|
|
2014-10-28 10:09:12 +01:00
|
|
|
#define PC_Q35_2_1_MACHINE_OPTIONS \
|
|
|
|
PC_Q35_MACHINE_OPTIONS, \
|
|
|
|
.default_machine_opts = "firmware=bios-256k.bin"
|
2014-07-30 09:02:00 +02:00
|
|
|
|
2014-04-24 12:14:53 +02:00
|
|
|
static QEMUMachine pc_q35_machine_v2_1 = {
|
|
|
|
PC_Q35_2_1_MACHINE_OPTIONS,
|
|
|
|
.name = "pc-q35-2.1",
|
2014-10-29 14:26:07 +01:00
|
|
|
.init = pc_q35_init_2_1,
|
2014-07-30 09:02:00 +02:00
|
|
|
.compat_props = (GlobalProperty[]) {
|
2014-10-14 18:40:06 +02:00
|
|
|
HW_COMPAT_2_1,
|
2014-07-30 09:02:00 +02:00
|
|
|
{ /* end of list */ }
|
|
|
|
},
|
2014-04-24 12:14:53 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
#define PC_Q35_2_0_MACHINE_OPTIONS PC_Q35_2_1_MACHINE_OPTIONS
|
|
|
|
|
2013-12-02 12:47:29 +01:00
|
|
|
static QEMUMachine pc_q35_machine_v2_0 = {
|
|
|
|
PC_Q35_2_0_MACHINE_OPTIONS,
|
|
|
|
.name = "pc-q35-2.0",
|
2014-04-24 12:14:53 +02:00
|
|
|
.init = pc_q35_init_2_0,
|
2014-05-05 16:52:50 +02:00
|
|
|
.compat_props = (GlobalProperty[]) {
|
pc: Move q35 compat props to PC_COMPAT_*
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-25 04:04:44 +02:00
|
|
|
PC_COMPAT_2_0,
|
2014-05-05 16:52:50 +02:00
|
|
|
{ /* end of list */ }
|
|
|
|
},
|
2013-12-02 12:47:29 +01:00
|
|
|
};
|
|
|
|
|
e1000: add interrupt mitigation support
This patch partially implements the e1000 interrupt mitigation mechanisms.
Using a single QEMUTimer, it emulates the ITR register (which is the newer
mitigation register, recommended by Intel) and approximately emulates
RADV and TADV registers. TIDV and RDTR register functionalities are not
emulated (RDTR is only used to validate RADV, according to the e1000 specs).
RADV, TADV, TIDV and RDTR registers make up the older e1000 mitigation
mechanism and would need a timer each to be completely emulated. However,
a single timer has been used in order to reach a good compromise between
emulation accuracy and simplicity/efficiency.
The implemented mechanism can be enabled/disabled specifying the command
line e1000-specific boolean parameter "mitigation", e.g.
qemu-system-x86_64 -device e1000,mitigation=on,... ...
For more information, see the Software developer's manual at
http://download.intel.com/design/network/manuals/8254x_GBe_SDM.pdf.
Interrupt mitigation boosts performance when the guest suffers from
an high interrupt rate (i.e. receiving short UDP packets at high packet
rate). For some numerical results see the following link
http://info.iet.unipi.it/~luigi/papers/20130520-rizzo-vm.pdf
Signed-off-by: Vincenzo Maffione <v.maffione@gmail.com>
Reviewed-by: Andreas Färber <afaerber@suse.de> (for pc-* machines)
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2013-08-02 18:30:52 +02:00
|
|
|
#define PC_Q35_1_7_MACHINE_OPTIONS PC_Q35_MACHINE_OPTIONS
|
|
|
|
|
|
|
|
static QEMUMachine pc_q35_machine_v1_7 = {
|
|
|
|
PC_Q35_1_7_MACHINE_OPTIONS,
|
|
|
|
.name = "pc-q35-1.7",
|
2013-12-08 10:38:17 +01:00
|
|
|
.init = pc_q35_init_1_7,
|
|
|
|
.compat_props = (GlobalProperty[]) {
|
pc: Move q35 compat props to PC_COMPAT_*
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-25 04:04:44 +02:00
|
|
|
PC_COMPAT_1_7,
|
2013-12-08 10:38:17 +01:00
|
|
|
{ /* end of list */ }
|
|
|
|
},
|
e1000: add interrupt mitigation support
This patch partially implements the e1000 interrupt mitigation mechanisms.
Using a single QEMUTimer, it emulates the ITR register (which is the newer
mitigation register, recommended by Intel) and approximately emulates
RADV and TADV registers. TIDV and RDTR register functionalities are not
emulated (RDTR is only used to validate RADV, according to the e1000 specs).
RADV, TADV, TIDV and RDTR registers make up the older e1000 mitigation
mechanism and would need a timer each to be completely emulated. However,
a single timer has been used in order to reach a good compromise between
emulation accuracy and simplicity/efficiency.
The implemented mechanism can be enabled/disabled specifying the command
line e1000-specific boolean parameter "mitigation", e.g.
qemu-system-x86_64 -device e1000,mitigation=on,... ...
For more information, see the Software developer's manual at
http://download.intel.com/design/network/manuals/8254x_GBe_SDM.pdf.
Interrupt mitigation boosts performance when the guest suffers from
an high interrupt rate (i.e. receiving short UDP packets at high packet
rate). For some numerical results see the following link
http://info.iet.unipi.it/~luigi/papers/20130520-rizzo-vm.pdf
Signed-off-by: Vincenzo Maffione <v.maffione@gmail.com>
Reviewed-by: Andreas Färber <afaerber@suse.de> (for pc-* machines)
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2013-08-02 18:30:52 +02:00
|
|
|
};
|
|
|
|
|
2013-08-27 08:48:06 +02:00
|
|
|
#define PC_Q35_1_6_MACHINE_OPTIONS PC_Q35_MACHINE_OPTIONS
|
|
|
|
|
2013-05-27 22:23:53 +02:00
|
|
|
static QEMUMachine pc_q35_machine_v1_6 = {
|
2013-08-27 08:48:06 +02:00
|
|
|
PC_Q35_1_6_MACHINE_OPTIONS,
|
2013-05-27 22:23:53 +02:00
|
|
|
.name = "pc-q35-1.6",
|
2013-08-01 14:39:11 +02:00
|
|
|
.init = pc_q35_init_1_6,
|
e1000: add interrupt mitigation support
This patch partially implements the e1000 interrupt mitigation mechanisms.
Using a single QEMUTimer, it emulates the ITR register (which is the newer
mitigation register, recommended by Intel) and approximately emulates
RADV and TADV registers. TIDV and RDTR register functionalities are not
emulated (RDTR is only used to validate RADV, according to the e1000 specs).
RADV, TADV, TIDV and RDTR registers make up the older e1000 mitigation
mechanism and would need a timer each to be completely emulated. However,
a single timer has been used in order to reach a good compromise between
emulation accuracy and simplicity/efficiency.
The implemented mechanism can be enabled/disabled specifying the command
line e1000-specific boolean parameter "mitigation", e.g.
qemu-system-x86_64 -device e1000,mitigation=on,... ...
For more information, see the Software developer's manual at
http://download.intel.com/design/network/manuals/8254x_GBe_SDM.pdf.
Interrupt mitigation boosts performance when the guest suffers from
an high interrupt rate (i.e. receiving short UDP packets at high packet
rate). For some numerical results see the following link
http://info.iet.unipi.it/~luigi/papers/20130520-rizzo-vm.pdf
Signed-off-by: Vincenzo Maffione <v.maffione@gmail.com>
Reviewed-by: Andreas Färber <afaerber@suse.de> (for pc-* machines)
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2013-08-02 18:30:52 +02:00
|
|
|
.compat_props = (GlobalProperty[]) {
|
pc: Move q35 compat props to PC_COMPAT_*
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-25 04:04:44 +02:00
|
|
|
PC_COMPAT_1_6,
|
e1000: add interrupt mitigation support
This patch partially implements the e1000 interrupt mitigation mechanisms.
Using a single QEMUTimer, it emulates the ITR register (which is the newer
mitigation register, recommended by Intel) and approximately emulates
RADV and TADV registers. TIDV and RDTR register functionalities are not
emulated (RDTR is only used to validate RADV, according to the e1000 specs).
RADV, TADV, TIDV and RDTR registers make up the older e1000 mitigation
mechanism and would need a timer each to be completely emulated. However,
a single timer has been used in order to reach a good compromise between
emulation accuracy and simplicity/efficiency.
The implemented mechanism can be enabled/disabled specifying the command
line e1000-specific boolean parameter "mitigation", e.g.
qemu-system-x86_64 -device e1000,mitigation=on,... ...
For more information, see the Software developer's manual at
http://download.intel.com/design/network/manuals/8254x_GBe_SDM.pdf.
Interrupt mitigation boosts performance when the guest suffers from
an high interrupt rate (i.e. receiving short UDP packets at high packet
rate). For some numerical results see the following link
http://info.iet.unipi.it/~luigi/papers/20130520-rizzo-vm.pdf
Signed-off-by: Vincenzo Maffione <v.maffione@gmail.com>
Reviewed-by: Andreas Färber <afaerber@suse.de> (for pc-* machines)
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2013-08-02 18:30:52 +02:00
|
|
|
{ /* end of list */ }
|
|
|
|
},
|
2013-05-27 22:23:53 +02:00
|
|
|
};
|
|
|
|
|
2013-02-08 14:06:15 +01:00
|
|
|
static QEMUMachine pc_q35_machine_v1_5 = {
|
2013-08-27 08:48:06 +02:00
|
|
|
PC_Q35_1_6_MACHINE_OPTIONS,
|
2013-02-08 14:06:15 +01:00
|
|
|
.name = "pc-q35-1.5",
|
2013-05-13 19:00:23 +02:00
|
|
|
.init = pc_q35_init_1_5,
|
2013-05-27 22:23:54 +02:00
|
|
|
.compat_props = (GlobalProperty[]) {
|
pc: Move q35 compat props to PC_COMPAT_*
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-25 04:04:44 +02:00
|
|
|
PC_COMPAT_1_5,
|
2013-05-27 22:23:54 +02:00
|
|
|
{ /* end of list */ }
|
|
|
|
},
|
2012-11-14 21:54:06 +01:00
|
|
|
};
|
|
|
|
|
2013-08-27 08:48:06 +02:00
|
|
|
#define PC_Q35_1_4_MACHINE_OPTIONS \
|
|
|
|
PC_Q35_1_6_MACHINE_OPTIONS, \
|
|
|
|
.hot_add_cpu = NULL
|
|
|
|
|
2013-02-08 14:06:15 +01:00
|
|
|
static QEMUMachine pc_q35_machine_v1_4 = {
|
2013-08-27 08:48:06 +02:00
|
|
|
PC_Q35_1_4_MACHINE_OPTIONS,
|
2013-02-08 14:06:15 +01:00
|
|
|
.name = "pc-q35-1.4",
|
pc: Kill the "use flash device for BIOS unless KVM" misfeature
Use of a flash memory device for the BIOS was added in series "[PATCH
v10 0/8] PC system flash support", commit 4732dca..1b89faf, v1.1.
Flash vs. ROM is a guest-visible difference. Thus, flash use had to
be suppressed for machine types pc-1.0 and older. This was
accomplished by adding a dummy device "pc-sysfw" with property
"rom_only":
* Non-zero rom_only means "use ROM". Default for pc-1.0 and older.
* Zero rom_only means "maybe use flash". Default for newer machines.
Not only is the dummy device ugly, it was also retroactively added to
the older machine types! Fortunately, it's not guest-visible (thus no
immediate guest ABI breakage), and has no vmstate (thus no immediate
migration breakage). Breakage occurs only if the user unwisely
enables flash by setting rom_only to zero. Patch review FAIL #1.
Why "maybe use flash"? Flash didn't (and still doesn't) work with
KVM. Therefore, rom_only=0 really means "use flash, except when KVM
is enabled, use ROM". This is a Bad Idea, because it makes enabling/
disabling KVM guest-visible. Patch review FAIL #2.
Aside: it also precludes migrating between KVM on and off, but that's
not possible for other reasons anyway.
Fix as follows:
1. Change the meaning of rom_only=0 to mean "use flash, no ifs, buts,
or maybes" for pc-i440fx-1.5 and pc-q35-1.5. Don't change anything
for older machines (to remain bug-compatible).
2. Change the default value from 0 to 1 for these machines.
Necessary, because 0 doesn't work with KVM. Once it does, we can flip
the default back to 0.
3. Don't revert the retroactive addition of device "pc-sysfw" to older
machine types. Seems not worth the trouble.
4. Add a TODO comment asking for device "pc-sysfw" to be dropped once
flash works with KVM.
Net effect is that you get a BIOS ROM again even when KVM is disabled,
just like for machines predating the introduction of flash.
To get flash instead, use "--global pc-sysfw.rom_only=0".
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-id: 1365780303-26398-4-git-send-email-armbru@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-04-12 17:25:03 +02:00
|
|
|
.init = pc_q35_init_1_4,
|
2013-02-08 14:06:15 +01:00
|
|
|
.compat_props = (GlobalProperty[]) {
|
pc: Move q35 compat props to PC_COMPAT_*
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-25 04:04:44 +02:00
|
|
|
PC_COMPAT_1_4,
|
2013-02-08 14:06:15 +01:00
|
|
|
{ /* end of list */ }
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2012-11-14 21:54:06 +01:00
|
|
|
static void pc_q35_machine_init(void)
|
|
|
|
{
|
2015-04-23 08:21:35 +02:00
|
|
|
qemu_register_pc_machine(&pc_q35_machine_v2_4);
|
2014-12-05 10:51:42 +01:00
|
|
|
qemu_register_pc_machine(&pc_q35_machine_v2_3);
|
2014-07-30 09:02:00 +02:00
|
|
|
qemu_register_pc_machine(&pc_q35_machine_v2_2);
|
2014-06-02 15:24:57 +02:00
|
|
|
qemu_register_pc_machine(&pc_q35_machine_v2_1);
|
|
|
|
qemu_register_pc_machine(&pc_q35_machine_v2_0);
|
|
|
|
qemu_register_pc_machine(&pc_q35_machine_v1_7);
|
|
|
|
qemu_register_pc_machine(&pc_q35_machine_v1_6);
|
|
|
|
qemu_register_pc_machine(&pc_q35_machine_v1_5);
|
|
|
|
qemu_register_pc_machine(&pc_q35_machine_v1_4);
|
2012-11-14 21:54:06 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
machine_init(pc_q35_machine_init);
|