[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 1/1] target-ppc: Implement rtas_get_sysparm(P
From: |
David Gibson |
Subject: |
Re: [Qemu-devel] [PATCH v2 1/1] target-ppc: Implement rtas_get_sysparm(PROCESSOR_MODULE_INFO) |
Date: |
Thu, 12 Nov 2015 15:47:15 +1100 |
User-agent: |
Mutt/1.5.23 (2015-06-09) |
On Wed, Nov 11, 2015 at 02:10:48PM -0800, Nishanth Aravamudan wrote:
> On 11.11.2015 [12:41:26 +1100], David Gibson wrote:
> > On Tue, Nov 10, 2015 at 04:56:38PM -0800, Nishanth Aravamudan wrote:
> > > On 11.11.2015 [11:17:58 +1100], David Gibson wrote:
> > > > On Mon, Nov 09, 2015 at 08:22:32PM -0800, Sukadev Bhattiprolu wrote:
>
> <snip>
>
> > > > The trouble with xscom is that it's extremely specific to the way the
> > > > current IBM servers present things. It won't work on other types of
> > > > host machine (which could happen with PR KVM), and could even break if
> > > > IBM changes the way it organizes the SCOMs in a future machine.
> > > >
> > > > Working from the nodes in /cpus still has some dependencies on IBM
> > > > specific properties, but it's at least partially based on OF
> > > > standards.
> > > >
> > > > There's also another possible approach here, though I don't know if it
> > > > will work. Instead of looking directly in the device tree, try to get
> > > > the information from lscpu, or libosinfo. That would at least give
> > > > you some hope of providing meaningful information on other host types.
> > >
> > > Heh, the issue that is underlying all of this, is that `lscpu` itself is
> > > quite wrong.
> > >
> > > On PAPR-compliant hypervisors (well, PowerVM, at least), the only
> > > supported means of determining the underlying hardware CPU information
> > > (which is what licensing models want in the end), is to use this RTAS
> > > call in an LPAR. `lscpu` is explicitly incorrect in these environments
> > > (it's values are "derived" from sysfs and some are adjusted to ensure
> > > the division of values works out).
> >
> > So.. I'm not sure if you're just saying that lscpu is wrong because it
> > gives the guest information, or because of other problems.
>
> `lscpu`'s man-page specifically says that on virtualized platforms, the
> output may be inaccurate. And, in fact, on Power, in a KVM guest (and
> in a LPAR), `lscpu` is outputting the guest CPU information, which is
> completely fake. This is true on x86 KVM guests too, afaict.
Um.. yes, I was assuming lscpu reporting information about virtual
cpus and sockets was intended and correct behaviour.
> *If* we have a valid RTAS implementation on PowerKVM (or under qemu
> generally), I think we can modify `lscpu` to do the right thing in at
> least those two environments.
>
> > What I was suggesting is implementing the RTAS call so that it
> > effectively lets the guest get lscpu information from the host.
>
> A bit of a chicken & egg problem, I'd say. The `lscpu` output in PowerNV
> is also wrong :)
Ok.. why is it wrong in PowerNV? This sounds like something you'd
want to fix anyway.
> > > So, we are trying to at least resolve what PowerKVM guest can see by
> > > supporting this RTAS call there. We should report *something* to the
> > > guest, if possible, and we can adjust what is reported to the guests as
> > > we go, from the host perspective.
> > >
> > > I haven't followed along too closely in this thread, but woudl it be
> > > reasonable to only report this RTAS call as being supported under
> > > KVM?
> >
> > Possibly, yes.
>
> At least, as a first step, I guess.
>
> > > How are other RTAS calls dealt with for PR and non-IBM models
> > > currently?
> >
> > Most of them still make sense in PR or TCG. A few do look in the host
> > device tree, in which case they're likely to fail on non-KVM.
>
> Got it, thanks.
>
> So my investigation overall led me to this set of conclusions:
>
> 1) Under PowerVM, we do not use this RTAS call, which is the only (as
> asserted by pHyp developers) valid way to get hardware information about
> the machine. Therefore, the PowerVM `lscpu` output is the "virtual" CPU
> information -- where cores are as defined by sharing of the L2-cache.
>
> 2) Under PowerKVM, we do not use this RTAS call, because it's not
> supported, and just spit out whatever the qemu topology is (which has no
> connection to the host (physical) CPU information).
Right.. so does that mean nothing is using this call yet?
> --> so if we implement the RTAS call of some sort under PowerKVM, then
> we can update `lscpu` to use that RTAS call.
Yeah, I'm not convinced that's correct. Shouldn't lscpu return the
virtual cpu information, at least by default.
> 3) Under PowerNV, there is a dependency on the hack that is ibm,chip-id
> from OPAL, which leads to twice as many sockets potentially being
> reported. `lscpu` also uses the sysfs files directly, which may or may
> not be the physical topology (I'm still tracking all of this down).
>
> *Also* `lscpu` has no knowledge of offline/online CPUs, so as you
> online/offline CPUs, the output of `lscpu` starts to change.
Ah, true.
> I think what we eventually want to do is add some fields to `lscpu` to
> indicate the "physical" data vs. the "virtual" data.
Ok.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
- Re: [Qemu-devel] [PATCH v2 1/1] target-ppc: Implement rtas_get_sysparm(PROCESSOR_MODULE_INFO), (continued)
Re: [Qemu-devel] [PATCH v2 1/1] target-ppc: Implement rtas_get_sysparm(PROCESSOR_MODULE_INFO), David Gibson, 2015/11/09
- Re: [Qemu-devel] [PATCH v2 1/1] target-ppc: Implement rtas_get_sysparm(PROCESSOR_MODULE_INFO), Sukadev Bhattiprolu, 2015/11/09
- Re: [Qemu-devel] [PATCH v2 1/1] target-ppc: Implement rtas_get_sysparm(PROCESSOR_MODULE_INFO), David Gibson, 2015/11/10
- Re: [Qemu-devel] [PATCH v2 1/1] target-ppc: Implement rtas_get_sysparm(PROCESSOR_MODULE_INFO), Nishanth Aravamudan, 2015/11/10
- Re: [Qemu-devel] [PATCH v2 1/1] target-ppc: Implement rtas_get_sysparm(PROCESSOR_MODULE_INFO), David Gibson, 2015/11/10
- Re: [Qemu-devel] [PATCH v2 1/1] target-ppc: Implement rtas_get_sysparm(PROCESSOR_MODULE_INFO), Nishanth Aravamudan, 2015/11/11
- Re: [Qemu-devel] [PATCH v2 1/1] target-ppc: Implement rtas_get_sysparm(PROCESSOR_MODULE_INFO),
David Gibson <=
- Re: [Qemu-devel] [PATCH v2 1/1] target-ppc: Implement rtas_get_sysparm(PROCESSOR_MODULE_INFO), Nishanth Aravamudan, 2015/11/12
- Re: [Qemu-devel] [PATCH v2 1/1] target-ppc: Implement rtas_get_sysparm(PROCESSOR_MODULE_INFO), David Gibson, 2015/11/30
Re: [Qemu-devel] [PATCH v2 1/1] target-ppc: Implement rtas_get_sysparm(PROCESSOR_MODULE_INFO), Sukadev Bhattiprolu, 2015/11/13