From: Gleb Natapov <gleb@redhat.com>
To: "Kevin O'Connor" <kevin@koconnor.net>
Cc: seabios@seabios.org, kvm@vger.kernel.org
Subject: Re: Alt SeaBIOS SSDT cpu hotplug
Date: Fri, 9 Jul 2010 18:44:33 +0300 [thread overview]
Message-ID: <20100709154433.GB11885@redhat.com> (raw)
In-Reply-To: <20100709004506.GB25116@morn.localdomain>
On Thu, Jul 08, 2010 at 08:45:06PM -0400, Kevin O'Connor wrote:
> On Thu, Jul 08, 2010 at 03:54:10PM +0300, Gleb Natapov wrote:
> > On Wed, Jul 07, 2010 at 07:26:07PM -0400, Kevin O'Connor wrote:
> > > On Wed, Jul 07, 2010 at 01:22:49PM +0300, Gleb Natapov wrote:
> > > > On Wed, Jul 07, 2010 at 12:57:05AM -0400, Kevin O'Connor wrote:
> > > > > The "CPUS" package stores references to the Processor objects, and the
> > > > > "CPON" package stores the state of which cpus are active. With this
> > > > > info, hopefully there is no need to update the MADT tables.
> > > > >
> > > > The way you wrote it acpi_id is always equal to lapic_id which is not
> > > > alway true. By using MADT from memory we remove this dependency from
> > > > DSDT code.
> > >
> > > The current code always sets the apic->processor_id equal to
> > > apic->local_apic_id in the madt apic table. If this changes, we could
> > > add a dynamically created mapping table to the ssdt. Something like:
> > >
> > > Name(CPLA, Package() { 0x00, 0x01, 0x02, 0x03, 0x04 })
> > >
> > Yeah, but if we can avoid it in the first place why not doing so.
>
> There is a cost to reading/writing the MADT tables. The hardcoding of
> 0x514 has a risk - it's not clear to me that an optionrom wont clobber
> that space. It also recently occurred to me that there may be a
> problem if a guest expects the MADT address to remain constant across
> a hibernate/restore cycle - the malloc_high() function doesn't
> guarentee stable addresses across reboots.
>
That's definitely an issue. HW shouldn't change between hibernate and
resume, so boot process should be the same and address should end up be
the same too, but I wouldn't want to rely on this blindly.
> >BTW how
> > do you pass to DSDT what cpus are initially on? Previously this info was
> > taken from memory copy of MADT too.
>
> The CPON array is dynamically generated with the status of the
> processors. (It is then kept up to date by the DSDT code.) The code
> for generating CPON is:
>
> // build "Name(CPON, Package() { One, One, ..., Zero, Zero, ... })"
> *(ssdt_ptr++) = 0x08; // NameOp
> *(ssdt_ptr++) = 'C';
> *(ssdt_ptr++) = 'P';
> *(ssdt_ptr++) = 'O';
> *(ssdt_ptr++) = 'N';
> *(ssdt_ptr++) = 0x12; // PackageOp
> ssdt_ptr = encodeLen(ssdt_ptr, 2+1+(1*acpi_cpus), 2);
> *(ssdt_ptr++) = acpi_cpus;
> for (i=0; i<acpi_cpus; i++)
> *(ssdt_ptr++) = (i < CountCPUs) ? 0x01 : 0x00;
>
See it now. Thanks.
--
Gleb.
prev parent reply other threads:[~2010-07-09 15:44 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-07 4:57 Alt SeaBIOS SSDT cpu hotplug Kevin O'Connor
2010-07-07 10:07 ` Avi Kivity
2010-07-08 13:19 ` Liu, Jinsong
2010-07-09 5:35 ` Kevin O'Connor
2010-07-09 16:41 ` Liu, Jinsong
2010-07-11 16:10 ` Kevin O'Connor
2010-07-24 18:04 ` Kevin O'Connor
2010-07-25 4:49 ` Liu, Jinsong
2010-07-30 17:22 ` Liu, Jinsong
2010-07-31 0:04 ` Kevin O'Connor
2010-08-02 2:41 ` Liu, Jinsong
2010-08-02 5:49 ` Kevin O'Connor
2010-08-02 8:12 ` Alexander Graf
2010-08-02 15:55 ` Kevin O'Connor
2010-08-02 16:10 ` Alexander Graf
2010-08-02 16:13 ` Avi Kivity
2010-08-02 16:15 ` Alexander Graf
2010-08-02 17:27 ` Kevin O'Connor
2010-08-03 0:30 ` Zheng, Shaohui
2010-08-03 9:00 ` Liu, Jinsong
2010-08-03 22:47 ` Kevin O'Connor
2010-08-06 3:46 ` Liu, Jinsong
2010-07-07 10:22 ` Gleb Natapov
2010-07-07 23:26 ` Kevin O'Connor
2010-07-08 12:54 ` Gleb Natapov
2010-07-09 0:45 ` Kevin O'Connor
2010-07-09 15:44 ` Gleb Natapov [this message]
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=20100709154433.GB11885@redhat.com \
--to=gleb@redhat.com \
--cc=kevin@koconnor.net \
--cc=kvm@vger.kernel.org \
--cc=seabios@seabios.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).