lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1341963026.16730.828.camel@misato.fc.hp.com>
Date:	Tue, 10 Jul 2012 17:30:26 -0600
From:	Toshi Kani <toshi.kani@...com>
To:	Khalid Aziz <khalid.aziz@...com>
Cc:	Jiang Liu <liuj97@...il.com>, lenb@...nel.org,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ACPI: Add ACPI CPU hot-remove support

On Tue, 2012-07-10 at 16:56 -0600, Khalid Aziz wrote:
> On Fri, 2012-07-06 at 15:00 -0600, Toshi Kani wrote:
> > Yes, offlining and eject are similar operations to a core as it alone
> > cannot be removed physically.  Ejecting a core is a logical eject
> > operation, which updates the status (_STA) of the object in ACPI after
> > offlining.  The difference from the offlining is that the ejected core
> > is no longer assigned to the partition.  Here is one example.  Say, a
> > core is assigned to a guest partition as a dedicated resource (ex. 100%
> > of its CPU time is bound to the partition).  Offlining this core saves
> > the power-consumption, but this core is still bound to the partition.
> > Ejecting the core removes it from the partition (logically), and allows
> > it to be assigned to other partition as a dedicated resource with
> > hot-add.
> > 
> 
> Ejecting a core is reasonable when eject happens from a guest. I still
> wonder what firmware would do if kernel calls eject method on a core
> when running on the native host platform. If firmware behavior is not
> well defined in this case, there might be some risk associated with
> calling eject method on core. 
> 
> Makes sense?

No, that's not the case.  The firmware only implements _EJ0 when it
supports the behavior on the environment.  It is true for both native
and virtual platforms.  Note that the presence of a CPU is abstracted
with _STA in ACPI, so it does not matter to the kernel if an eject is a
physical or logical operation.

For example, HP Superdome 2 implements _EJ0 on the native platform to
support capacity-on-demand and RAS features (which are supported by
HP-UX).  _EJ0 is still a logical eject operation in this case.

Thanks,
-Toshi



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