qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH qemu v2] spapr: Kill SLOF


From: Cédric Le Goater
Subject: Re: [PATCH qemu v2] spapr: Kill SLOF
Date: Mon, 6 Jan 2020 18:09:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

>>>>> 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?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]