All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Dominik Dingel <dingel@linux.vnet.ibm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
	qemu-devel@nongnu.org, Anthony Liguori <anthony@codemonkey.ws>,
	Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] [PATCH 01/10] Common: Add a default bootindex for all applicable devices
Date: Sat, 27 Apr 2013 08:44:42 +0300	[thread overview]
Message-ID: <20130427054442.GR16740@redhat.com> (raw)
In-Reply-To: <20130426233424.05aa31d3@BR9TG4T3.de.ibm.com>

On Fri, Apr 26, 2013 at 11:34:24PM +0200, Dominik Dingel wrote:
> On Fri, 26 Apr 2013 22:13:14 +0300
> Gleb Natapov <gleb@redhat.com> wrote:
> 
> > On Fri, Apr 26, 2013 at 01:55:23PM -0500, Anthony Liguori wrote:
> > > Dominik Dingel <dingel@linux.vnet.ibm.com> writes:
> > > 
> > > > On Fri, 26 Apr 2013 11:36:11 -0500
> > > > Anthony Liguori <anthony@codemonkey.ws> wrote:
> > > >
> > > >> Dominik Dingel <dingel@linux.vnet.ibm.com> writes:
> > > >> 
> > > >> > Currently only devices with a positive boot index will be pushed in the
> > > >> > fw_boot_order queue, so if no boot index at all will be specified,
> > > >> > the queue ends up empty.
> > > >> >
> > > >> > Instead we push exactly as docs/bootindex.txt says the devices with
> > > >> > the lowest possible boot priority at the tail of the queue,
> > > >> > because we give them the highest available boot index.
> > > >> >
> > > >> > Signed-off-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
> > > >> 
> > > >> Wouldn't this break the ability to say: "don't every try to boot from
> > > >> this device?"
> > > >> 
> > > >> As an example, some people want to force PXE boot to not be tried on
> > > >> certain networks.
> > > >> 
> > > >> Regards,
> > > >> 
> > > >> Anthony Liguori
> > > >
> > > > That is correct, hmm. The thing is, if we don't submit a bootindex, we
> > > > will assign -1 in virtio-blk and virtio-net. This would forbid that
> > > > the device would be booted from. 
> > > > Where docs/bootindex.txt says: if a device got no bootindex, it gets
> > > > the lowest possibly priority... 
> > > >
> > > > One way to fix this, would be to change the behaviour for virtio-blk
> > > > and virtio-net, if there is no boot value assigned to, give it the
> > > > possible highest number. 
> > > >
> > > > Would be this okay for you Anthony?
> > > 
> > > CC'ing Gleb since he introduced bootindex.
> > > 
> > This will break "strict" boot option. It makes firmware boot only
> > from a device with specified boot priority.
> > 
> > What problem the patch is trying to fix?
> 
> virtio-blk and virtio-net devices will be excluded from the boot order if they don't get a boot index on commandline, which is exactly the opposite of what docs/bootindex.txt describes.  
> 
That is up to firmware whether to exclude something from boot order or
not is "strict" boot option is not set. If "strict" is used excluding
devices without bootindex is a desirable behaviour. If docs/bootindex.txt
does not makes it clear (and I agree, it does not) it should be fixed.

> > > The challenge here is we have two mechanisms on x86.
> > > 
> > > If there are no devices specified by boot index, then we follow the CMOS
> > > bits that include "boot from first hard disk".  The firmware can
> > > enumerate hard disks on its own (including virtio-blk devices) and the
> > > user can reorder this list within the firmware.
> > > 
> > > So we don't need to explicitly set bootindex on x86 to get the behavior
> > > your trying to replicate on s390 (boot from first hard disk).  We get it
> > > through our CMOS fallback.
> > IIRC even if CMOS will not specify the boot order Seabios will use its
> > own defaults. Firmware enumerates bootable devices anyway and may have
> > its own logic to find the one to boot from. For instance the first
> > bootable device that is found.
> 
> But wouldn't that prevent any kind of boot protection for like pxe boot? If the network would be the first boot device?
> 
You can implement whatever logic you like. Seabios default boot order is floppy,cdrom,disk,net.

