qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gonglei <arei.gonglei@huawei.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: peter.huangpeng@huawei.com, dvaleev@suse.de,
	Dinar Valeev <dvaleev@suse.com>,
	qemu-devel@nongnu.org, agraf@suse.de
Subject: Re: [Qemu-devel] [PATCH v3 4/4] bootdevice: update boot_order in MachineState
Date: Fri, 13 Feb 2015 10:44:42 +0800	[thread overview]
Message-ID: <54DD651A.2060504@huawei.com> (raw)
In-Reply-To: <87oaoza0qq.fsf@blackfin.pond.sub.org>

On 2015/2/12 18:21, Markus Armbruster wrote:
> <arei.gonglei@huawei.com> writes:
> 
>> From: Dinar Valeev <dvaleev@suse.com>
>>
>> on sPAPR we need to update boot_order in MachineState in case it
>> got changed on reset.
>>
>> Signed-off-by: Dinar Valeev <dvaleev@suse.com>
>> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> Signed-off-by: Gonglei <arei.gonglei@huawei.com>
>> ---
>>  bootdevice.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/bootdevice.c b/bootdevice.c
>> index d3d4277..ac586b1 100644
>> --- a/bootdevice.c
>> +++ b/bootdevice.c
>> @@ -26,6 +26,7 @@
>>  #include "qapi/visitor.h"
>>  #include "qemu/error-report.h"
>>  #include "hw/hw.h"
>> +#include "hw/boards.h"
>>  
>>  typedef struct FWBootEntry FWBootEntry;
>>  
>> @@ -50,6 +51,7 @@ void qemu_register_boot_set(QEMUBootSetHandler *func, void *opaque)
>>  void qemu_boot_set(const char *boot_order, Error **errp)
>>  {
>>      Error *local_err = NULL;
>> +    MachineState *machine = MACHINE(qdev_get_machine());
>>  
>>      validate_bootdevices(boot_order, &local_err);
>>      if (local_err) {
>> @@ -57,6 +59,8 @@ void qemu_boot_set(const char *boot_order, Error **errp)
>>          return;
>>      }
>>  
>> +    machine->boot_order = boot_order;
>> +
>>      if (boot_set_handler) {
>>          boot_set_handler(boot_set_opaque, boot_order, errp);
>>      }
> 
> Looks harmless enough, but I'm afraid I don't quite understand why we
> need this.  Can you explain it to me real slow?  :)
> 
Alex pointed that there is two reset logic for boot order, one is machine struct
(machine->order) and another is set_boot_handler by parameter. But the
qemu_boot_set() only support to use set_boot_handler to set boot order.
So, I decide to remove the check for boot_set_handler if NULL or not (PATCH 1),
and change the value of machine->boot_order in qemu_boot_set().

But I ignored this change cause a regression for HMP command set_boot. To avoid
the regression, we only support one way to set boot_order, that is set_boot_handler.
Fortunately the patches for supporting boot 'once' argument on sPAPR on the flight. We
have the opportunity to drop this change and avoid the regression.

Regards,
-Gonglei

  reply	other threads:[~2015-02-13  2:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-07  7:20 [Qemu-devel] [PATCH v3 0/4] bootdevcie: change the boot order validation logic arei.gonglei
2015-02-07  7:20 ` [Qemu-devel] [PATCH v3 1/4] bootdevice: remove the check about boot_set_handler arei.gonglei
2015-02-12 10:19   ` Markus Armbruster
2015-02-13  2:12     ` Gonglei
2015-02-07  7:20 ` [Qemu-devel] [PATCH v3 2/4] bootdevice: check boot order argument validation before vm running arei.gonglei
2015-02-12 10:19   ` Markus Armbruster
2015-02-13  2:24     ` Gonglei
2015-02-07  7:20 ` [Qemu-devel] [PATCH v3 3/4] bootdevice: add check in restore_boot_order() arei.gonglei
2015-02-07  7:20 ` [Qemu-devel] [PATCH v3 4/4] bootdevice: update boot_order in MachineState arei.gonglei
2015-02-12 10:21   ` Markus Armbruster
2015-02-13  2:44     ` Gonglei [this message]
2015-02-12  7:53 ` [Qemu-devel] [PATCH v3 0/4] bootdevcie: change the boot order validation logic Gonglei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54DD651A.2060504@huawei.com \
    --to=arei.gonglei@huawei.com \
    --cc=agraf@suse.de \
    --cc=armbru@redhat.com \
    --cc=dvaleev@suse.com \
    --cc=dvaleev@suse.de \
    --cc=peter.huangpeng@huawei.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).