2007-11-17 20:14:51 +03:00
|
|
|
#ifndef HW_PC_H
|
|
|
|
|
#define HW_PC_H
|
2009-03-06 02:01:23 +03:00
|
|
|
|
2020-02-28 14:46:49 +03:00
|
|
|
#include "qemu/notify.h"
|
|
|
|
|
#include "qapi/qapi-types-common.h"
|
2021-02-04 22:39:38 +03:00
|
|
|
#include "qemu/uuid.h"
|
2014-06-10 15:15:17 +04:00
|
|
|
#include "hw/boards.h"
|
2013-02-05 20:06:20 +04:00
|
|
|
#include "hw/block/fdc.h"
|
pc: Support firmware configuration with -blockdev
The PC machines put firmware in ROM by default. To get it put into
flash memory (required by OVMF), you have to use -drive
if=pflash,unit=0,... and optionally -drive if=pflash,unit=1,...
Why two -drive? This permits setting up one part of the flash memory
read-only, and the other part read/write. It also makes upgrading
firmware on the host easier. Below the hood, it creates two separate
flash devices, because we were too lazy to improve our flash device
models to support sector protection.
The problem at hand is to do the same with -blockdev somehow, as one
more step towards deprecating -drive.
Mapping -drive if=none,... to -blockdev is a solved problem. With
if=T other than if=none, -drive additionally configures a block device
frontend. For non-onboard devices, that part maps to -device. Also a
solved problem. For onboard devices such as PC flash memory, we have
an unsolved problem.
This is actually an instance of a wider problem: our general device
configuration interface doesn't cover onboard devices. Instead, we have
a zoo of ad hoc interfaces that are much more limited. One of them is
-drive, which we'd rather deprecate, but can't until we have suitable
replacements for all its uses.
Sadly, I can't attack the wider problem today. So back to the narrow
problem.
My first idea was to reduce it to its solved buddy by using pluggable
instead of onboard devices for the flash memory. Workable, but it
requires some extra smarts in firmware descriptors and libvirt. Paolo
had an idea that is simpler for libvirt: keep the devices onboard, and
add machine properties for their block backends.
The implementation is less than straightforward, I'm afraid.
First, block backend properties are *qdev* properties. Machines can't
have those, as they're not devices. I could duplicate these qdev
properties as QOM properties, but I hate that.
More seriously, the properties do not belong to the machine, they
belong to the onboard flash devices. Adding them to the machine would
then require bad magic to somehow transfer them to the flash devices.
Fortunately, QOM provides the means to handle exactly this case: add
alias properties to the machine that forward to the onboard devices'
properties.
Properties need to be created in .instance_init() methods. For PC
machines, that's pc_machine_initfn(). To make alias properties work,
we need to create the onboard flash devices there, too. Requires
several bug fixes, in the previous commits. We also have to realize
the devices. More on that below.
If the user sets pflash0, firmware resides in flash memory.
pc_system_firmware_init() maps and realizes the flash devices.
Else, firmware resides in ROM. The onboard flash devices aren't used
then. pc_system_firmware_init() destroys them unrealized, along with
the alias properties.
The existing code to pick up drives defined with -drive if=pflash is
replaced by code to desugar into the machine properties.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <87ftrtux81.fsf@dusky.pond.sub.org>
2019-03-11 20:39:26 +03:00
|
|
|
#include "hw/block/flash.h"
|
2019-10-22 10:39:50 +03:00
|
|
|
#include "hw/i386/x86.h"
|
2009-03-06 02:01:23 +03:00
|
|
|
|
2016-04-20 12:28:57 +03:00
|
|
|
#include "hw/acpi/acpi_dev_interface.h"
|
2020-02-28 14:46:49 +03:00
|
|
|
#include "hw/hotplug.h"
|
2020-09-03 23:43:22 +03:00
|
|
|
#include "qom/object.h"
|
vl: Add sgx compound properties to expose SGX EPC sections to guest
Because SGX EPC is enumerated through CPUID, EPC "devices" need to be
realized prior to realizing the vCPUs themselves, i.e. long before
generic devices are parsed and realized. From a virtualization
perspective, the CPUID aspect also means that EPC sections cannot be
hotplugged without paravirtualizing the guest kernel (hardware does
not support hotplugging as EPC sections must be locked down during
pre-boot to provide EPC's security properties).
So even though EPC sections could be realized through the generic
-devices command, they need to be created much earlier for them to
actually be usable by the guest. Place all EPC sections in a
contiguous block, somewhat arbitrarily starting after RAM above 4g.
Ensuring EPC is in a contiguous region simplifies calculations, e.g.
device memory base, PCI hole, etc..., allows dynamic calculation of the
total EPC size, e.g. exposing EPC to guests does not require -maxmem,
and last but not least allows all of EPC to be enumerated in a single
ACPI entry, which is expected by some kernels, e.g. Windows 7 and 8.
The new compound properties command for sgx like below:
......
-object memory-backend-epc,id=mem1,size=28M,prealloc=on \
-object memory-backend-epc,id=mem2,size=10M \
-M sgx-epc.0.memdev=mem1,sgx-epc.1.memdev=mem2
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Yang Zhong <yang.zhong@intel.com>
Message-Id: <20210719112136.57018-6-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-28 11:40:58 +03:00
|
|
|
#include "hw/i386/sgx-epc.h"
|
2013-05-30 13:57:26 +04:00
|
|
|
|
2013-12-08 13:38:17 +04:00
|
|
|
#define HPET_INTCAP "hpet-intcap"
|
|
|
|
|
|
2014-06-02 17:25:08 +04:00
|
|
|
/**
|
|
|
|
|
* PCMachineState:
|
2014-06-02 17:25:24 +04:00
|
|
|
* @acpi_dev: link to ACPI PM device that performs ACPI hotplug handling
|
2016-11-16 16:04:41 +03:00
|
|
|
* @boot_cpus: number of present VCPUs
|
2014-06-02 17:25:08 +04:00
|
|
|
*/
|
2020-09-08 18:55:30 +03:00
|
|
|
typedef struct PCMachineState {
|
2014-06-02 17:24:57 +04:00
|
|
|
/*< private >*/
|
2019-10-22 10:39:50 +03:00
|
|
|
X86MachineState parent_obj;
|
2014-06-02 17:25:08 +04:00
|
|
|
|
|
|
|
|
/* <public> */
|
2015-12-11 21:42:21 +03:00
|
|
|
|
|
|
|
|
/* State for other subsystems/APIs: */
|
2015-12-11 21:42:23 +03:00
|
|
|
Notifier machine_done;
|
2014-06-02 17:25:24 +04:00
|
|
|
|
2015-12-11 21:42:21 +03:00
|
|
|
/* Pointers to devices and objects: */
|
|
|
|
|
PCIBus *bus;
|
2016-05-13 04:43:45 +03:00
|
|
|
I2CBus *smbus;
|
pc: Support firmware configuration with -blockdev
The PC machines put firmware in ROM by default. To get it put into
flash memory (required by OVMF), you have to use -drive
if=pflash,unit=0,... and optionally -drive if=pflash,unit=1,...
Why two -drive? This permits setting up one part of the flash memory
read-only, and the other part read/write. It also makes upgrading
firmware on the host easier. Below the hood, it creates two separate
flash devices, because we were too lazy to improve our flash device
models to support sector protection.
The problem at hand is to do the same with -blockdev somehow, as one
more step towards deprecating -drive.
Mapping -drive if=none,... to -blockdev is a solved problem. With
if=T other than if=none, -drive additionally configures a block device
frontend. For non-onboard devices, that part maps to -device. Also a
solved problem. For onboard devices such as PC flash memory, we have
an unsolved problem.
This is actually an instance of a wider problem: our general device
configuration interface doesn't cover onboard devices. Instead, we have
a zoo of ad hoc interfaces that are much more limited. One of them is
-drive, which we'd rather deprecate, but can't until we have suitable
replacements for all its uses.
Sadly, I can't attack the wider problem today. So back to the narrow
problem.
My first idea was to reduce it to its solved buddy by using pluggable
instead of onboard devices for the flash memory. Workable, but it
requires some extra smarts in firmware descriptors and libvirt. Paolo
had an idea that is simpler for libvirt: keep the devices onboard, and
add machine properties for their block backends.
The implementation is less than straightforward, I'm afraid.
First, block backend properties are *qdev* properties. Machines can't
have those, as they're not devices. I could duplicate these qdev
properties as QOM properties, but I hate that.
More seriously, the properties do not belong to the machine, they
belong to the onboard flash devices. Adding them to the machine would
then require bad magic to somehow transfer them to the flash devices.
Fortunately, QOM provides the means to handle exactly this case: add
alias properties to the machine that forward to the onboard devices'
properties.
Properties need to be created in .instance_init() methods. For PC
machines, that's pc_machine_initfn(). To make alias properties work,
we need to create the onboard flash devices there, too. Requires
several bug fixes, in the previous commits. We also have to realize
the devices. More on that below.
If the user sets pflash0, firmware resides in flash memory.
pc_system_firmware_init() maps and realizes the flash devices.
Else, firmware resides in ROM. The onboard flash devices aren't used
then. pc_system_firmware_init() destroys them unrealized, along with
the alias properties.
The existing code to pick up drives defined with -drive if=pflash is
replaced by code to desugar into the machine properties.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <87ftrtux81.fsf@dusky.pond.sub.org>
2019-03-11 20:39:26 +03:00
|
|
|
PFlashCFI01 *flash[2];
|
2020-07-02 16:25:21 +03:00
|
|
|
ISADevice *pcspk;
|
2014-06-20 05:40:25 +04:00
|
|
|
|
2015-12-11 21:42:21 +03:00
|
|
|
/* Configuration options: */
|
2020-05-29 10:39:56 +03:00
|
|
|
uint64_t max_ram_below_4g;
|
2014-11-21 19:18:52 +03:00
|
|
|
OnOffAuto vmport;
|
2016-03-04 19:00:32 +03:00
|
|
|
|
2016-11-01 20:44:16 +03:00
|
|
|
bool acpi_build_enabled;
|
2018-11-07 18:24:34 +03:00
|
|
|
bool smbus_enabled;
|
|
|
|
|
bool sata_enabled;
|
|
|
|
|
bool pit_enabled;
|
2020-10-21 17:47:16 +03:00
|
|
|
bool hpet_enabled;
|
2021-07-08 15:55:14 +03:00
|
|
|
bool default_bus_bypass_iommu;
|
2020-12-08 18:53:38 +03:00
|
|
|
uint64_t max_fw_size;
|
2016-11-01 20:44:16 +03:00
|
|
|
|
2019-09-18 16:06:23 +03:00
|
|
|
/* ACPI Memory hotplug IO base address */
|
|
|
|
|
hwaddr memhp_io_base;
|
vl: Add sgx compound properties to expose SGX EPC sections to guest
Because SGX EPC is enumerated through CPUID, EPC "devices" need to be
realized prior to realizing the vCPUs themselves, i.e. long before
generic devices are parsed and realized. From a virtualization
perspective, the CPUID aspect also means that EPC sections cannot be
hotplugged without paravirtualizing the guest kernel (hardware does
not support hotplugging as EPC sections must be locked down during
pre-boot to provide EPC's security properties).
So even though EPC sections could be realized through the generic
-devices command, they need to be created much earlier for them to
actually be usable by the guest. Place all EPC sections in a
contiguous block, somewhat arbitrarily starting after RAM above 4g.
Ensuring EPC is in a contiguous region simplifies calculations, e.g.
device memory base, PCI hole, etc..., allows dynamic calculation of the
total EPC size, e.g. exposing EPC to guests does not require -maxmem,
and last but not least allows all of EPC to be enumerated in a single
ACPI entry, which is expected by some kernels, e.g. Windows 7 and 8.
The new compound properties command for sgx like below:
......
-object memory-backend-epc,id=mem1,size=28M,prealloc=on \
-object memory-backend-epc,id=mem2,size=10M \
-M sgx-epc.0.memdev=mem1,sgx-epc.1.memdev=mem2
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Yang Zhong <yang.zhong@intel.com>
Message-Id: <20210719112136.57018-6-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-28 11:40:58 +03:00
|
|
|
|
|
|
|
|
SGXEPCState sgx_epc;
|
2020-09-08 18:55:30 +03:00
|
|
|
} PCMachineState;
|
2014-06-02 17:24:57 +04:00
|
|
|
|
2014-06-02 17:25:24 +04:00
|
|
|
#define PC_MACHINE_ACPI_DEVICE_PROP "acpi-device"
|
2020-05-29 10:39:56 +03:00
|
|
|
#define PC_MACHINE_MAX_RAM_BELOW_4G "max-ram-below-4g"
|
2018-04-23 19:51:24 +03:00
|
|
|
#define PC_MACHINE_DEVMEM_REGION_SIZE "device-memory-region-size"
|
2014-10-04 01:33:37 +04:00
|
|
|
#define PC_MACHINE_VMPORT "vmport"
|
2016-11-05 10:19:48 +03:00
|
|
|
#define PC_MACHINE_SMBUS "smbus"
|
2016-11-05 10:19:49 +03:00
|
|
|
#define PC_MACHINE_SATA "sata"
|
2016-11-05 10:19:50 +03:00
|
|
|
#define PC_MACHINE_PIT "pit"
|
2020-12-08 18:53:38 +03:00
|
|
|
#define PC_MACHINE_MAX_FW_SIZE "max-fw-size"
|
2014-06-02 17:25:12 +04:00
|
|
|
/**
|
|
|
|
|
* PCMachineClass:
|
2015-12-11 21:42:21 +03:00
|
|
|
*
|
|
|
|
|
* Compat fields:
|
|
|
|
|
*
|
2015-12-02 01:58:06 +03:00
|
|
|
* @enforce_aligned_dimm: check that DIMM's address/size is aligned by
|
|
|
|
|
* backend's alignment value if provided
|
2015-12-11 21:42:21 +03:00
|
|
|
* @acpi_data_size: Size of the chunk of memory at the top of RAM
|
|
|
|
|
* for the BIOS ACPI tables and other BIOS
|
|
|
|
|
* datastructures.
|
|
|
|
|
* @gigabyte_align: 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.
|
|
|
|
|
*
|
2014-06-02 17:25:12 +04:00
|
|
|
*/
|
2020-09-03 23:43:22 +03:00
|
|
|
struct PCMachineClass {
|
2014-06-02 17:24:57 +04:00
|
|
|
/*< private >*/
|
2019-10-22 10:39:50 +03:00
|
|
|
X86MachineClass parent_class;
|
2014-06-02 17:25:12 +04:00
|
|
|
|
|
|
|
|
/*< public >*/
|
2015-12-11 21:42:21 +03:00
|
|
|
|
|
|
|
|
/* Device configuration: */
|
2015-12-02 01:58:03 +03:00
|
|
|
bool pci_enabled;
|
2015-12-11 21:42:21 +03:00
|
|
|
bool kvmclock_enabled;
|
2018-03-02 12:29:06 +03:00
|
|
|
const char *default_nic_model;
|
2015-12-11 21:42:21 +03:00
|
|
|
|
|
|
|
|
/* Compat options: */
|
|
|
|
|
|
2019-06-28 03:28:42 +03:00
|
|
|
/* Default CPU model version. See x86_cpu_set_default_version(). */
|
|
|
|
|
int default_cpu_version;
|
|
|
|
|
|
2015-12-11 21:42:21 +03:00
|
|
|
/* ACPI compat: */
|
2015-12-02 01:58:03 +03:00
|
|
|
bool has_acpi_build;
|
|
|
|
|
bool rsdp_in_ram;
|
2015-12-11 21:42:21 +03:00
|
|
|
int legacy_acpi_table_size;
|
|
|
|
|
unsigned acpi_data_size;
|
2016-05-13 04:43:45 +03:00
|
|
|
bool do_not_add_smb_acpi;
|
2021-03-01 22:59:18 +03:00
|
|
|
int pci_root_uid;
|
2015-12-11 21:42:21 +03:00
|
|
|
|
|
|
|
|
/* SMBIOS compat: */
|
2015-12-02 01:58:03 +03:00
|
|
|
bool smbios_defaults;
|
|
|
|
|
bool smbios_legacy_mode;
|
|
|
|
|
bool smbios_uuid_encoded;
|
2015-12-11 21:42:21 +03:00
|
|
|
|
|
|
|
|
/* RAM / address space compat: */
|
2015-12-02 01:58:03 +03:00
|
|
|
bool gigabyte_align;
|
|
|
|
|
bool has_reserved_memory;
|
2015-12-02 01:58:06 +03:00
|
|
|
bool enforce_aligned_dimm;
|
2015-12-11 21:42:21 +03:00
|
|
|
bool broken_reserved_end;
|
2015-11-24 06:33:57 +03:00
|
|
|
|
2016-06-15 12:25:23 +03:00
|
|
|
/* generate legacy CPU hotplug AML */
|
|
|
|
|
bool legacy_cpu_hotplug;
|
2017-04-25 18:37:50 +03:00
|
|
|
|
|
|
|
|
/* use DMA capable linuxboot option rom */
|
|
|
|
|
bool linuxboot_dma_enabled;
|
2019-01-22 15:10:48 +03:00
|
|
|
|
|
|
|
|
/* use PVH to load kernels that support this feature */
|
|
|
|
|
bool pvh_enabled;
|
2020-09-22 18:19:34 +03:00
|
|
|
|
|
|
|
|
/* create kvmclock device even when KVM PV features are not exposed */
|
|
|
|
|
bool kvmclock_create_always;
|
2020-09-03 23:43:22 +03:00
|
|
|
};
|
2014-06-02 17:24:57 +04:00
|
|
|
|
|
|
|
|
#define TYPE_PC_MACHINE "generic-pc-machine"
|
2020-09-16 21:25:18 +03:00
|
|
|
OBJECT_DECLARE_TYPE(PCMachineState, PCMachineClass, PC_MACHINE)
|
2014-06-02 17:24:57 +04:00
|
|
|
|
2015-09-22 16:18:20 +03:00
|
|
|
/* ioapic.c */
|
|
|
|
|
|
2019-10-18 16:59:06 +03:00
|
|
|
GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled);
|
|
|
|
|
|
2007-11-17 20:14:51 +03:00
|
|
|
/* pc.c */
|
|
|
|
|
extern int fd_bootchk;
|
|
|
|
|
|
2010-05-14 11:29:15 +04:00
|
|
|
void pc_acpi_smi_interrupt(void *opaque, int irq, int level);
|
|
|
|
|
|
2015-12-11 21:42:33 +03:00
|
|
|
void pc_guest_info_init(PCMachineState *pcms);
|
2013-05-30 13:57:26 +04:00
|
|
|
|
2013-07-29 18:47:57 +04:00
|
|
|
#define PCI_HOST_PROP_PCI_HOLE_START "pci-hole-start"
|
|
|
|
|
#define PCI_HOST_PROP_PCI_HOLE_END "pci-hole-end"
|
|
|
|
|
#define PCI_HOST_PROP_PCI_HOLE64_START "pci-hole64-start"
|
|
|
|
|
#define PCI_HOST_PROP_PCI_HOLE64_END "pci-hole64-end"
|
|
|
|
|
#define PCI_HOST_PROP_PCI_HOLE64_SIZE "pci-hole64-size"
|
2016-06-22 15:24:49 +03:00
|
|
|
#define PCI_HOST_BELOW_4G_MEM_SIZE "below-4g-mem-size"
|
|
|
|
|
#define PCI_HOST_ABOVE_4G_MEM_SIZE "above-4g-mem-size"
|
2013-08-27 09:37:26 +04:00
|
|
|
|
2013-07-29 18:47:57 +04:00
|
|
|
|
2013-10-29 16:57:34 +04:00
|
|
|
void pc_pci_as_mapping_init(Object *owner, MemoryRegion *system_memory,
|
|
|
|
|
MemoryRegion *pci_address_space);
|
2013-07-29 18:47:57 +04:00
|
|
|
|
2015-12-11 21:42:25 +03:00
|
|
|
void xen_load_linux(PCMachineState *pcms);
|
2015-12-11 21:42:24 +03:00
|
|
|
void pc_memory_init(PCMachineState *pcms,
|
|
|
|
|
MemoryRegion *system_memory,
|
|
|
|
|
MemoryRegion *rom_memory,
|
|
|
|
|
MemoryRegion **ram_memory);
|
2017-11-11 18:25:00 +03:00
|
|
|
uint64_t pc_pci_hole64_start(void);
|
2011-12-16 01:09:51 +04:00
|
|
|
DeviceState *pc_vga_init(ISABus *isa_bus, PCIBus *pci_bus);
|
2020-07-02 16:25:16 +03:00
|
|
|
void pc_basic_device_init(struct PCMachineState *pcms,
|
|
|
|
|
ISABus *isa_bus, qemu_irq *gsi,
|
2011-05-03 20:06:54 +04:00
|
|
|
ISADevice **rtc_state,
|
2015-05-28 23:04:08 +03:00
|
|
|
bool create_fdctrl,
|
2016-01-22 18:09:21 +03:00
|
|
|
uint32_t hpet_irqs);
|
2011-12-16 01:09:51 +04:00
|
|
|
void pc_init_ne2k_isa(ISABus *bus, NICInfo *nd);
|
2015-08-07 22:55:49 +03:00
|
|
|
void pc_cmos_init(PCMachineState *pcms,
|
2015-06-25 16:35:07 +03:00
|
|
|
BusState *ide0, BusState *ide1,
|
2011-02-05 19:32:23 +03:00
|
|
|
ISADevice *s);
|
2018-03-02 12:29:06 +03:00
|
|
|
void pc_nic_init(PCMachineClass *pcmc, ISABus *isa_bus, PCIBus *pci_bus);
|
2010-05-14 11:29:15 +04:00
|
|
|
void pc_pci_device_init(PCIBus *pci_bus);
|
2010-05-14 11:29:09 +04:00
|
|
|
|
2010-05-14 11:29:04 +04:00
|
|
|
typedef void (*cpu_set_smm_t)(int smm, void *arg);
|
|
|
|
|
|
2019-10-18 16:59:09 +03:00
|
|
|
void pc_i8259_create(ISABus *isa_bus, qemu_irq *i8259_irqs);
|
2012-11-15 00:54:01 +04:00
|
|
|
|
2015-12-30 23:11:51 +03:00
|
|
|
ISADevice *pc_find_fdc0(void);
|
|
|
|
|
|
2019-12-13 13:51:00 +03:00
|
|
|
/* port92.c */
|
2016-06-22 15:24:52 +03:00
|
|
|
#define PORT92_A20_LINE "a20"
|
|
|
|
|
|
2019-12-13 13:51:00 +03:00
|
|
|
#define TYPE_PORT92 "port92"
|
|
|
|
|
|
2012-02-22 11:18:51 +04:00
|
|
|
/* pc_sysfw.c */
|
pc: Support firmware configuration with -blockdev
The PC machines put firmware in ROM by default. To get it put into
flash memory (required by OVMF), you have to use -drive
if=pflash,unit=0,... and optionally -drive if=pflash,unit=1,...
Why two -drive? This permits setting up one part of the flash memory
read-only, and the other part read/write. It also makes upgrading
firmware on the host easier. Below the hood, it creates two separate
flash devices, because we were too lazy to improve our flash device
models to support sector protection.
The problem at hand is to do the same with -blockdev somehow, as one
more step towards deprecating -drive.
Mapping -drive if=none,... to -blockdev is a solved problem. With
if=T other than if=none, -drive additionally configures a block device
frontend. For non-onboard devices, that part maps to -device. Also a
solved problem. For onboard devices such as PC flash memory, we have
an unsolved problem.
This is actually an instance of a wider problem: our general device
configuration interface doesn't cover onboard devices. Instead, we have
a zoo of ad hoc interfaces that are much more limited. One of them is
-drive, which we'd rather deprecate, but can't until we have suitable
replacements for all its uses.
Sadly, I can't attack the wider problem today. So back to the narrow
problem.
My first idea was to reduce it to its solved buddy by using pluggable
instead of onboard devices for the flash memory. Workable, but it
requires some extra smarts in firmware descriptors and libvirt. Paolo
had an idea that is simpler for libvirt: keep the devices onboard, and
add machine properties for their block backends.
The implementation is less than straightforward, I'm afraid.
First, block backend properties are *qdev* properties. Machines can't
have those, as they're not devices. I could duplicate these qdev
properties as QOM properties, but I hate that.
More seriously, the properties do not belong to the machine, they
belong to the onboard flash devices. Adding them to the machine would
then require bad magic to somehow transfer them to the flash devices.
Fortunately, QOM provides the means to handle exactly this case: add
alias properties to the machine that forward to the onboard devices'
properties.
Properties need to be created in .instance_init() methods. For PC
machines, that's pc_machine_initfn(). To make alias properties work,
we need to create the onboard flash devices there, too. Requires
several bug fixes, in the previous commits. We also have to realize
the devices. More on that below.
If the user sets pflash0, firmware resides in flash memory.
pc_system_firmware_init() maps and realizes the flash devices.
Else, firmware resides in ROM. The onboard flash devices aren't used
then. pc_system_firmware_init() destroys them unrealized, along with
the alias properties.
The existing code to pick up drives defined with -drive if=pflash is
replaced by code to desugar into the machine properties.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <87ftrtux81.fsf@dusky.pond.sub.org>
2019-03-11 20:39:26 +03:00
|
|
|
void pc_system_flash_create(PCMachineState *pcms);
|
2020-06-24 15:18:41 +03:00
|
|
|
void pc_system_flash_cleanup_unused(PCMachineState *pcms);
|
2019-03-08 16:14:43 +03:00
|
|
|
void pc_system_firmware_init(PCMachineState *pcms, MemoryRegion *rom_memory);
|
2021-02-04 22:39:38 +03:00
|
|
|
bool pc_system_ovmf_table_find(const char *entry, uint8_t **data,
|
|
|
|
|
int *data_len);
|
2021-05-21 16:34:07 +03:00
|
|
|
void pc_system_parse_ovmf_flash(uint8_t *flash_ptr, size_t flash_size);
|
2021-02-04 22:39:38 +03:00
|
|
|
|
2012-02-22 11:18:51 +04:00
|
|
|
|
2016-04-20 12:28:57 +03:00
|
|
|
/* acpi-build.c */
|
|
|
|
|
void pc_madt_cpu_entry(AcpiDeviceIf *adev, int uid,
|
2017-01-18 20:13:20 +03:00
|
|
|
const CPUArchIdList *apic_ids, GArray *entry);
|
2016-04-20 12:28:57 +03:00
|
|
|
|
2021-08-31 04:54:26 +03:00
|
|
|
extern GlobalProperty pc_compat_6_1[];
|
|
|
|
|
extern const size_t pc_compat_6_1_len;
|
|
|
|
|
|
2021-03-31 14:19:00 +03:00
|
|
|
extern GlobalProperty pc_compat_6_0[];
|
|
|
|
|
extern const size_t pc_compat_6_0_len;
|
|
|
|
|
|
2020-11-09 20:39:28 +03:00
|
|
|
extern GlobalProperty pc_compat_5_2[];
|
|
|
|
|
extern const size_t pc_compat_5_2_len;
|
|
|
|
|
|
2020-08-19 17:40:16 +03:00
|
|
|
extern GlobalProperty pc_compat_5_1[];
|
|
|
|
|
extern const size_t pc_compat_5_1_len;
|
|
|
|
|
|
2020-04-29 17:46:05 +03:00
|
|
|
extern GlobalProperty pc_compat_5_0[];
|
|
|
|
|
extern const size_t pc_compat_5_0_len;
|
|
|
|
|
|
2019-11-12 13:48:11 +03:00
|
|
|
extern GlobalProperty pc_compat_4_2[];
|
|
|
|
|
extern const size_t pc_compat_4_2_len;
|
|
|
|
|
|
2019-07-24 13:35:24 +03:00
|
|
|
extern GlobalProperty pc_compat_4_1[];
|
|
|
|
|
extern const size_t pc_compat_4_1_len;
|
|
|
|
|
|
2019-04-11 13:20:25 +03:00
|
|
|
extern GlobalProperty pc_compat_4_0[];
|
|
|
|
|
extern const size_t pc_compat_4_0_len;
|
|
|
|
|
|
2018-12-12 18:36:30 +03:00
|
|
|
extern GlobalProperty pc_compat_3_1[];
|
|
|
|
|
extern const size_t pc_compat_3_1_len;
|
2018-12-04 19:27:16 +03:00
|
|
|
|
2018-12-12 18:36:30 +03:00
|
|
|
extern GlobalProperty pc_compat_3_0[];
|
|
|
|
|
extern const size_t pc_compat_3_0_len;
|
2018-09-21 11:22:10 +03:00
|
|
|
|
2018-12-12 18:36:30 +03:00
|
|
|
extern GlobalProperty pc_compat_2_12[];
|
|
|
|
|
extern const size_t pc_compat_2_12_len;
|
2018-05-14 19:41:50 +03:00
|
|
|
|
2018-12-12 18:36:30 +03:00
|
|
|
extern GlobalProperty pc_compat_2_11[];
|
|
|
|
|
extern const size_t pc_compat_2_11_len;
|
2017-12-19 06:37:29 +03:00
|
|
|
|
2018-12-12 18:36:30 +03:00
|
|
|
extern GlobalProperty pc_compat_2_10[];
|
|
|
|
|
extern const size_t pc_compat_2_10_len;
|
2017-09-06 17:26:57 +03:00
|
|
|
|
2018-12-12 18:36:30 +03:00
|
|
|
extern GlobalProperty pc_compat_2_9[];
|
|
|
|
|
extern const size_t pc_compat_2_9_len;
|
2017-04-25 12:49:13 +03:00
|
|
|
|
2018-12-12 18:36:30 +03:00
|
|
|
extern GlobalProperty pc_compat_2_8[];
|
|
|
|
|
extern const size_t pc_compat_2_8_len;
|
2017-01-18 20:53:45 +03:00
|
|
|
|
2018-12-12 18:36:30 +03:00
|
|
|
extern GlobalProperty pc_compat_2_7[];
|
|
|
|
|
extern const size_t pc_compat_2_7_len;
|
target-i386: present virtual L3 cache info for vcpus
Some software algorithms are based on the hardware's cache info, for example,
for x86 linux kernel, when cpu1 want to wakeup a task on cpu2, cpu1 will trigger
a resched IPI and told cpu2 to do the wakeup if they don't share low level
cache. Oppositely, cpu1 will access cpu2's runqueue directly if they share llc.
The relevant linux-kernel code as bellow:
static void ttwu_queue(struct task_struct *p, int cpu)
{
struct rq *rq = cpu_rq(cpu);
......
if (... && !cpus_share_cache(smp_processor_id(), cpu)) {
......
ttwu_queue_remote(p, cpu); /* will trigger RES IPI */
return;
}
......
ttwu_do_activate(rq, p, 0); /* access target's rq directly */
......
}
In real hardware, the cpus on the same socket share L3 cache, so one won't
trigger a resched IPIs when wakeup a task on others. But QEMU doesn't present a
virtual L3 cache info for VM, then the linux guest will trigger lots of RES IPIs
under some workloads even if the virtual cpus belongs to the same virtual socket.
For KVM, there will be lots of vmexit due to guest send IPIs.
The workload is a SAP HANA's testsuite, we run it one round(about 40 minuates)
and observe the (Suse11sp3)Guest's amounts of RES IPIs which triggering during
the period:
No-L3 With-L3(applied this patch)
cpu0: 363890 44582
cpu1: 373405 43109
cpu2: 340783 43797
cpu3: 333854 43409
cpu4: 327170 40038
cpu5: 325491 39922
cpu6: 319129 42391
cpu7: 306480 41035
cpu8: 161139 32188
cpu9: 164649 31024
cpu10: 149823 30398
cpu11: 149823 32455
cpu12: 164830 35143
cpu13: 172269 35805
cpu14: 179979 33898
cpu15: 194505 32754
avg: 268963.6 40129.8
The VM's topology is "1*socket 8*cores 2*threads".
After present virtual L3 cache info for VM, the amounts of RES IPIs in guest
reduce 85%.
For KVM, vcpus send IPIs will cause vmexit which is expensive, so it can cause
severe performance degradation. We had tested the overall system performance if
vcpus actually run on sparate physical socket. With L3 cache, the performance
improves 7.2%~33.1%(avg:15.7%).
Signed-off-by: Longpeng(Mike) <longpeng2@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-09-07 08:21:13 +03:00
|
|
|
|
2018-12-12 18:36:30 +03:00
|
|
|
extern GlobalProperty pc_compat_2_6[];
|
|
|
|
|
extern const size_t pc_compat_2_6_len;
|
2016-05-17 17:43:10 +03:00
|
|
|
|
2018-12-12 18:36:30 +03:00
|
|
|
extern GlobalProperty pc_compat_2_5[];
|
|
|
|
|
extern const size_t pc_compat_2_5_len;
|
2015-11-30 17:56:36 +03:00
|
|
|
|
2018-12-12 18:36:30 +03:00
|
|
|
extern GlobalProperty pc_compat_2_4[];
|
|
|
|
|
extern const size_t pc_compat_2_4_len;
|
|
|
|
|
|
2018-12-12 18:36:30 +03:00
|
|
|
extern GlobalProperty pc_compat_2_3[];
|
|
|
|
|
extern const size_t pc_compat_2_3_len;
|
|
|
|
|
|
2018-12-12 18:36:30 +03:00
|
|
|
extern GlobalProperty pc_compat_2_2[];
|
|
|
|
|
extern const size_t pc_compat_2_2_len;
|
|
|
|
|
|
2018-12-12 18:36:30 +03:00
|
|
|
extern GlobalProperty pc_compat_2_1[];
|
|
|
|
|
extern const size_t pc_compat_2_1_len;
|
|
|
|
|
|
2018-12-12 20:57:53 +03:00
|
|
|
extern GlobalProperty pc_compat_2_0[];
|
|
|
|
|
extern const size_t pc_compat_2_0_len;
|
|
|
|
|
|
|
|
|
|
extern GlobalProperty pc_compat_1_7[];
|
|
|
|
|
extern const size_t pc_compat_1_7_len;
|
|
|
|
|
|
|
|
|
|
extern GlobalProperty pc_compat_1_6[];
|
|
|
|
|
extern const size_t pc_compat_1_6_len;
|
|
|
|
|
|
|
|
|
|
extern GlobalProperty pc_compat_1_5[];
|
|
|
|
|
extern const size_t pc_compat_1_5_len;
|
|
|
|
|
|
|
|
|
|
extern GlobalProperty pc_compat_1_4[];
|
|
|
|
|
extern const size_t pc_compat_1_4_len;
|
|
|
|
|
|
2016-04-09 22:26:38 +03:00
|
|
|
/* Helper for setting model-id for CPU models that changed model-id
|
|
|
|
|
* depending on QEMU versions up to QEMU 2.4.
|
|
|
|
|
*/
|
|
|
|
|
#define PC_CPU_MODEL_IDS(v) \
|
2019-01-07 22:30:20 +03:00
|
|
|
{ "qemu32-" TYPE_X86_CPU, "model-id", "QEMU Virtual CPU version " v, },\
|
|
|
|
|
{ "qemu64-" TYPE_X86_CPU, "model-id", "QEMU Virtual CPU version " v, },\
|
|
|
|
|
{ "athlon-" TYPE_X86_CPU, "model-id", "QEMU Virtual CPU version " v, },
|
2016-04-09 22:26:38 +03:00
|
|
|
|
2015-05-15 20:18:55 +03:00
|
|
|
#define DEFINE_PC_MACHINE(suffix, namestr, initfn, optsfn) \
|
2015-05-15 20:18:56 +03:00
|
|
|
static void pc_machine_##suffix##_class_init(ObjectClass *oc, void *data) \
|
|
|
|
|
{ \
|
|
|
|
|
MachineClass *mc = MACHINE_CLASS(oc); \
|
|
|
|
|
optsfn(mc); \
|
|
|
|
|
mc->init = initfn; \
|
|
|
|
|
} \
|
|
|
|
|
static const TypeInfo pc_machine_type_##suffix = { \
|
|
|
|
|
.name = namestr TYPE_MACHINE_SUFFIX, \
|
|
|
|
|
.parent = TYPE_PC_MACHINE, \
|
|
|
|
|
.class_init = pc_machine_##suffix##_class_init, \
|
|
|
|
|
}; \
|
2015-05-15 20:18:53 +03:00
|
|
|
static void pc_machine_init_##suffix(void) \
|
|
|
|
|
{ \
|
2015-05-15 20:18:56 +03:00
|
|
|
type_register(&pc_machine_type_##suffix); \
|
2015-05-15 20:18:53 +03:00
|
|
|
} \
|
2016-02-16 23:59:04 +03:00
|
|
|
type_init(pc_machine_init_##suffix)
|
2015-05-15 20:18:53 +03:00
|
|
|
|
2015-07-15 08:37:47 +03:00
|
|
|
extern void igd_passthrough_isa_bridge_create(PCIBus *bus, uint16_t gpu_dev_id);
|
2007-11-17 20:14:51 +03:00
|
|
|
#endif
|