From: Igor Mammedov <imammedo@redhat.com>
To: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>
Cc: gleb@redhat.com, seabios@seabios.org, qemu-devel@nongnu.org,
kvm@vger.kernel.org, avi@redhat.com
Subject: Re: [RFC PATCH 2/9][SeaBIOS] Implement acpi-dsdt functions for memory hotplug.
Date: Fri, 20 Apr 2012 12:55:24 +0200 [thread overview]
Message-ID: <4F91409C.5080307@redhat.com> (raw)
In-Reply-To: <1334844527-18869-3-git-send-email-vasilis.liaskovitis@profitbricks.com>
On 04/19/2012 04:08 PM, Vasilis Liaskovitis wrote:
> Extend the DSDT to include methods for handling memory hot-add and hot-remove
> notifications and memory device status requests. These functions are called
> from the memory device SSDT methods.
>
> Eject has only been tested with level gpe event, but will be changed to edge gpe
> event soon, according to recent master patch for other ACPI hotplug events.
>
> Signed-off-by: Vasilis Liaskovitis<vasilis.liaskovitis@profitbricks.com>
> ---
> src/acpi-dsdt.dsl | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 files changed, 66 insertions(+), 2 deletions(-)
>
> diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl
> index 4bdc268..184daf0 100644
> --- a/src/acpi-dsdt.dsl
> +++ b/src/acpi-dsdt.dsl
> @@ -709,9 +709,72 @@ DefinitionBlock (
> }
> Return(One)
> }
> - }
>
> + /* Objects filled in by run-time generated SSDT */
> + External(MTFY, MethodObj)
> + External(MEON, PkgObj)
> +
> + Method (CMST, 1, NotSerialized) {
> + // _STA method - return ON status of memdevice
> + // Local0 = MEON flag for this cpu
> + Store(DerefOf(Index(MEON, Arg0)), Local0)
> + If (Local0) { Return(0xF) } Else { Return(0x0) }
> + }
> + /* Memory eject notify method */
> + OperationRegion(MEMJ, SystemIO, 0xaf40, 32)
> + Field (MEMJ, ByteAcc, NoLock, Preserve)
> + {
> + MPE, 256
> + }
> +
> + Method (MPEJ, 2, NotSerialized) {
> + // _EJ0 method - eject callback
> + Store(ShiftLeft(1,Arg0), MPE)
> + Sleep(200)
> + }
MPE is write only and only one memslot is ejected at a time. Why 256 bit-field is here then?
Could we use just 1 byte and write a slot number into it and save some io address space this way?
> +
> + /* Memory hotplug notify method */
> + OperationRegion(MEST, SystemIO, 0xaf20, 32)
It's more a suggestion: move it a bit farther to allow maybe 1024 cpus in the future.
That will prevent compatibility a headache, if we decide to expand support to more then
256 cpus.
Or event better to make this address configurable in run-time and build this var along
with SSDT (converting along the way all other hard-coded io ports to the same generic
run-time interface). This wish is out of scope of this patch-set, but what
do you think about the idea?
> + Field (MEST, ByteAcc, NoLock, Preserve)
> + {
> + MES, 256
> + }
> +
> + Method(MESC, 0) {
> + // Local5 = active memdevice bitmap
> + Store (MES, Local5)
> + // Local2 = last read byte from bitmap
> + Store (Zero, Local2)
> + // Local0 = memory device iterator
> + Store (Zero, Local0)
> + While (LLess(Local0, SizeOf(MEON))) {
> + // Local1 = MEON flag for this memory device
> + Store(DerefOf(Index(MEON, Local0)), Local1)
> + If (And(Local0, 0x07)) {
> + // Shift down previously read bitmap byte
> + ShiftRight(Local2, 1, Local2)
> + } Else {
> + // Read next byte from memdevice bitmap
> + Store(DerefOf(Index(Local5, ShiftRight(Local0, 3))), Local2)
> + }
> + // Local3 = active state for this memory device
> + Store(And(Local2, 1), Local3)
>
> + If (LNotEqual(Local1, Local3)) {
> + // State change - update MEON with new state
> + Store(Local3, Index(MEON, Local0))
> + // Do MEM notify
> + If (LEqual(Local3, 1)) {
> + MTFY(Local0, 1)
> + } Else {
> + MTFY(Local0, 3)
> + }
> + }
> + Increment(Local0)
> + }
> + Return(One)
> + }
> + }
> /****************************************************************
> * General purpose events
> ****************************************************************/
> @@ -732,7 +795,8 @@ DefinitionBlock (
> Return(\_SB.PRSC())
> }
> Method(_L03) {
> - Return(0x01)
> + // Memory hotplug event
> + Return(\_SB.MESC())
> }
> Method(_L04) {
> Return(0x01)
--
-----
Igor
next prev parent reply other threads:[~2012-04-20 10:55 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-19 14:08 [RFC PATCH 0/9] ACPI memory hotplug Vasilis Liaskovitis
2012-04-19 14:08 ` [RFC PATCH 1/9][SeaBIOS] Add SSDT memory device support Vasilis Liaskovitis
2012-04-19 14:08 ` [RFC PATCH 2/9][SeaBIOS] Implement acpi-dsdt functions for memory hotplug Vasilis Liaskovitis
2012-04-20 10:55 ` Igor Mammedov [this message]
2012-04-20 14:11 ` [Qemu-devel] " Vasilis Liaskovitis
2012-04-19 14:08 ` [RFC PATCH 3/9][SeaBIOS] acpi: generate hotplug memory devices Vasilis Liaskovitis
2012-04-23 23:37 ` Kevin O'Connor
2012-04-24 8:27 ` Vasilis Liaskovitis
2012-04-19 14:08 ` [RFC PATCH 4/9] Implement memslot device abstraction Vasilis Liaskovitis
2012-04-19 14:08 ` [RFC PATCH 5/9] acpi_piix4: Implement memory device hotplug registers Vasilis Liaskovitis
2012-04-19 14:08 ` [RFC PATCH 6/9] pc: pass paravirt info for hotplug memory slots to BIOS Vasilis Liaskovitis
2012-04-19 14:21 ` Avi Kivity
2012-04-20 10:33 ` Igor Mammedov
2012-04-20 16:35 ` [Qemu-devel] " Vasilis Liaskovitis
2012-04-19 14:08 ` [RFC PATCH 7/9] Implement memslot command-line option and memslot hmp command Vasilis Liaskovitis
2012-04-19 14:22 ` Avi Kivity
2012-04-19 18:10 ` Vasilis Liaskovitis
2012-04-19 14:08 ` [RFC PATCH 8/9] pc: adjust e820 map on hot-add and hot-remove Vasilis Liaskovitis
2012-04-22 13:58 ` Gleb Natapov
2012-04-23 11:27 ` Vasilis Liaskovitis
2012-04-23 11:30 ` Gleb Natapov
2012-04-19 14:08 ` [RFC PATCH 9/9][SeaBIOS] enable memory devices if e820 entry is present Vasilis Liaskovitis
2012-04-26 0:58 ` [SeaBIOS] [RFC PATCH 9/9] " Wen Congyang
2012-04-19 14:49 ` [Qemu-devel] [RFC PATCH 0/9] ACPI memory hotplug Anthony Liguori
2012-04-19 18:09 ` Vasilis Liaskovitis
2012-04-20 14:20 ` Vasilis Liaskovitis
2012-04-22 13:56 ` Gleb Natapov
2012-04-22 14:06 ` Avi Kivity
2012-04-22 14:09 ` Gleb Natapov
2012-04-22 14:13 ` Avi Kivity
2012-04-22 14:20 ` Gleb Natapov
2012-04-23 12:31 ` Vasilis Liaskovitis
2012-04-24 7:52 ` Gleb Natapov
2012-04-24 8:24 ` Vasilis Liaskovitis
2012-04-24 8:34 ` Gleb Natapov
2012-04-23 13:31 ` Avi Kivity
2012-04-24 7:21 ` Gleb Natapov
2012-04-24 9:09 ` Avi Kivity
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=4F91409C.5080307@redhat.com \
--to=imammedo@redhat.com \
--cc=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--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.