On 01/16/2012 01:32 PM, Vasilis Liaskovitis wrote:
On Sun, Jan 15, 2012 at 02:38:52PM +0200, Avi Kivity wrote:
On 01/13/2012 01:11 PM, Vasilis Liaskovitis wrote:
Signed-off-by: Vasilis Liaskovitis vasilis.liaskovitis@profitbricks.com
hw/acpi_piix4.c | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c index d5743b6..8bf30dd 100644 --- a/hw/acpi_piix4.c +++ b/hw/acpi_piix4.c @@ -37,6 +37,7 @@
#define GPE_BASE 0xafe0 #define PROC_BASE 0xaf00 +#define PROC_EJ_BASE 0xaf20
We're adding stuff to piix4 which was never there. At a minimum this needs to be documented. Also needs to be -M pc-1.1 and later only.
Where should this be documented? PCI/ACPI hotplug addresses are documented in docs/specs/acpi_pci_hotplug.txt
A pleasant surprise
but for CPU hotplug documentation (i.e. for the existing PROC_BASE) I don't see relevant documentation. I will create a docs/specs/acpi_cpu_hotplug.txt if that sounds reasonable.
I suggest renaming it to acpi_hotplug.txt, so it covers both cases.
For pc-1.1, a new QEMUmachine type will be needed I assume. Should a check be made against the machine version in the piix4 code? any relevant examples?
The standard practice is to set a property. See for example pc_machine_v0_14 in hw/pc_piix.c, it autosets properties for devices (erroneously called "drivers" in the code).
btw, I notice the I/O ports are write only and don't remember their state. I can't think offhand if there's anything bad about it (in fact not having state makes live migration more robust), but perhaps someone else will.
-
Avi Kivity