diff mbox

[1/2] hw/ppc/spapr.c Set default boot order

Message ID 1422053517-23781-1-git-send-email-dvaleev@suse.de
State New
Headers show

Commit Message

dvaleev@suse.de Jan. 23, 2015, 10:51 p.m. UTC
From: Dinar Valeev <dvaleev@suse.com>

In order to use -boot once=X option we need to have default list
 where restore to on reset.

Signed-off-by: Dinar Valeev <dvaleev@suse.com>
---
 hw/ppc/spapr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Alexander Graf Jan. 23, 2015, 11 p.m. UTC | #1
On 23.01.15 23:51, dvaleev@suse.de wrote:
> From: Dinar Valeev <dvaleev@suse.com>
> 
> In order to use -boot once=X option we need to have default list
>  where restore to on reset.
> 
> Signed-off-by: Dinar Valeev <dvaleev@suse.com>

Alexey, Nijunj, where is the default boot order stored usually? Is "cdn"
an accurate equivalent?


Alex

> ---
>  hw/ppc/spapr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index b560459..3d2cfa3 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1733,7 +1733,7 @@ static void spapr_machine_class_init(ObjectClass *oc, void *data)
>      mc->block_default_type = IF_SCSI;
>      mc->max_cpus = MAX_CPUS;
>      mc->no_parallel = 1;
> -    mc->default_boot_order = NULL;
> +    mc->default_boot_order = "cdn";
>      mc->kvm_type = spapr_kvm_type;
>      mc->has_dynamic_sysbus = true;
>  
>
Markus Armbruster Jan. 26, 2015, 9:11 a.m. UTC | #2
dvaleev@suse.de writes:

> From: Dinar Valeev <dvaleev@suse.com>
>
> In order to use -boot once=X option we need to have default list
>  where restore to on reset.

Really?  What happens without this patch?
Alexander Graf Jan. 26, 2015, 9:33 a.m. UTC | #3
On 01/26/2015 01:57 PM, Dinar Valeev wrote:
> On 01/26/2015 01:37 PM, Markus Armbruster wrote:
>> Dinar Valeev <dvaleev@suse.de> writes:
>>
>>> On 01/26/2015 10:11 AM, Markus Armbruster wrote:
>>>> dvaleev@suse.de writes:
>>>>
>>>>> From: Dinar Valeev <dvaleev@suse.com>
>>>>>
>>>>> In order to use -boot once=X option we need to have default list
>>>>>    where restore to on reset.
>>>>
>>>> Really?  What happens without this patch?
>>>>
>>> qemu segfaults on reset.
>>> 0 > reset-all  Segmentation fault
>>
>> Next time, include a backtrace, please.
> Ok, sorry for that.
>>
>> Here's what I think happens.
>>
>> Boot order comes from --boot parameter once, order, or else the machine
>> type's .default_boot_order.  The latter is null for you.
>>
>> It gets passed via ppc_spapr_init() to spapr_create_fdt_skel(), which
>> sets qemu,boot-device in the FDT to it, but only when it isn't null.
>>
>> If it comes from parameter once, we additionally register a reset
>> handler to switch it to parameter order or else .default_boot_order on
>> reset.  If you specify once, but not order, this is null for you.
>>
>> On reset, reset handler restore_boot_order() runs.  Unlike
>> spapr_create_fdt_skel(), it doesn't check for null, and crashes in
>> validate_bootdevices().
>>
>> Correct?
> Yes
>
> qemu_register_boot_set is implemented in PATCH 2/2. on reset 
> boot_device is restored to NULL
>>
>> For me, a null .default_boot_order means "machine type does not support
>> boot order" (this is how commit c165473 treats it).  Arguably, --boot
>> order and once should be rejected then.
> AFICS SLOF handles qemu,boot-device as boot device, if nothing passed 
> then it goes disk, cdrom, network. Which is the same as "cdn" list.

That's not entirely true. If SLOF doesn't see qemu,boot-device, it first 
goes via its NVRAM configured boot list and only if nothing is there it 
falls back to "cdn".

Maybe the actual appropriate thing would be "mcdn" with m meaning "NVRAM".


Alex

>
>> If I understand you correctly, your machine type does support boot
>> order.  Giving it a non-null .default_boot_order makes sense then.  The
>> appropriate value depends on firmware.  It could even be "".
>>
>> The null check in spapr_create_fdt_skel() looks superfluous then.
>> Consider dropping it.
>>
>> Makes sense?
>>
>
dvaleev@suse.de Jan. 26, 2015, 10:32 a.m. UTC | #4
On 01/26/2015 10:11 AM, Markus Armbruster wrote:
> dvaleev@suse.de writes:
>
>> From: Dinar Valeev <dvaleev@suse.com>
>>
>> In order to use -boot once=X option we need to have default list
>>   where restore to on reset.
>
> Really?  What happens without this patch?
>
qemu segfaults on reset.
0 > reset-all  Segmentation fault
Markus Armbruster Jan. 26, 2015, 12:37 p.m. UTC | #5
Dinar Valeev <dvaleev@suse.de> writes:

