[OP-CD] LoPAPR latest spec.
mpe at ellerman.id.au
Thu Mar 14 00:54:09 UTC 2019
Karel Gardas <gardask at gmail.com> writes:
> On 3/4/19 5:11 PM, Jeffrey Scheel wrote:
>> openpower-community-dev-bounces at mailinglist.openpowerfoundation.org > wrote on 03/03/2019 02:13:48 PM: >> From: Karel Gardas
> <gardask at gmail.com> while reading LoPAPR >> doc/spec version 1.1 (March
> 24 2016) I've found on the page 53 >> following text: >> >> "All
> platforms compliant with LoPAPR 2.3 and beyond..." >> >> it's in "2.8
> 64-Bit Addressing Support." paragraph. >> >> Does it mean that there is
> more recent version of LoPAPR than >> what's I'm reading (1.1) or does
> it mean that the author(s) is/are >> forward thinking? > Well, actually,
> both are correct. > > The original text could be considered a bug
> because the LoPAPR 1.0 > spec is based on the PAPR 2.8 version, which
> means the statement > could be eliminated because LoPAPR 1.0 is the
> earliest we plan to > deliver publicly. > > BUT, there too is a much
> going on inside the System SW WG where we > are actually taking the
> LoPAPR and splitting it into 5 sub-documents > (Device Tree, Platform,
> Error Handling, Run-time Abstraction > Services) which will then push
> PowerVM-centric details to Appendices > and focus on OPAL/baremetal
> thanks for your answer and for the reference. You sounded like
> OPAL/baremetal interfaces are priority now. Honestly the reason I'm
> reading LoPAPR is perhaps my bad understanding of the current situation.
> Let me write that I'd like to touch/observe/learn at least part of POWER
> platform ideally to be able to port some OS to it (even if it would be
> just a toy). As far as I understand, there are two platforms here:
> 1) PowerNV/OPAL interfaces -- looks like a new, emerging world, but
> interfaces looks more low-level, thing is more hardware oriented, more
We merged the powernv platform into the kernel about 7 years ago, so
some of us have been working on it for a while ;)
It is more low level, there is no hypervisor under Linux when we're
using the powernv platform, Linux *is* the hypervisor.
> 2) PowerKVM/qemu-system-ppc64 + kvm -- not sure, but I hoped this kind
> of provide what LoPAPR describes as it basically emulates pSeries.
Yeah that's pretty much right. LoPAPR describes the ABI between the
hypervisor (qemu + KVM, OR PowerVM) and the guest operating system.
> That was my naive idea about it. Yes, qemu can also emulate and be usable
> with virtio interfaces and such, but still PowerKVM/qemu+kvm looks like
> some interface which is more abstract, more stable.
Not sure I follow what you mean there entirely. Linux guests can use
virtio instead of vscsi/veth, and in fact we would recommend you do use
virtio on KVM. But even then you're still using the LoPAPR API for lots
of other things.
> Able to survive update to latest POWER10-1x CPU. Which I think
> PowerNV/OPAL will not.
The plan is that existing powernv kernels will be able to boot on a
future CPU, possibly relying on OPAL (skiboot) to abstract some hardware
details. But it's true that at that level there is less insulation from
hardware changes in future CPUs.
> Or do I understand in a wrong way new MMU (Radix?) on Power9 while
> there was just hash MMU on Power8?
There was a new MMU called radix introduced on Power9, but it's
optional. There were some backward incompatible changes made as part of
that even for kernels using the hash MMU. We are trying to avoid doing
that again in future.
> Anyway, based on complexity of platforms, what do you think would be
> best way to start with POWER for playing with OSes? I mean from the
> developer perspective, from low-level work, from debugging perspective
> etc. I do have access to one POWER8 box and planning to purchase
> Raptor's Blackbird once available -- so basic hardware will be
> available. No, I don't have JTAG or similar mechanism usable for
> low-level debugging on POWER hardware yet.
If you want to play with writing a kernel or porting a kernel, then I
would definitely recommend you start by targeting the LoPAPR
environment. That way you can test in qemu (with KVM or TCG), including
using gdb etc. And you're also insulated from some of the very low level
hardware details, and if you have a bug (which you will) it won't crash
your whole box, just the VM you're testing in.
Once you've got something working as a guest then you can try getting it
to run bare metal.
More information about the OpenPOWER-Community-Dev