If QEMU is started with -numa ... Windows only notices that
CPU has been hot-added but it will not online such CPUs.
It's caused by the fact that possible CPUs are flagged as
not enabled in SRAT and Windows honoring that information
doesn't use corresponding CPU.
ACPI 5.0 Spec regarding to flag says:
"
Table 5-47 Local APIC Flags
...
Enabled: if zero, this processor is unusable, and the operating system
support will not attempt to use it.
"
Fix QEMU to adhere to spec and mark possible CPUs as enabled
in SRAT.
With that Windows onlines hot-added CPUs as expected.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
acpi build modifies internal FW CFG RAM on first access
but we forgot to mark it dirty.
If this RAM has been migrated already, it won't be
migrated again, returning corrupted tables to guest.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
There are three ACPI tables: 'linker_data', 'rsdp' and 'table_data'. They are
used differently. Two of them are being copied before using and only the copy
is used later. But the third is used directly. Because of that we need to free
two tables completely and delete only wrapper for the third one.
Valgrind output:
==23931== 131,072 bytes in 1 blocks are definitely lost in loss record 7,729 of 7,734
==23931== at 0x4C2CE8E: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23931== by 0x2EA920: realloc_and_trace (vl.c:2811)
==23931== by 0x509E6AE: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==23931== by 0x506DB32: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==23931== by 0x506E463: g_array_set_size (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==23931== by 0x256A4F: acpi_align_size (acpi-build.c:487)
==23931== by 0x259F92: acpi_build (acpi-build.c:1601)
==23931== by 0x25A212: acpi_setup (acpi-build.c:1682)
==23931== by 0x24F346: pc_guest_info_machine_done (pc.c:1110)
==23931== by 0x55FAAB: notifier_list_notify (notify.c:39)
==23931== by 0x2EA704: qemu_run_machine_init_done_notifiers (vl.c:2759)
==23931== by 0x2EEC3C: main (vl.c:4504)
Signed-off-by: Nikita Belov <zodiac@ispras.ru>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Create the TCPA log in a separate file rather than allocating
ACPI table memory for it.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
It would allow to transparently switch detection whether Bus
is hotpluggable from allow_hotplug field to hotplug_handler
link and to drop allow_hotplug field once all users are
converted to hotplug handler API.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
If we start Windows 2008 R2 DataCenter with number of cpu less than 8,
The system will use APIC Flat Logical destination mode as default configuration,
Which has an upper limit of 8 CPUs.
The fault is that VM can not show all processors within Task Manager if
we hot-add cpus when the number of cpus in VM extends the limit of 8.
If we use cluster destination model, the problem will be solved.
Note:
This flag was introduced later than ACPI v1.0 specification while QEMU
generates v1.0 tables only, but...
linux kernel ignores this flag, so patch has no influence on it.
Tested with Win[XPsp3|Srv2003EE|Srv2008DC|Srv2008R2|Srv2012R2], there
isn't BSODs and guests boot just fine. In cases guest doesn't support
cpu-hotplug, cpu becomes visible after reboot and in case the guest
supports cpu-hotplug, it works as expected with this patch.
Cc: qemu-stable@nongnu.org
Signed-off-by: huangzhichao <huangzhichao@huawei.com>
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-By: Igor Mammedov <imammedo@redhat.com>
Expose Intel IOMMU to the BIOS. If object of TYPE_INTEL_IOMMU_DEVICE exists,
add DMAR table to ACPI RSDT table. For now the DMAR table indicates that there
is only one hardware unit without INTR_REMAP capability on the platform.
Signed-off-by: Le Tan <tamlokveer@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
RSDP should be aligned at a 16-byte boundary.
This would by chance at the moment, fix up acpi build
to make it robust.
Cc: qemu-stable@nongnu.org
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
- Tweak error message for legacy machine type:
Basically if table size exceeds the limits we set all
bets are off for migration: e.g. it can start failing even
within given qemu minor version simply because of a bugfix.
- Increase table size to 128k.
- Make sure we notice it long before we start getting close to the
128k limit: warn at 64k.
- Don't fail if we exceed the limit: most people don't care about
migration, even less people care about cross version miration.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
This patch avoids that similar changes break QEMU again in the future.
QEMU will now hard-code 64k as the maximum ACPI table size, which
(despite being an order of magnitude smaller than 640k) should be enough
for everyone.
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>
Fixes migration regression from QEMU-1.7 to a newer QEMUs.
SSDT table size in QEMU-1.7 doesn't change regardless of
a number of PCI bridge devices present at startup.
However in QEMU-2.0 since addition of hotplug on PCI bridges,
each PCI bridge adds ~1875 bytes to SSDT table, including
pc-i440fx-1.7 machine type where PCI bridge hotplug disabled
via compat property.
It breaks migration from "QEMU-1.7" to "QEMU-2.[01] -M pc-i440fx-1.7"
since RAMBlock size of ACPI tables on target becomes larger
then on source and migration fails with:
"Length mismatch: /rom@etc/acpi/tables: 2000 in != 3000"
error.
Fix this by generating AML only for PCI0 bus if
hotplug on PCI bridges is disabled and preserves PCI brigde
description in AML as it was done in QEMU-1.7 for pc-i440fx-1.7.
It will help to maintain size of SSDT static regardless of
number of PCI bridges on startup for pc-i440fx-1.7 machine type.
Signed-off-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>
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>
Needed for Windows to use hotplugged memory device, otherwise
it complains that server is not configured for memory hotplug.
Tests shows that aftewards it uses dynamically provided
proximity value from _PXM() method if available.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Acked-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
- provides static SSDT object for memory hotplug that can handle
upto 256 hotplugable memory slots
- SSDT template for memory devices and runtime generator
of them in SSDT table.
Signed-off-by: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Acked-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
replace magic numbers with enum describing Flags field of
memory affinity in SRAT table.
MemoryAffinityFlags enum will define flags decribed by:
ACPI spec 5.0, "5.2.16.2 Memory Affinity Structure",
"Table 5-69 Flags - Memory Affinity Structure"
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Acked-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
After previous Peter patch, they are redundant. This way we don't
assign them except when needed. Once there, there were lots of case
where the ".fields" indentation was wrong:
.fields = (VMStateField []) {
and
.fields = (VMStateField []) {
Change all the combinations to:
.fields = (VMStateField[]){
The biggest problem (appart from aesthetics) was that checkpatch complained
when we copy&pasted the code from one place to another.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Acked-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
acpi build tried to add offset of hpet table to rsdt even when hpet was
disabled. If no tables follow hpet, this could lead to a malformed
rsdt.
Fix it up.
To avoid such errors in the future, rearrange code slightly to make it
clear that acpi_add_table stores the offset of the following table - not
of the previous one.
Reported-by: TeLeMan <geleman@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Cc: qemu-stable@nongnu.org
Object returned by object_property_get_qobject needs its reference counter to
be decremented when it is not needed by caller anymore.
Signed-off-by: Kirill Batuzov <batuzovk@ispras.ru>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Fix typo in build_append_int() which causes integer
truncation when it's in range 0x{F-1}FFFF by packing it
as WordConst instead of required DWordConst.
In partucular this fixes a regression: hotplug in slots 16,17,18 and 19
didn't work, since SSDT had code like this:
If (And (Arg0, 0x0000))
{
Notify (S80, Arg1)
}
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Stefan Weil <sw@weilnetz.de>
Here are some bugfixes for 2.0.
A bugfix for acpi for pci bridges, and a build fix for
old systems without pthread_setname_np: both fix regressions
so we definitely want to include them.
HPET fix is not for a regression but looks very safe,
fixes a nasty bug and has been on list for a while.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJTNWRMAAoJECgfDbjSjVRp6CoH/A3iLi+jkV4EhQQzU8U6vOmi
PIV71600rZd29u4hk6w5pyev6yyXSBwatmWk+vzHvINUIcc22KUue+773nXPW/fH
3oIgTwjKndE98V5vTSeOgOdD7iFuWlcgHQHLXXMsgpY1hVMS/1kidZdb+36o8euI
kdE+AxYGXS8Z3oBRFfROpT4v0UZ17qIaL4tqA4JJWMh/A3Qp3HY+ffU3ODAvKSQw
KWVWmKvbh82I25HOvALoMwtu26x48jhzu586pHBuEsHgTJKKBrAUdWph+2f1eSC+
xTgduKWEgK6Z9dCYDQwDaM8CqNzjqVzfgRu0RCSHtgTxCWaIN3dQbxEFi7WQ2Yo=
=dfqJ
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
acpi,pc,build bug fixes
Here are some bugfixes for 2.0.
A bugfix for acpi for pci bridges, and a build fix for
old systems without pthread_setname_np: both fix regressions
so we definitely want to include them.
HPET fix is not for a regression but looks very safe,
fixes a nasty bug and has been on list for a while.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# gpg: Signature made Fri 28 Mar 2014 12:00:12 GMT using RSA key ID D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>"
# gpg: aka "Michael S. Tsirkin <mst@redhat.com>"
* remotes/mst/tags/for_upstream:
acpi: fix ACPI generation for pci bridges
Don't enable a HPET timer if HPET is disabled
Detect pthread_setname_np at configure time
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Commit 8dcf525abc
acpi-build: append description for non-hotplug
appended description for all occupied non hotpluggable PCI slots.
However the bridge devices are already added to SSDT,
adding them again will create an incorrect SSDT table.
Fixed by skipping the pci bridge devices, marking them as 'system'.
Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Add U suffix to avoid undefined behaviour.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The ACPI specification says:
The ASL compiler can emit two different AML opcodes for a Package
declaration, either PackageOp or VarPackageOp. For small, fixed-length
packages, the PackageOp is used and this opcode is compatible with ACPI
1.0. A VarPackageOp will be emitted if any of the following conditions
are true:
. The NumElements argument is a TermArg that can only be resolved at
runtime.
. At compile time, NumElements resolves to a constant that is larger than
255.
. The PackageList contains more than 255 initializer elements.
Note: The ability to create variable-sized packages was first introduced
in ACPI 2.0. ACPI 1.0 only allowed fixed-size packages with up to 255 elements.
So the spec seems to say a fixed value up to 255 must always
be used with PackageOp and not VarPackageOp, and some guests
(windows up to win2k8) seem to interpret it like this.
Let's do just this, choosing the encoding depending on
the number of elements.
Fixes 9bcc80cd71
(i386/acpi-build: allow more than 255 elements in CPON).
https://bugs.launchpad.net/bugs/1297651
Reported-by: Robert Hu <robert.hu@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
when using signature for table ID, we forgot to byte-swap it.
signatures are really ASCII strings, let's treat them as such.
While at it, get rid of most of _SIGNATURE macros.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Building on the previous patch, raise the maximal count of processor
objects / NTFY branches / CPON elements from 255 to 256. This allows the
VCPU with APIC ID 0xFF to be hotplugged.
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>
The build_ssdt() function builds a number of AML objects that are related
to CPU hotplug, and whose IDs form a contiguous sequence of APIC IDs.
(APIC IDs are in fact discontiguous, but this is the traditional
interface: build a contiguous sequence from zero up that covers all
possible APIC IDs.) These objects are:
- a Processor() object for each VCPU,
- a NTFY method, with one branch for each VCPU,
- a CPON package with one element (hotplug status byte) for each VCPU.
The build_ssdt() function currently limits the *count* of processor
objects, and NTFY branches, and CPON elements, in 0xFF (see the assignment
to "acpi_cpus"). This allows for an inclusive APIC ID range of [0..254].
This is incorrect, because the highest APIC ID that we otherwise allow a
VCPU to take is 255.
In order to extend the maximum count to 256, and the traversed APIC ID
range correspondingly to [0..255]:
- the Processor() objects need no change,
- the NTFY method also needs no change,
- the CPON package must be updated, because it is defined with a
DefPackage, and the number of elements in such a package can be at most
255. We pick a DefVarPackage instead.
We replace the Op byte, and the encoding of the number of elements.
Compare:
DefPackage := PackageOp PkgLength NumElements PackageElementList
DefVarPackage := VarPackageOp PkgLength VarNumElements PackageElementList
PackageOp := 0x12
VarPackageOp := 0x13
NumElements := ByteData
VarNumElements := TermArg => Integer
The build_append_int() function implements precisely the following TermArg
encodings (a subset of what the ACPI spec describes):
TermArg := DataObject
DataObject := ComputationalData
ComputationalData := ConstObj | ByteConst | WordConst | DWordConst
directly encoded in the function, with build_append_byte():
ConstObj := ZeroOp | OneOp
ZeroOp := 0x00
OneOp := 0x01
call to build_append_value(..., 1):
ByteConst := BytePrefix ByteData
BytePrefix := 0x0A
ByteData := 0x00 - 0xFF
call to build_append_value(..., 2):
WordConst := WordPrefix WordData
WordPrefix := 0x0B
WordData := ByteData[0:7] ByteData[8:15]
call to build_append_value(..., 4):
DWordConst := DWordPrefix DWordData
DWordPrefix := 0x0C
DWordData := WordData[0:15] WordData[16:31]
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>
MAX_CPUMASK_BITS is a limit for max_cpus and CPU indexes, not for APIC
IDs.
ACPI_CPU_HOTPLUG_ID_LIMIT is the right macro for the limit on APIC IDs
on the ACPI and CPU hotplug code.
There are no functional changes introduced by this patch, as
MAX_CPUMASK_BITS + 1 == 255 + 1 == 256 == ACPI_CPU_HOTPLUG_ID_LIMIT.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
casting an unaligned address to e.g.
uint32_t can trigger undefined behaviour in C.
Replace cast + assignment with memcpy.
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
As reported in
http://article.gmane.org/gmane.comp.emulators.qemu/253987
Mac OSX actually requires describing all occupied slots
in ACPI - even if hotplug isn't enabled.
I didn't expect this so I dropped description of all
non hotpluggable slots from ACPI.
As a result: before
commit 99fd437dee (enable
hotplug for pci bridges), PCI cards show up in the "device tree" of OS X
(System Information). E.g., on MountainLion users have:
Hardware -> PCI Cards:
Card Type Driver Installed Slot
*ethernet Ethernet Controller Yes PCI Slot 2
pci8086,2934 USB UHC Yes PCI Slot 29
ethernet:
Type: Ethernet Controller
Driver Installed: Yes
MSI: No
Bus: PCI
Slot PCI Slot 2
Vendor ID: 0x8086
Device ID: 0x100e
Subsystem Vendor ID: 0x1af4
Subsystem ID: 0x1100
Revision ID: 0x0003
Hardware -> Ethernet Cards
ethernet:
Type: Ethernet Controller
Bus: PCI
Slot PCI Slot 2
Vendor ID: 0x8086
Device ID: 0x100e
Subsystem Vendor ID: 0x1af4
Subsystem ID: 0x1100
Revision ID: 0x0003
BSD name: en0
Kext name: AppleIntel8254XEthernet.kext
Location: /System/Library/Extensions/...
Version: 3.1.1b1
After commit 99fd437dee, users get:
Hardware -> PCI Cards:
This computer doesn't contain any PCI cards. If you installed PCI
cards, make sure they're properly installed.
Hardware -> Ethernet Cards
ethernet:
Type: Ethernet Controller
Bus: PCI
Vendor ID: 0x8086
Device ID: 0x100e
Subsystem Vendor ID: 0x1af4
Subsystem ID: 0x1100
Revision ID: 0x0003
BSD name: en0
Kext name: AppleIntel8254XEthernet.kext
Location: /System/Library/Extensions/...
Version: 3.1.1b1
Ethernet still works, but it's not showing up on the PCI bus, and it
no longer thinks it's plugged in to slot #2, as it used to before the
change.
To fix, append description for all occupied non hotpluggable PCI slots.
One need to be careful when doing this: VGA devices
are now described in SSDT, so we need to drop description from DSDT.
And ISA devices are used in DSDT so drop them from SSDT.
Reported-by: Gabriel L. Somlo <gsomlo@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Also update generated dsdt and pcihp hex dump files.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Get rid of PCIDevice specific PCIDeviceClass.no_hotplug and use
generic DeviceClass.hotpluggable field instead.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The original SeaBIOS code used the RamSize variable, that was used by
SeaBIOS for the size of RAM below 4GB, not for all RAM. When copied to
QEMU, the code was changed to use the full RAM size, and this broke the
build_srat() code that handles the PCI hole.
Change build_srat() to use ram_size_below_4g instead of ram_size, to
restore the original behavior from SeaBIOS.
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>
This enables support for device hotplug behind
pci bridges. Bridge devices themselves need
to be pre-configured on qemu command line.
Design:
- at machine init time, assign "bsel" property to bridges with
hotplug support
- dynamically (At ACPI table read) generate ACPI code to handle
hotplug events for each bridge with "bsel" property
Note: ACPI doesn't support adding or removing bridges by hotplug.
We detect and prevent removal of bridges by hotplug,
unless they were added by hotplug previously
(and so, are not described by ACPI).
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Minimize the storage used for AppleSMC's _STA (8bit), relying on ASL
to implicitly convert it to the officially specified 32bit value.
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
AppleSMC (-device isa-applesmc) is required to boot OS X guests.
OS X expects a SMC node to be present in the ACPI DSDT. This patch
adds a SMC node to the DSDT, and dynamically patches the return value
of SMC._STA to either 0x0B if the chip is present, or otherwise to 0x00,
before booting the guest.
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
IASL stores it's revision in each table header it generates.
That's not nice since guests will see a change each time they move
between hypervisors. We generally fill our own info for tables, but we
(and seabios) forgot to do this for the built-in DSDT.
Modifications in DSDT table:
OEM ID: "BXPC" -> "BOCHS "
OEM Table ID: "BXDSDT" -> "BXPCDSDT"
Compiler ID: "INTL" -> "BXPC"
Compiler Version: 0x20130823 -> 0x00000001
Tested-by: Marcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
gcc 4.8.2 reports this warning when extra warnings are enabled (-Wextra):
CC m68k-softmmu/hw/m68k/mcf5206.o
hw/i386/acpi-build.c: In function ‘build_append_nameseg’:
hw/i386/acpi-build.c:294:5: error:
function might be possible candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format]
g_string_vprintf(s, format, args);
^
When this warning is fixed, there is a new compiler warning:
CC i386-softmmu/hw/i386/acpi-build.o
hw/i386/acpi-build.c: In function ‘build_append_notify’:
hw/i386/acpi-build.c:632:5: error:
format not a string literal and no format arguments [-Werror=format-security]
build_append_nameseg(method, name);
^
This is fixed here, too.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
glib < 2.22 does not have g_array_get_element_size,
limit it's use (to check all elements are 1 byte
in size) to newer glib.
This fixes build on RHEL 5.3.
Reported-by: Richard Henderson <rth@redhat.com>
Reported-by: Erik Rull <erik.rull@rdsoftware.de>
Tested-by: Richard Henderson <rth@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-id: 20131125220039.GA16386@redhat.com
Signed-off-by: Anthony Liguori <aliguori@amazon.com>
g_array_get_element_size was only added in glib 2.14.
Fortunately we don't use it for any arrays where
element size is > 1, so just add an assert.
Reported-by: Richard Henderson <rth@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1385036128-8753-2-git-send-email-mst@redhat.com
Signed-off-by: Anthony Liguori <aliguori@amazon.com>
g_string_vprintf was only introduced in 2.24 so switch to vsnprintf
instead. A bit uglier but name size is fixed at 4 bytes here so it's
easy.
Reported-by: Richard Henderson <rth@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1385036128-8753-1-git-send-email-mst@redhat.com
Signed-off-by: Anthony Liguori <aliguori@amazon.com>
QEMU will currently crash if started with -no-acpi flag
since acpi build code probes the PM device which isn't present
in this configuration.
To fix, don't expose ACPI tables to guest when acpi has been
disabled from command line.
Fixes LP# 1248854
https://bugs.launchpad.net/qemu/+bug/1248854
Reported-by: chao zhou <chao.zhou@intel.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
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>