> On 01/26/2015 10:11 AM, Markus Armbruster wrote:
>> dvaleev@suse.de writes:
>>
>>> From: Dinar Valeev <dvaleev@suse.com>
>>>
>>> In order to use -boot once=X option we need to have default list
>>>   where restore to on reset.
>>
>> Really?  What happens without this patch?
>>
> qemu segfaults on reset.
> 0 > reset-all  Segmentation fault

Next time, include a backtrace, please.

Here's what I think happens.

Boot order comes from --boot parameter once, order, or else the machine
type's .default_boot_order.  The latter is null for you.

It gets passed via ppc_spapr_init() to spapr_create_fdt_skel(), which
sets qemu,boot-device in the FDT to it, but only when it isn't null.

If it comes from parameter once, we additionally register a reset
handler to switch it to parameter order or else .default_boot_order on
reset.  If you specify once, but not order, this is null for you.

On reset, reset handler restore_boot_order() runs.  Unlike
spapr_create_fdt_skel(), it doesn't check for null, and crashes in
validate_bootdevices().

Correct?

For me, a null .default_boot_order means "machine type does not support
boot order" (this is how commit c165473 treats it).  Arguably, --boot
order and once should be rejected then.

If I understand you correctly, your machine type does support boot
order.  Giving it a non-null .default_boot_order makes sense then.  The
appropriate value depends on firmware.  It could even be "".

The null check in spapr_create_fdt_skel() looks superfluous then.
Consider dropping it.

Makes sense?
dvaleev@suse.de Jan. 26, 2015, 12:57 p.m. UTC | #6
On 01/26/2015 01:37 PM, Markus Armbruster wrote:
> Dinar Valeev <dvaleev@suse.de> writes:
>
>> On 01/26/2015 10:11 AM, Markus Armbruster wrote:
>>> dvaleev@suse.de writes:
>>>
>>>> From: Dinar Valeev <dvaleev@suse.com>
>>>>
>>>> In order to use -boot once=X option we need to have default list
>>>>    where restore to on reset.
>>>
>>> Really?  What happens without this patch?
>>>
>> qemu segfaults on reset.
>> 0 > reset-all  Segmentation fault
>
> Next time, include a backtrace, please.
Ok, sorry for that.
>
> Here's what I think happens.
>
> Boot order comes from --boot parameter once, order, or else the machine
> type's .default_boot_order.  The latter is null for you.
>
> It gets passed via ppc_spapr_init() to spapr_create_fdt_skel(), which
> sets qemu,boot-device in the FDT to it, but only when it isn't null.
>
> If it comes from parameter once, we additionally register a reset
> handler to switch it to parameter order or else .default_boot_order on
> reset.  If you specify once, but not order, this is null for you.
>
> On reset, reset handler restore_boot_order() runs.  Unlike
> spapr_create_fdt_skel(), it doesn't check for null, and crashes in
> validate_bootdevices().
>
> Correct?
Yes

qemu_register_boot_set is implemented in PATCH 2/2. on reset boot_device 
is restored to NULL
>
> For me, a null .default_boot_order means "machine type does not support
> boot order" (this is how commit c165473 treats it).  Arguably, --boot
> order and once should be rejected then.
AFICS SLOF handles qemu,boot-device as boot device, if nothing passed 
then it goes disk, cdrom, network. Which is the same as "cdn" list.

> If I understand you correctly, your machine type does support boot
> order.  Giving it a non-null .default_boot_order makes sense then.  The
> appropriate value depends on firmware.  It could even be "".
>
> The null check in spapr_create_fdt_skel() looks superfluous then.
> Consider dropping it.
>
> Makes sense?
>
Nikunj A Dadhania Jan. 27, 2015, 4:36 a.m. UTC | #7
Alexander Graf <agraf@suse.de> writes:

> On 23.01.15 23:51, dvaleev@suse.de wrote:
>> From: Dinar Valeev <dvaleev@suse.com>
>> 
>> In order to use -boot once=X option we need to have default list
>>  where restore to on reset.
>> 
>> Signed-off-by: Dinar Valeev <dvaleev@suse.com>
>
> Alexey, Nijunj, where is the default boot order stored usually?

When -boot argument is not present, the default boot order is NULL for
spapr, and SLOF decides to boot from NVRAM set variable or discovered
disk.

> Is "cdn" an accurate equivalent?

No, we have changed that to NULL.

http://comments.gmane.org/gmane.comp.emulators.qemu/187318

Regards,
Nikunj
diff mbox

Patch

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index b560459..3d2cfa3 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1733,7 +1733,7 @@  static void spapr_machine_class_init(ObjectClass *oc, void *data)
     mc->block_default_type = IF_SCSI;
     mc->max_cpus = MAX_CPUS;
     mc->no_parallel = 1;
-    mc->default_boot_order = NULL;
+    mc->default_boot_order = "cdn";
     mc->kvm_type = spapr_kvm_type;
     mc->has_dynamic_sysbus = true;