From: "Cédric Le Goater" <clg@kaod.org>
To: Alexey Kardashevskiy <aik@ozlabs.ru>,
David Gibson <david@gibson.dropbear.id.au>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [PATCH qemu v2] spapr: Kill SLOF
Date: Mon, 6 Jan 2020 18:09:11 +0100 [thread overview]
Message-ID: <b0587d24-c7f6-ff1f-9527-ee389bd25b1f@kaod.org> (raw)
In-Reply-To: <741e9b5e-6a7d-66a4-451d-e37c30697b2b@ozlabs.ru>
>>>>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
>>>>> index e62c89b3dd40..1c97534a0aea 100644
>>>>> --- a/hw/ppc/spapr.c
>>>>> +++ b/hw/ppc/spapr.c
>>>>> @@ -896,6 +896,51 @@ out:
>>>>> return ret;
>>>>> }
>>>>> +/*
>>>>> + * Below is a compiled version of RTAS blob and OF client interface entry point.
>>>>> + *
>>>>> + * gcc -nostdlib -mbig -o spapr-rtas.img spapr-rtas.S
>>>>> + * objcopy -O binary -j .text spapr-rtas.img spapr-rtas.bin
>>>>> + *
>>>>> + * .globl _start
>>>>> + * _start:
>>>>> + * mr 4,3
>>>>> + * lis 3,KVMPPC_H_RTAS@h
>>>>> + * ori 3,3,KVMPPC_H_RTAS@l
>>>>> + * sc 1
>>>>> + * blr
>>>>> + * mr 4,3
>>>>> + * lis 3,KVMPPC_H_CLIENT@h
>>>>> + * ori 3,3,KVMPPC_H_CLIENT@l
>>>>> + * sc 1
>>>>> + * blr
>>>>> + */
>>>>> +static struct {
>>>>> + uint8_t rtas[20], client[20];
>>>>> +} QEMU_PACKED rtas_client_blob = {
>>>>> + .rtas = {
>>>>> + 0x7c, 0x64, 0x1b, 0x78,
>>>>> + 0x3c, 0x60, 0x00, 0x00,
>>>>> + 0x60, 0x63, 0xf0, 0x00,
>>>>> + 0x44, 0x00, 0x00, 0x22,
>>>>> + 0x4e, 0x80, 0x00, 0x20
>>>>> + },
>>>>> + .client = {
>>>>> + 0x7c, 0x64, 0x1b, 0x78,
>>>>> + 0x3c, 0x60, 0x00, 0x00,
>>>>> + 0x60, 0x63, 0xf0, 0x05,
>>>>> + 0x44, 0x00, 0x00, 0x22,
>>>>> + 0x4e, 0x80, 0x00, 0x20
>>>>> + }
>>>>> +};
>>>>
>>>> I'd really prefer to read this in from a file (or files) which we
>>>> assemble (as with the existing spapr-rtas.img), rather than having a
>>>> magic array in qemu.
>>>
>>> Two considerations here:
>>> 1. This blob is not going to change (at least often)
>>
>> True, but I'd still prefer to build it from a .S rather than have the
>> binary written out. We already had this until recently (when we moved
>> the RTAS image into SLOF), and it's really not too hard to manage.
>
>
> But what is exactly the benefit? It is not going to change. I can look into making it a .S, compile it to a binary an include this binary into qemu-system-ppc64 as a byte array, just need to refresh my gcc/ldd memories but a separate file is too much for this imho.
ARM bootloaders are also embedded in QEMU's code. See hw/arm/boot.c.
You could improve a bit the definition though.
C.
>
>>> 2. A new file which needs to be packaged/signed/copied.
>>
>> Eh, again, we had this for RTAS until very recently and it really
>> wasn't that much hassle.
>
>
> I keep secure VMs in mind. And SLOF is a separate package, why was not RTAS?
next prev parent reply other threads:[~2020-01-06 17:09 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-05 23:42 [PATCH qemu v2] spapr: Kill SLOF Alexey Kardashevskiy
2020-01-06 4:19 ` David Gibson
2020-01-06 6:28 ` Alexey Kardashevskiy
2020-01-06 8:50 ` David Gibson
2020-01-06 12:34 ` Alexey Kardashevskiy
2020-01-06 17:09 ` Cédric Le Goater [this message]
2020-01-06 17:25 ` Peter Maydell
2020-01-06 18:56 ` Philippe Mathieu-Daudé
2020-01-07 1:44 ` Alexey Kardashevskiy
2020-01-07 5:26 ` David Gibson
2020-01-08 4:07 ` Alexey Kardashevskiy
2020-01-09 4:07 ` David Gibson
2020-01-09 6:31 ` Alexey Kardashevskiy
2020-01-13 3:32 ` David Gibson
2020-01-06 13:39 ` Alexey Kardashevskiy
2020-01-06 23:56 ` David Gibson
2020-01-07 4:44 ` Alexey Kardashevskiy
2020-01-07 5:54 ` David Gibson
2020-01-08 4:20 ` Alexey Kardashevskiy
2020-01-08 5:53 ` Alexey Kardashevskiy
2020-01-09 4:25 ` David Gibson
2020-01-09 4:18 ` 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=b0587d24-c7f6-ff1f-9527-ee389bd25b1f@kaod.org \
--to=clg@kaod.org \
--cc=aik@ozlabs.ru \
--cc=david@gibson.dropbear.id.au \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).