[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [Qemu-devel] [PATCH RFC] spapr: by-pass SLOF when -kernel
From: |
Alexey Kardashevskiy |
Subject: |
Re: [Qemu-ppc] [Qemu-devel] [PATCH RFC] spapr: by-pass SLOF when -kernel is provided |
Date: |
Wed, 6 Jul 2016 18:04:44 +1000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 |
On 06/07/16 18:02, Nikunj A Dadhania wrote:
> Alexey Kardashevskiy <address@hidden> writes:
>
>> [ Unknown signature status ]
>> On 06/07/16 11:35, David Gibson wrote:
>>> On Tue, Jul 05, 2016 at 04:42:37PM +0200, Laurent Vivier wrote:
>>>> As device-tree is now fully built by QEMU, we don't need SLOF
>>>> anymore if the kernel is provided on the command line.
>>>>
>>>> In this case, don't load SLOF and boot directly into the
>>>> kernel.
>>>>
>>>> This saves at least 5 seconds on the boot sequence.
>>>>
>>>> Signed-off-by: Laurent Vivier <address@hidden>
>>>
>>> I'm not comfortable applying this. We actually used to do this ages
>>> ago, but changed to always running through SLOF, and there were
>>> reasons for doing so.
>>>
>>> I don't remember exactly what they were, but I think it boiled down to
>>> slight differences in state between booting from SLOF and booting
>>> without SLOF leading to confusing errors from the guest kernel.
>>>
>>
>> PCI resource allocation is still done by SLOF (however having them not set
>> will trigger allocation in the guest but this is rather unexpected
>> workaround than a feature);
>
> I am not sure that works well, i had a work around in qemu for this to get
> triggered in guest kernel.
>
Creating resource properties (i.e. BARs) with FFFFFFFF in QEMU did the
trick if I remember correctly. Either way, this is a hack.
>> "client-architecture-support" won't work
>> without SLOF either (i.e. compatibile PowerISA 2.0x CPUs).
>
> Right.
>
> Regards
> Nikunj
>
--
Alexey