> Maybe someone should check if docs/bootindex.txt is up to date? With all the changes in the code flow.
Definitely.

> 
> If I see it correctly we have three cases for a boot device: 
> - boot index <= 0, should mean from 0 to x this is your position in the boot ordering
> - boot index > 0, should mean don't you dare to try to boot from this device
> 
> - no boot index at all, the doc says: boot, but with no priority 
> 			    code says: don't boot
> 
No. This is not how it is now.

All devices with non negative bootindex are tries first in order of
bootindex. If strict option is specified boot process stops here, otherwise
firmware tries to boot from remaining bootable devices in whatever order
firmware deems best.

> Both ways are fine, but should be in sync. This is currently a complete focus on s390 as for x and p I'm not quite sure what the firmware can do after all happend.
> 
> Dominik
> 
> > > 
> > > I think defaulting all bootable devices to something other than -1 (for
> > > instance, UINT_MAX) would be okay provided that we used globals to use
> > > the old behavior with older machine types.
> > > 
> > > Regards,
> > > 
> > > Anthony Liguori
> > > 
> > > >
> > > > Dominik
> > > >  
> > > >> >
> > > >> > diff --git a/vl.c b/vl.c
> > > >> > index 6caa5f4..84d7031 100644
> > > >> > --- a/vl.c
> > > >> > +++ b/vl.c
> > > >> > @@ -248,7 +248,7 @@ struct FWBootEntry {
> > > >> >      char *suffix;
> > > >> >  };
> > > >> >  
> > > >> > -static QTAILQ_HEAD(, FWBootEntry) fw_boot_order =
> > > >> > +static QTAILQ_HEAD(FWBootOrder, FWBootEntry) fw_boot_order =
> > > >> >      QTAILQ_HEAD_INITIALIZER(fw_boot_order);
> > > >> >  
> > > >> >  int nb_numa_nodes;
> > > >> > @@ -1213,10 +1213,21 @@ void add_boot_device_path(int32_t bootindex, DeviceState *dev,
> > > >> >      FWBootEntry *node, *i;
> > > >> >  
> > > >> >      if (bootindex < 0) {
> > > >> > -        return;
> > > >> > +        bootindex = INT32_MAX;
> > > >> > +        if (!QTAILQ_EMPTY(&fw_boot_order) &&
> > > >> > +           (QTAILQ_LAST(&fw_boot_order, FWBootOrder)->bootindex == INT32_MAX)) {
> > > >> > +            /* there is a device at the end of the queue, so we need to walk
> > > >> > +               the queue reverse to get the next free bootindex */
> > > >> > +            QTAILQ_FOREACH_REVERSE(i, &fw_boot_order, FWBootOrder, link) {
> > > >> > +                if (i->bootindex != bootindex) {
> > > >> > +                    break;
> > > >> > +                }
> > > >> > +                bootindex--;
> > > >> > +            }
> > > >> > +        }
> > > >> >      }
> > > >> >  
> > > >> > -    assert(dev != NULL || suffix != NULL);
> > > >> > +    assert(dev != NULL || suffix != NULL || bootindex >=  0);
> > > >> >  
> > > >> >      node = g_malloc0(sizeof(FWBootEntry));
> > > >> >      node->bootindex = bootindex;
> > > >> > -- 
> > > >> > 1.7.9.5
> > > >> 
> > 
> > --
> > 			Gleb.
> > 

--
			Gleb.

  reply	other threads:[~2013-04-27  5:45 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-26 12:12 [Qemu-devel] [PATCH 00/10] S390: Enhance s390 BIOS to enable bootdevice selection Dominik Dingel
2013-04-26 12:12 ` [Qemu-devel] [PATCH 01/10] Common: Add a default bootindex for all applicable devices Dominik Dingel
2013-04-26 15:19   ` Alexander Graf
2013-04-26 16:36   ` Anthony Liguori
2013-04-26 18:01     ` Dominik Dingel
2013-04-26 18:55       ` Anthony Liguori
2013-04-26 19:13         ` Gleb Natapov
2013-04-26 21:34           ` Dominik Dingel
2013-04-27  5:44             ` Gleb Natapov [this message]
2013-04-26 19:38       ` Christian Borntraeger
2013-04-26 12:12 ` [Qemu-devel] [PATCH 02/10] Common: Add quick access to first boot device Dominik Dingel
2013-04-26 16:37   ` Anthony Liguori
2013-04-26 12:12 ` [Qemu-devel] [PATCH 03/10] S390: Check Bootdevice Type Dominik Dingel
2013-04-26 15:22   ` Alexander Graf
2013-04-26 15:36     ` Dominik Dingel
2013-04-26 15:42     ` Christian Borntraeger
2013-04-26 15:48       ` Alexander Graf
2013-04-26 16:01         ` Christian Borntraeger
2013-04-26 16:05           ` Alexander Graf
2013-04-26 16:10             ` Dominik Dingel
2013-04-26 16:13               ` Alexander Graf
2013-04-26 16:11             ` Christian Borntraeger
2013-04-26 16:13               ` Alexander Graf
2013-04-26 16:45                 ` Anthony Liguori
2013-04-26 16:04         ` Dominik Dingel
2013-04-26 16:07           ` Alexander Graf
2013-04-26 16:50   ` Alexander Graf
2013-04-26 12:12 ` [Qemu-devel] [PATCH 04/10] S390: check if BIOS is available and create links Dominik Dingel
2013-04-26 15:23   ` Alexander Graf
2013-04-26 15:48     ` Dominik Dingel
2013-04-26 15:57       ` Alexander Graf
2013-04-26 16:20         ` Dominik Dingel
2013-04-26 16:22           ` Alexander Graf
2013-04-26 16:38         ` Anthony Liguori
2013-04-26 18:03           ` Dominik Dingel
2013-04-26 18:04             ` Alexander Graf
2013-04-26 12:12 ` [Qemu-devel] [PATCH 05/10] s390-ccw.img: Detect devices with stsch Dominik Dingel
2013-04-26 12:12 ` [Qemu-devel] [PATCH 06/10] s390-ccw.img: Enhance drain_irqs() Dominik Dingel
2013-04-26 12:12 ` [Qemu-devel] [PATCH 07/10] s390-ccw.img: Rudimentary error checking Dominik Dingel
2013-04-26 12:12 ` [Qemu-devel] [PATCH 08/10] s390-ccw.img: Get queue config from host Dominik Dingel
2013-04-26 12:12 ` [Qemu-devel] [PATCH 09/10] S390: Pass per-device loadparm values for CCW blk and net devs Dominik Dingel
2013-04-26 16:52   ` Alexander Graf
2013-04-26 18:08     ` Dominik Dingel
2013-04-26 18:14       ` Alexander Graf
2013-04-26 19:54         ` Christian Borntraeger
2013-04-26 12:12 ` [Qemu-devel] [PATCH 10/10] S390: Enabling device and program selection Dominik Dingel
2013-04-26 15:29   ` Alexander Graf
2013-04-26 16:56   ` Alexander Graf
2013-04-26 17:55     ` Dominik Dingel
2013-04-26 17:56       ` Alexander Graf
2013-04-26 16:19 ` [Qemu-devel] [PATCH 00/10] S390: Enhance s390 BIOS to enable bootdevice selection Alexander Graf
2013-04-26 16:22   ` Dominik Dingel

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=20130427054442.GR16740@redhat.com \
    --to=gleb@redhat.com \
    --cc=agraf@suse.de \
    --cc=anthony@codemonkey.ws \
    --cc=borntraeger@de.ibm.com \
    --cc=dingel@linux.vnet.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.