All of lore.kernel.org
 help / color / mirror / Atom feed
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.

      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 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.