All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Andrea Bolognani <abologna@redhat.com>,
	Daniel Henrique Barboza <danielhb413@gmail.com>,
	qemu-devel@nongnu.org
Cc: "Jose Ricardo Ziviani" <joserz@linux.ibm.com>,
	"Fabiano Rosas" <farosas@linux.ibm.com>,
	"Sam Bobroff" <sbobroff@linux.ibm.com>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Michael Roth" <mdroth@linux.vnet.ibm.com>,
	"Nicholas Piggin" <npiggin@gmail.com>,
	"Paul Mackerras" <paulus@ozlabs.org>,
	qemu-ppc@nongnu.org,
	"Leonardo Augusto Guimarães Garcia" <lagarcia@br.ibm.com>,
	"Leonardo Bras" <leonardo@linux.ibm.com>,
	"David Gibson" <david@gibson.dropbear.id.au>
Subject: Re: [RFC PATCH qemu] spapr: Kill SLOF
Date: Tue, 14 Jan 2020 11:43:54 +1100	[thread overview]
Message-ID: <aa44205f-e56c-daba-e2ed-e3c7817676df@ozlabs.ru> (raw)
In-Reply-To: <1a8f9121a3cb85d415ff1c67a5379a717ad2b8e0.camel@redhat.com>



On 13/01/2020 20:13, Andrea Bolognani wrote:
> On Wed, 2020-01-08 at 13:34 +1100, Alexey Kardashevskiy wrote:
>> On 07/01/2020 20:39, Andrea Bolognani wrote:
>>> On Tue, 2020-01-07 at 12:55 +1100, Alexey Kardashevskiy wrote:
>>>> Petitboot kernel+initramdisk almost replaces SLOF + GRUB.
>>>
>>> Is this necessarily a good thing?
>>
>> The bare metal host and the powernv machine in QEMU do not use grub,
>> they use petitboot which parses all grub configs and supports quite a lot.
> 
> How well does the distro integration work? Eg. if I change something
> in /etc/default/grub and then run grub2-mkconfig, can I expect my
> changes to be picked up?

Yes. Even the environment file (/boot/grub/grubenv).

> In which scenarios will that *not* work?

When/if grub adds a big new feature and petitboot won't have support for
it. Otherwise everything from GRUB is supported today.


>> Using Linux for a boot loader is not powerpc-only thing really, some
>> folks do this too (forgot who, just heard this at the KVM forum).
> 
> While other options are available and some architectures use
> something else entirely, GRUB is the de-facto standard across most
> of the non-obscure architectures.

True. I am thinking of extending this patch to support GRUB as well. Or
alternatively we could add a mode to GRUB to run in userspace under
petitboot's kernel.

It just seems quite an attractive idea to be able to boot from literally
anything without needing a ROM on whatever device is passed through to
the guest, or a driver in SLOF.


> I guess the question is whether it's more important to be consistent
> within the architecture or across them. I think the latter might be
> preferable, especially when we consider what I think is the most
> common scenario, that is, someone who's used to having GRUB on their
> x86 machine running a ppc64 guest on the cloud. The more skills they
> can automatically transfer over, the better.

True. petitboot is not horribly different though, and the user has to
take exact same steps as if it was GRUB.

>>> Personally I quite like the fact
>>> that I can use the same bootloader across x86, ppc64 and aarch64.
>>
>> I am not suggesting removing SLOF soon
> 
> Perhaps the patch subject shouldn't be "kill SLOF" then? ;)

This way I get more attention ;)


-- 
Alexey


  reply	other threads:[~2020-01-14  0:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-03  7:44 [RFC PATCH qemu] spapr: Kill SLOF Alexey Kardashevskiy
2020-01-05 23:38 ` Alexey Kardashevskiy
2020-01-06 14:15   ` Daniel Henrique Barboza
2020-01-07  1:55     ` Alexey Kardashevskiy
2020-01-07  9:39       ` Andrea Bolognani
2020-01-07 11:23         ` Thomas Huth
2020-01-14  9:04           ` Michal Suchánek
2020-01-08  2:34         ` Alexey Kardashevskiy
2020-01-13  9:13           ` Andrea Bolognani
2020-01-14  0:43             ` Alexey Kardashevskiy [this message]
2020-01-14  0:48             ` David Gibson

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=aa44205f-e56c-daba-e2ed-e3c7817676df@ozlabs.ru \
    --to=aik@ozlabs.ru \
    --cc=abologna@redhat.com \
    --cc=danielhb413@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=farosas@linux.ibm.com \
    --cc=joserz@linux.ibm.com \
    --cc=lagarcia@br.ibm.com \
    --cc=leonardo@linux.ibm.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=paulus@ozlabs.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=sbobroff@linux.ibm.com \
    /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.