[Qemu-devel] [PATCH v2 0/4] acpi_piix4: Add CPU eject infrastructure for pc-1.1

[Qemu-devel] [PATCH v2 0/4] acpi_piix4: Add CPU eject infrastructure for pc-1.1

[Vasilis Liaskovitis]

This patch series adds support for CPU ejection callbacks in Seabios and qemu.
This will be needed for proper ACPI vcpu destruction/unplug in conjunction
with the vcpu lifecycle patches. 

v1->v2: Add pc-1.1 model with cpu acpi ejection property. Add documentation.
v1 of the series also defined the eject method to handle the CPU_DEAD event
in the cpu lifecycle/destruction series. That patch has been dropped from the
patchset and will be sent separately as lifecycle/unplug series matures.

v2 patches are based on uq/master, plus a patch from the first version of
vcpu-hotplug qemu upstream series, specifically:
http://patchwork.ozlabs.org/patch/136463/

Vasilis Liaskovitis (3):
  uq/master: Add machine model pc-1.1
  uq/master: Add CPU eject handling for acpi_piix4
  uq/master: Add acpi cpu interface documentation

 docs/specs/acpi_hotplug.txt     |   49 +++++++++++++++++++++++++++++++++++++++
 docs/specs/acpi_pci_hotplug.txt |   37 -----------------------------
 hw/acpi_piix4.c                 |   20 ++++++++++++++++
 hw/pc_piix.c                    |   16 ++++++++++++
 4 files changed, 85 insertions(+), 37 deletions(-)
 create mode 100644 docs/specs/acpi_hotplug.txt
 delete mode 100644 docs/specs/acpi_pci_hotplug.txt

-- 
1.7.7.3

[Qemu-devel] [PATCH v2 1/4][SeaBios] Add bitmap for CPU EJ0 callback

[Vasilis Liaskovitis]

Add bitmap for CPU EJ0 callback and write to it on a cpu _EJ0 callback. Remove
Sleep() call.

Signed-off-by: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>
---
 src/acpi-dsdt.dsl |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl
index 7082b65..5138c2a 100644
--- a/src/acpi-dsdt.dsl
+++ b/src/acpi-dsdt.dsl
@@ -650,9 +650,15 @@ DefinitionBlock (
             Store(DerefOf(Index(CPON, Arg0)), Local0)
             If (Local0) { Return(0xF) } Else { Return(0x0) }
         }
+        /* CPU eject notify method */
+        OperationRegion(PREJ, SystemIO, 0xaf20, 32)
+        Field (PREJ, ByteAcc, NoLock, Preserve)
+        {
+            PRE, 256
+        }
         Method (CPEJ, 2, NotSerialized) {
             // _EJ0 method - eject callback
-            Sleep(200)
+            Store(ShiftLeft(1, Arg0), PRE)
         }
 
         /* CPU hotplug notify method */
-- 
1.7.7.3

[Qemu-devel] [PATCH 2/4] uq/master: Add machine model pc-1.1

[Vasilis Liaskovitis]

Add machine model pc-1.1 

Signed-off-by: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>
---
 hw/pc_piix.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 744b0dc..ac251c6 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -375,6 +375,13 @@ static void pc_xen_hvm_init(ram_addr_t ram_size,
 }
 #endif
 
