From: Jan Kiszka <jan.kiszka@siemens.com>
To: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>
Cc: "mtosatti@redhat.com" <mtosatti@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"gleb@redhat.com" <gleb@redhat.com>,
"seabios@seabios.org" <seabios@seabios.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"kernelfans@gmail.com" <kernelfans@gmail.com>,
"kevin@koconnor.net" <kevin@koconnor.net>,
"avi@redhat.com" <avi@redhat.com>
Subject: Re: [PATCH v2 3/4] uq/master: Add CPU eject handling for acpi_piix4
Date: Tue, 24 Jan 2012 11:28:41 +0100 [thread overview]
Message-ID: <4F1E87D9.6000008@siemens.com> (raw)
In-Reply-To: <1327399808-31081-4-git-send-email-vasilis.liaskovitis@profitbricks.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>
Cc: "mtosatti@redhat.com" <mtosatti@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"gleb@redhat.com" <gleb@redhat.com>,
"seabios@seabios.org" <seabios@seabios.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"kernelfans@gmail.com" <kernelfans@gmail.com>,
"kevin@koconnor.net" <kevin@koconnor.net>,
"avi@redhat.com" <avi@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 3/4] uq/master: Add CPU eject handling for acpi_piix4
Date: Tue, 24 Jan 2012 11:28:41 +0100 [thread overview]
Message-ID: <4F1E87D9.6000008@siemens.com> (raw)
In-Reply-To: <1327399808-31081-4-git-send-email-vasilis.liaskovitis@profitbricks.com>
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
next prev parent reply other threads:[~2012-01-24 10:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-24 10:10 [PATCH v2 0/4] acpi_piix4: Add CPU eject infrastructure for pc-1.1 Vasilis Liaskovitis
2012-01-24 10:10 ` [Qemu-devel] " Vasilis Liaskovitis
2012-01-24 10:10 ` [PATCH v2 1/4][SeaBios] Add bitmap for CPU EJ0 callback Vasilis Liaskovitis
2012-01-24 10:10 ` [Qemu-devel] " Vasilis Liaskovitis
2012-01-24 10:10 ` [PATCH 2/4] uq/master: Add machine model pc-1.1 Vasilis Liaskovitis
2012-01-24 10:10 ` [Qemu-devel] " Vasilis Liaskovitis
2012-01-24 10:10 ` [PATCH v2 3/4] uq/master: Add CPU eject handling for acpi_piix4 Vasilis Liaskovitis
2012-01-24 10:10 ` [Qemu-devel] " Vasilis Liaskovitis
2012-01-24 10:28 ` Jan Kiszka [this message]
2012-01-24 10:28 ` Jan Kiszka
2012-01-24 12:52 ` Andreas Färber
2012-01-24 12:52 ` Andreas Färber
2012-01-24 12:57 ` Jan Kiszka
2012-01-24 12:57 ` Jan Kiszka
2012-01-24 14:56 ` Vasilis Liaskovitis
2012-01-24 14:56 ` [Qemu-devel] " Vasilis Liaskovitis
2012-01-26 10:46 ` Avi Kivity
2012-01-26 10:46 ` [Qemu-devel] " Avi Kivity
2012-01-30 10:14 ` Vasilis Liaskovitis
2012-01-30 10:14 ` [Qemu-devel] " Vasilis Liaskovitis
2012-01-24 10:10 ` [PATCH 4/4] uq/master: Add acpi cpu interface documentation Vasilis Liaskovitis
2012-01-24 10:10 ` [Qemu-devel] " Vasilis Liaskovitis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F1E87D9.6000008@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=kernelfans@gmail.com \
--cc=kevin@koconnor.net \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=seabios@seabios.org \
--cc=vasilis.liaskovitis@profitbricks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.