Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH qemu] spapr: Stop providing RTAS blob

[Thomas Huth]

On 19/07/2019 03.23, Alexey Kardashevskiy wrote:
> 
> 
> On 18/07/2019 20:49, Thomas Huth wrote:
>> On 18/07/2019 12.40, Greg Kurz wrote:
>>> On Thu, 18 Jul 2019 17:55:12 +1000
>>> Alexey Kardashevskiy <address@hidden> wrote:
>>>
>>>>
>>>>
>>>> On 18/07/2019 17:20, Thomas Huth wrote:
>>>>> On 16/07/2019 07.35, Alexey Kardashevskiy wrote:
>>>>>> SLOF implements one itself so let's remove it from QEMU. It is one
>>>>>> less
>>>>>> image and simpler setup as the RTAS blob never stays in its
>>>>>> initial place
>>>>>> anyway as the guest OS always decides where to put it.
>>>>>>
>>>>>> This totally depends on https://patchwork.ozlabs.org/patch/1132440/ ,
>>>>>> hence RFC.
>>>>>
>>>>> Patch looks basically fine for me, but I wonder whether we should wait
>>>>> for one or two releases until we really remove it from QEMU, so
>>>>> that it
>>>>> is still possible to test the latest QEMU with older SLOF releases
>>>>> for a
>>>>> while (which is sometimes useful when hunting bugs). Or should this
>>>>> maybe even go through the official deprecation process (i.e. with an
>>>>> entry in qemu-deprecated.texi)?
>>>>
>>>> I worry more about slof being distributed as a separate package in
>>>> RHEL,
>>>> easy enough to get qemu/slof out of sync.
>>>>
>>>
>>> Then it seems to call for keeping the code around in QEMU in case RHEL's
>>> slof doesn't implement the RTAS blob. Following the official deprecation
>>> process looks like a good option IMHO.
>>
>> We can of course make the qemu rpm depend on the new SLOF rpm, so that
>> you can not install an older SLOF with a newer QEMU.
> 
> Cool, let's do that.
> 
>> But anyway, to avoid confusion and ease debugging,
> 
> There is a little confusion ("why did the guest stop after Device tree
> struct  0x000000000aff0000 -> 0x000000000b000000") and what will make
> the debugging harder if we drop rtas from qemu now? I think I should
> have known the answer by now but I do not :)

I meant bugs where you are not sure whether it's a problem of QEMU or
SLOF. In that case, it's useful to use older SLOF versions with newer
QEMU versions, to see where it breaks.
But since SLOF is not that much updated recently, I think it's not so
important to keep this "feature".

>> I'd also rather vote
>> for the official deprecation process here, and remove the RTAS blob from
>> QEMU after the official deprecation period.
> 
> We won't be able to enjoy one less binary for another year and we
> already have bugs fixes for which would benefit from not having rtas blob.

Ok, if you have other things in the pipe that depend on this clean-up,
then please ignore my suggestion and remove it right away. It's not a
"feature" that was directly visible to the guest OS or the users, so I
don't think we urgently need the deprecation process here.

 Thomas