+static QEMUMachine pc_machine_v1_1 = {
+    .name = "pc-1.1",
+    .desc = "Standard PC",
+    .init = pc_init_pci,
+    .max_cpus = 255,
+};
+
 static QEMUMachine pc_machine_v1_0 = {
     .name = "pc-1.0",
     .alias = "pc",
@@ -674,6 +681,7 @@ static QEMUMachine xenfv_machine = {
 
 static void pc_machine_init(void)
 {
+    qemu_register_machine(&pc_machine_v1_1);
     qemu_register_machine(&pc_machine_v1_0);
     qemu_register_machine(&pc_machine_v0_15);
     qemu_register_machine(&pc_machine_v0_14);
-- 
1.7.7.3

[Qemu-devel] [PATCH v2 3/4] uq/master: Add CPU eject handling for acpi_piix4

[Vasilis Liaskovitis]

Add stub functions for CPU eject callback. Define cpu_acpi_eject property and
enable eject callback only for pc-1.1 machine model.

Signed-off-by: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>
---
 hw/acpi_piix4.c |   20 ++++++++++++++++++++
 hw/pc_piix.c    |    8 ++++++++
 2 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
index 96e1ce8..8475aa6 100644
--- a/hw/acpi_piix4.c
+++ b/hw/acpi_piix4.c
@@ -40,6 +40,7 @@
 
 #define GPE_BASE 0xafe0
 #define PROC_BASE 0xaf00
+#define PROC_EJ_BASE 0xaf20
 #define GPE_LEN 4
 #define PCI_BASE 0xae00
 #define PCI_EJ_BASE 0xae08
@@ -80,6 +81,8 @@ typedef struct PIIX4PMState {
     struct gpe_regs gpe_cpu;
     struct pci_status pci0_status;
     uint32_t pci0_hotplug_enable;
+    /* for cpu hotplug */
+    uint32_t cpu_acpi_eject;
 } PIIX4PMState;
 
 static void piix4_acpi_system_hot_add_init(PCIBus *bus, PIIX4PMState *s);
@@ -424,6 +427,7 @@ static PCIDeviceInfo piix4_pm_info = {
     .class_id           = PCI_CLASS_BRIDGE_OTHER,
     .qdev.props         = (Property[]) {
         DEFINE_PROP_UINT32("smb_io_base", PIIX4PMState, smb_io_base, 0),
+        DEFINE_PROP_UINT32("cpu_acpi_eject", PIIX4PMState, cpu_acpi_eject, 0),
         DEFINE_PROP_END_OF_LIST(),
     }
 };
@@ -497,6 +501,17 @@ static void pcihotplug_write(void *opaque, uint32_t addr, uint32_t val)
     PIIX4_DPRINTF("pcihotplug write %x <== %d\n", addr, val);
 }
 
+static uint32_t cpuej_read(void *opaque, uint32_t addr)
+{
+    PIIX4_DPRINTF("cpuej read %x\n", addr);
+    return 0;
+}
+
+static void cpuej_write(void *opaque, uint32_t addr, uint32_t val)
+{
+    PIIX4_DPRINTF("cpuej write %x <== %d\n", addr, val);
+}
+
 static uint32_t pciej_read(void *opaque, uint32_t addr)
 {
     PIIX4_DPRINTF("pciej read %x\n", addr);
@@ -555,6 +570,11 @@ static void piix4_acpi_system_hot_add_init(PCIBus *bus, PIIX4PMState *s)
     register_ioport_write(PROC_BASE, 32, 1, gpe_writeb, s);
     register_ioport_read(PROC_BASE, 32, 1,  gpe_readb, s);
 
+    if (s->cpu_acpi_eject) {
+        register_ioport_write(PROC_EJ_BASE, 32, 1, cpuej_write, s);
+        register_ioport_read(PROC_EJ_BASE, 32, 1,  cpuej_read, s);
+    }
+
     register_ioport_write(PCI_BASE, 8, 4, pcihotplug_write, pci0_status);
     register_ioport_read(PCI_BASE, 8, 4,  pcihotplug_read, pci0_status);
 
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index ac251c6..6d61567 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -380,6 +380,14 @@ static QEMUMachine pc_machine_v1_1 = {
     .desc = "Standard PC",
     .init = pc_init_pci,
     .max_cpus = 255,
+    .compat_props = (GlobalProperty[]) {
+        {
+            .driver   = "PIIX4_PM",
+            .property = "cpu_acpi_eject",
+            .value    = stringify(1),
+        },
+        { /* end of list */ }
+    },
 };
 
 static QEMUMachine pc_machine_v1_0 = {
-- 
1.7.7.3

Re: [Qemu-devel] [PATCH v2 3/4] uq/master: Add CPU eject handling for acpi_piix4

[Jan Kiszka]

On 2012-01-24 11:10, Vasilis Liaskovitis wrote:
> Add stub functions for CPU eject callback. Define cpu_acpi_eject property and
> enable eject callback only for pc-1.1 machine model.

Just to get the idea: What is the plan and advantage of introducing a
stub first? How much more is required to have some usable feature, even
if its just a friction of the full support?

> 
> Signed-off-by: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>
> ---
>  hw/acpi_piix4.c |   20 ++++++++++++++++++++
>  hw/pc_piix.c    |    8 ++++++++
>  2 files changed, 28 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
> index 96e1ce8..8475aa6 100644
> --- a/hw/acpi_piix4.c
> +++ b/hw/acpi_piix4.c
> @@ -40,6 +40,7 @@
>  
>  #define GPE_BASE 0xafe0
>  #define PROC_BASE 0xaf00
> +#define PROC_EJ_BASE 0xaf20
>  #define GPE_LEN 4
>  #define PCI_BASE 0xae00
>  #define PCI_EJ_BASE 0xae08
> @@ -80,6 +81,8 @@ typedef struct PIIX4PMState {
>      struct gpe_regs gpe_cpu;
>      struct pci_status pci0_status;
>      uint32_t pci0_hotplug_enable;
> +    /* for cpu hotplug */
> +    uint32_t cpu_acpi_eject;
>  } PIIX4PMState;
>  
>  static void piix4_acpi_system_hot_add_init(PCIBus *bus, PIIX4PMState *s);
> @@ -424,6 +427,7 @@ static PCIDeviceInfo piix4_pm_info = {
>      .class_id           = PCI_CLASS_BRIDGE_OTHER,
>      .qdev.props         = (Property[]) {
>          DEFINE_PROP_UINT32("smb_io_base", PIIX4PMState, smb_io_base, 0),
> +        DEFINE_PROP_UINT32("cpu_acpi_eject", PIIX4PMState, cpu_acpi_eject, 0),
>          DEFINE_PROP_END_OF_LIST(),
>      }
>  };
> @@ -497,6 +501,17 @@ static void pcihotplug_write(void *opaque, uint32_t addr, uint32_t val)
>      PIIX4_DPRINTF("pcihotplug write %x <== %d\n", addr, val);
>  }
>  
> +static uint32_t cpuej_read(void *opaque, uint32_t addr)
> +{
> +    PIIX4_DPRINTF("cpuej read %x\n", addr);
> +    return 0;
> +}
> +
> +static void cpuej_write(void *opaque, uint32_t addr, uint32_t val)
> +{
> +    PIIX4_DPRINTF("cpuej write %x <== %d\n", addr, val);
> +}
> +
>  static uint32_t pciej_read(void *opaque, uint32_t addr)
>  {
>      PIIX4_DPRINTF("pciej read %x\n", addr);
> @@ -555,6 +570,11 @@ static void piix4_acpi_system_hot_add_init(PCIBus *bus, PIIX4PMState *s)
>      register_ioport_write(PROC_BASE, 32, 1, gpe_writeb, s);
>      register_ioport_read(PROC_BASE, 32, 1,  gpe_readb, s);
>  
> +    if (s->cpu_acpi_eject) {
> +        register_ioport_write(PROC_EJ_BASE, 32, 1, cpuej_write, s);
> +        register_ioport_read(PROC_EJ_BASE, 32, 1,  cpuej_read, s);
> +    }
> +
>      register_ioport_write(PCI_BASE, 8, 4, pcihotplug_write, pci0_status);
>      register_ioport_read(PCI_BASE, 8, 4,  pcihotplug_read, pci0_status);
>  
> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index ac251c6..6d61567 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -380,6 +380,14 @@ static QEMUMachine pc_machine_v1_1 = {
>      .desc = "Standard PC",
>      .init = pc_init_pci,
>      .max_cpus = 255,
> +    .compat_props = (GlobalProperty[]) {
> +        {
> +            .driver   = "PIIX4_PM",
> +            .property = "cpu_acpi_eject",
> +            .value    = stringify(1),

Such things are usually handled the other way around: define
no_cpu_acpi_eject and set it in all legacy machines.

> +        },
> +        { /* end of list */ }
> +    },
>  };
>  
>  static QEMUMachine pc_machine_v1_0 = {

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH v2 3/4] uq/master: Add CPU eject handling for acpi_piix4

[Andreas Färber]

Am 24.01.2012 11:28, schrieb Jan Kiszka:
> On 2012-01-24 11:10, Vasilis Liaskovitis wrote:
>> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
>> index ac251c6..6d61567 100644
>> --- a/hw/pc_piix.c
>> +++ b/hw/pc_piix.c
>> @@ -380,6 +380,14 @@ static QEMUMachine pc_machine_v1_1 = {
>>      .desc = "Standard PC",
>>      .init = pc_init_pci,
>>      .max_cpus = 255,
>> +    .compat_props = (GlobalProperty[]) {
>> +        {
>> +            .driver   = "PIIX4_PM",
>> +            .property = "cpu_acpi_eject",
>> +            .value    = stringify(1),
> 
> Such things are usually handled the other way around: define
> no_cpu_acpi_eject and set it in all legacy machines.

Either way reminds me that qdev bool support never got merged. I'll dig
it out and rebase.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH v2 3/4] uq/master: Add CPU eject handling for acpi_piix4

[Jan Kiszka]

On 2012-01-24 13:52, Andreas Färber wrote:
> Am 24.01.2012 11:28, schrieb Jan Kiszka:
>> On 2012-01-24 11:10, Vasilis Liaskovitis wrote:
>>> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
>>> index ac251c6..6d61567 100644
>>> --- a/hw/pc_piix.c
>>> +++ b/hw/pc_piix.c
>>> @@ -380,6 +380,14 @@ static QEMUMachine pc_machine_v1_1 = {
>>>      .desc = "Standard PC",
>>>      .init = pc_init_pci,
>>>      .max_cpus = 255,
>>> +    .compat_props = (GlobalProperty[]) {
>>> +        {
>>> +            .driver   = "PIIX4_PM",
>>> +            .property = "cpu_acpi_eject",
>>> +            .value    = stringify(1),
>>
>> Such things are usually handled the other way around: define
>> no_cpu_acpi_eject and set it in all legacy machines.
> 
> Either way reminds me that qdev bool support never got merged. I'll dig
> it out and rebase.

Perfect! I really hate to model bool via bit.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH v2 3/4] uq/master: Add CPU eject handling for acpi_piix4

[Vasilis Liaskovitis]

On Tue, Jan 24, 2012 at 11:28:41AM +0100, Jan Kiszka wrote:
> On 2012-01-24 11:10, Vasilis Liaskovitis wrote:
> > Add stub functions for CPU eject callback. Define cpu_acpi_eject property and
> > enable eject callback only for pc-1.1 machine model.
> 
> Just to get the idea: What is the plan and advantage of introducing a
> stub first? How much more is required to have some usable feature, even
> if its just a friction of the full support?
>
There's not really an advantage to adding stubs first. The plan depends on the
lifecycle patches getting accepted in some form at some point. The code is all
out there, and some of it has been reviewed/commented on, but not accepted.

kvm needs the following patches:
https://lkml.org/lkml/2012/1/6/355 (v7, still in work)
http://patchwork.ozlabs.org/patch/127828/
This second patch introduces ioctl KVM_SETSTATE_VCPU, (qemu uses it to signal
vcpu destruction to the host) but the review mentions there should be a
simpler way. It's unclear to me whether this ioctl is desired or not.

userspace qemu/qemu-kvm need some form of these patches
http://patchwork.ozlabs.org/patch/127831/
http://patchwork.ozlabs.org/patch/127830/
http://patchwork.ozlabs.org/patch/127833/
http://patchwork.ozlabs.org/patch/127834/

Assuming that the above is further reviewed and accepted, the extra code
needed to actually make something useful in the stub functions would be something
like the following (with the above ioctl), comments welcome. This code calls
kvm function from hw/acpi_piix4.c so it's probably not well abstracted enough
for upstream.

diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
index 8475aa6..b5fcb4a 100644
--- a/hw/acpi_piix4.c
+++ b/hw/acpi_piix4.c
@@ -509,6 +509,20 @@ static uint32_t cpuej_read(void *opaque, uint32_t addr)
 
 static void cpuej_write(void *opaque, uint32_t addr, uint32_t val)
 {
+    PIIX4PMState *s = opaque;
+    CPUState *env;
+    int cpu;
+    int ret;
+
+    cpu = ffs(val);
+    /* zero means no bit was set, i.e. no CPU ejection happened */
+    if (!cpu)
+       return;
+    cpu--;
+    env = cpu_phyid_to_cpu((uint64_t)cpu);
+    if (s->kvm_enabled && env != NULL) {
+        kvm_eject_vcpu(env);
+    }
     PIIX4_DPRINTF("cpuej write %x <== %d\n", addr, val);
 }
 
diff --git a/kvm-all.c b/kvm-all.c
index 88f1156..d3e53f5 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -193,6 +193,13 @@ static void kvm_reset_vcpu(void *opaque)
     kvm_arch_reset_vcpu(env);
 }
 
+static void kvm_eject_vcpu(void *opaque)
+{
+    CPUState *env = opaque;
+
+    kvm_arch_eject_vcpu(env);
+}
+
 int kvm_irqchip_in_kernel(void)
 {
     return kvm_state->irqchip_in_kernel;
diff --git a/kvm.h b/kvm.h
index 40b5ffc..ace28a8 100644
--- a/kvm.h
+++ b/kvm.h
@@ -125,6 +125,8 @@ int kvm_arch_init_vcpu(CPUState *env);
 
 void kvm_arch_reset_vcpu(CPUState *env);
 
+void kvm_arch_eject_vcpu(CPUState *env);
+
 int kvm_arch_on_sigbus_vcpu(CPUState *env, int code, void *addr);
 int kvm_arch_on_sigbus(int code, void *addr);
 
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index e41de39..f8239c0 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -589,6 +589,21 @@ void kvm_arch_reset_vcpu(CPUState *env)
     }
 }
 
+void kvm_arch_eject_vcpu(CPUState *env)
+{
+    struct kvm_vcpu_state state;
+    int ret = 0;
+
+    if (env->state == CPU_STATE_ZAPREQ) {
+        state.vcpu_id = env->cpu_index;
+        state.state = 1;
+        ret = kvm_vm_ioctl(env->kvm_state, KVM_SETSTATE_VCPU, &state);
+        if (ret)
+            fprintf(stderr, "KVM_SETSTATE_VCPU failed: %s\n",
+                    strerror(ret));
+    }
+}
+
 static int kvm_get_supported_msrs(KVMState *s)
 {
     static int kvm_supported_msrs;

Re: [Qemu-devel] [PATCH v2 3/4] uq/master: Add CPU eject handling for acpi_piix4

[Avi Kivity]

On 01/24/2012 04:56 PM, Vasilis Liaskovitis wrote:
> On Tue, Jan 24, 2012 at 11:28:41AM +0100, Jan Kiszka wrote:
> > On 2012-01-24 11:10, Vasilis Liaskovitis wrote:
> > > Add stub functions for CPU eject callback. Define cpu_acpi_eject property and
> > > enable eject callback only for pc-1.1 machine model.
> > 
> > Just to get the idea: What is the plan and advantage of introducing a
> > stub first? How much more is required to have some usable feature, even
> > if its just a friction of the full support?
> >
> There's not really an advantage to adding stubs first. The plan depends on the
> lifecycle patches getting accepted in some form at some point. The code is all
> out there, and some of it has been reviewed/commented on, but not accepted.
>
> kvm needs the following patches:
> https://lkml.org/lkml/2012/1/6/355 (v7, still in work)
> http://patchwork.ozlabs.org/patch/127828/
> This second patch introduces ioctl KVM_SETSTATE_VCPU, (qemu uses it to signal
> vcpu destruction to the host) but the review mentions there should be a
> simpler way. It's unclear to me whether this ioctl is desired or not.

Those patches are not strictly needed.  On a kernel that doesn't have
them, you can simply park the vcpu thread in userspace until it is
re-added.  I suggest writing the qemu patches without the assumption
that you're running on a 3.4+ kernel.


-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH v2 3/4] uq/master: Add CPU eject handling for acpi_piix4

[Vasilis Liaskovitis]

On Thu, Jan 26, 2012 at 12:46:18PM +0200, Avi Kivity wrote:
> On 01/24/2012 04:56 PM, Vasilis Liaskovitis wrote:
> > On Tue, Jan 24, 2012 at 11:28:41AM +0100, Jan Kiszka wrote:
> > > On 2012-01-24 11:10, Vasilis Liaskovitis wrote:
> > > > Add stub functions for CPU eject callback. Define cpu_acpi_eject property and
> > > > enable eject callback only for pc-1.1 machine model.
> > > 
> > > Just to get the idea: What is the plan and advantage of introducing a
> > > stub first? How much more is required to have some usable feature, even
> > > if its just a friction of the full support?
> > >
> > There's not really an advantage to adding stubs first. The plan depends on the
> > lifecycle patches getting accepted in some form at some point. The code is all
> > out there, and some of it has been reviewed/commented on, but not accepted.
> >
> > kvm needs the following patches:
> > https://lkml.org/lkml/2012/1/6/355 (v7, still in work)
> > http://patchwork.ozlabs.org/patch/127828/
> > This second patch introduces ioctl KVM_SETSTATE_VCPU, (qemu uses it to signal
> > vcpu destruction to the host) but the review mentions there should be a
> > simpler way. It's unclear to me whether this ioctl is desired or not.
> 
> Those patches are not strictly needed.  On a kernel that doesn't have
> them, you can simply park the vcpu thread in userspace until it is
> re-added.  I suggest writing the qemu patches without the assumption
> that you're running on a 3.4+ kernel.

ok, I will try to handle CPU ejection without relying on the lifecycle
patches.

thanks,

- Vasilis

[Qemu-devel] [PATCH 4/4] uq/master: Add acpi cpu interface documentation

[Vasilis Liaskovitis]

Add CPU acpi interface documentation. Move all ACPI documentation (CPU and
PCI) to one file.

Signed-off-by: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>
---
 docs/specs/acpi_hotplug.txt     |   49 +++++++++++++++++++++++++++++++++++++++
 docs/specs/acpi_pci_hotplug.txt |   37 -----------------------------
 2 files changed, 49 insertions(+), 37 deletions(-)
 create mode 100644 docs/specs/acpi_hotplug.txt
 delete mode 100644 docs/specs/acpi_pci_hotplug.txt

diff --git a/docs/specs/acpi_hotplug.txt b/docs/specs/acpi_hotplug.txt
new file mode 100644
index 0000000..2026bed
--- /dev/null
+++ b/docs/specs/acpi_hotplug.txt
@@ -0,0 +1,49 @@
+QEMU<->ACPI BIOS PCI hotplug interface
+--------------------------------------
+
+QEMU supports PCI hotplug via ACPI, for PCI bus 0. This document
+describes the interface between QEMU and the ACPI BIOS.
+
+ACPI GPE block (IO ports 0xafe0-0xafe3, byte access):
+-----------------------------------------
+
+Generic ACPI GPE block. Bit 1 (GPE.1) used to notify PCI hotplug/eject
+event to ACPI BIOS, via SCI interrupt.
+
+PCI slot injection notification pending (IO port 0xae00-0xae03, 4-byte access):
+---------------------------------------------------------------
+Slot injection notification pending. One bit per slot.
+
+Read by ACPI BIOS GPE.1 handler to notify OS of injection
+events.
+
+PCI slot removal notification (IO port 0xae04-0xae07, 4-byte access):
+-----------------------------------------------------
+Slot removal notification pending. One bit per slot.
+
+Read by ACPI BIOS GPE.1 handler to notify OS of removal
+events.
+
+PCI device eject (IO port 0xae08-0xae0b, 4-byte access):
+----------------------------------------
+
+Used by ACPI BIOS _EJ0 method to request device removal. One bit per slot.
+Reads return 0.
+
+PCI removability status (IO port 0xae0c-0xae0f, 4-byte access):
+-----------------------------------------------
+
+Used by ACPI BIOS _RMV method to indicate removability status to OS. One
+bit per slot.
+
+CPU hotplug notification pending (IO port 0xaf00-0xaf1f, 32-byte access):
+---------------------------------------------------------------
+CPU hotplug notification pending. One bit per cpu.
+
+Read by ACPI BIOS GPE.2 handler to notify OS of injection
+events.
+
+CPU eject (IO port 0xaf20-0xaf3f, 32-byte access):
+----------------------------------------
+
+Used by ACPI BIOS _EJ0 method to request cpu removal. One bit per cpu.
diff --git a/docs/specs/acpi_pci_hotplug.txt b/docs/specs/acpi_pci_hotplug.txt
deleted file mode 100644
index f0f74a7..0000000
--- a/docs/specs/acpi_pci_hotplug.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-QEMU<->ACPI BIOS PCI hotplug interface
---------------------------------------
-
-QEMU supports PCI hotplug via ACPI, for PCI bus 0. This document
-describes the interface between QEMU and the ACPI BIOS.
-
-ACPI GPE block (IO ports 0xafe0-0xafe3, byte access):
------------------------------------------
-
-Generic ACPI GPE block. Bit 1 (GPE.1) used to notify PCI hotplug/eject
-event to ACPI BIOS, via SCI interrupt.
-
-PCI slot injection notification pending (IO port 0xae00-0xae03, 4-byte access):
----------------------------------------------------------------
-Slot injection notification pending. One bit per slot.
-
-Read by ACPI BIOS GPE.1 handler to notify OS of injection
-events.
-
-PCI slot removal notification (IO port 0xae04-0xae07, 4-byte access):
------------------------------------------------------
-Slot removal notification pending. One bit per slot.
-
-Read by ACPI BIOS GPE.1 handler to notify OS of removal
-events.
-
-PCI device eject (IO port 0xae08-0xae0b, 4-byte access):
-----------------------------------------
-
-Used by ACPI BIOS _EJ0 method to request device removal. One bit per slot.
-Reads return 0.
-
-PCI removability status (IO port 0xae0c-0xae0f, 4-byte access):
------------------------------------------------
-
-Used by ACPI BIOS _RMV method to indicate removability status to OS. One
-bit per slot.
-- 
1.7.7.3