qemu-ppc
[Top][All Lists]
Advanced

[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



reply via email to

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