All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Bernhard Kohl <bernhard.kohl@nsn.com>
Cc: "Ostler, Thomas (NSN - DE/Munich)" <thomas.ostler@nsn.com>,
	qemu-devel@nongnu.org,
	ext Chris Krumme <chris.krumme@windriver.com>
Subject: [Qemu-devel] Re: [PATCH] new parameter boot=on|off for "-net nic" and "-device" NIC devices
Date: Tue, 21 Sep 2010 16:52:36 +0200	[thread overview]
Message-ID: <20100921145236.GA11337@redhat.com> (raw)
In-Reply-To: <4C98BED0.2040406@nsn.com>

On Tue, Sep 21, 2010 at 04:18:56PM +0200, Bernhard Kohl wrote:
> Am 19.09.2010 18:07, schrieb ext Michael S. Tsirkin:
> >On Tue, Sep 14, 2010 at 05:46:55PM +0200, Bernhard Kohl wrote:
> >>>  This patch was motivated by the following use case: In our system
> >>>  the VMs usually have 4 NICs, any combination of virtio-net-pci and
> >>>  pci-assign NIC devices. The VMs boot via gPXE preferably over the
> >>>  pci-assign devices.
> >>>  >  There is no way to make this working with a combination of
> >>the
> >>>  current options -net -pcidevice -device -optionrom -boot.
> >>>  >  With the parameter boot=off it is possible to avoid
> >>loading
> >>>  and using gPXE option ROMs either for old style "-net nic" or
> >>>  for "-device" NIC devices. So we can select which NIC is used
> >>>  for booting.
> >>>  >  A side effect of the boot=off parameter is that unneeded
> >>ROMs
> >>>  which might waste memory are not longer loaded. E.g. if you have
> >>>  2 virtio-net-pci and 2 pci-assign NICs in sum 4 option ROMs are
> >>>  loaded and the virtio ROMs take precedence over the pci-assign
> >>>  ROMs. The BIOS uses the first gPXE ROM which it finds and only
> >>>  needs one of them even if there are more NICs of the same type.
> >>>  >  Without using the boot=on|off parameter the current
> >>behaviour
> >>>  does not change.
> >>>  >  Signed-off-by: Thomas Ostler<thomas.ostler@nsn.com>
> >>>  Signed-off-by: Bernhard Kohl<bernhard.kohl@nsn.com>
> >I think this is useful, however:
> >
> >- We have bit properties which handle parsing on/off
> >   and other formats automatically. Please don't use string.
> >- boot is not a great property name for PCI: what
> >   you actually do is disable option rom.
> >   So maybe call it 'rom' or something like that?
> Our main goal is to select a certain NIC's option rom for booting.
> So the other roms are not needed and not loaded. We used 'boot'
> as the property name as it is similar as in the '-drive' option to
> select a certain disk for booting. What's about to call it 'bootrom'?

Sounds good.

> >- given you have added a property, it can now
> >   be changed with -device. and visible in -device ?
> >   This also has an advantage of only applying to pci devices
> >   (-net option would appear to apply to non-pci but have no effect).
> >   Please do not add more flag parsing in qdemu-options, net and vl.c
> I think it is OK that we don't support this new feature for the old
> style '-net' option and only implement it for qdev / -device?


I think so, too.

> >To summarize, just add a qdev bit option and check
> >the bit.
> >
> In general, we will rework the patch and use all new qdev features.
> There are also some memory leaks as Chris told us, because of the
> usage of strdup.
> 
> This rework might take 2 weeks because of vacation.
> 
> Thanks
> Bernhard

Sounds good.

-- 
MST

  reply	other threads:[~2010-09-21 14:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-14 15:46 [Qemu-devel] [PATCH] new parameter boot=on|off for "-net nic" and "-device" NIC devices Bernhard Kohl
2010-09-19 16:07 ` [Qemu-devel] " Michael S. Tsirkin
2010-09-21 14:18   ` Bernhard Kohl
2010-09-21 14:52     ` Michael S. Tsirkin [this message]
2010-09-21 15:19     ` Anthony Liguori
2010-09-21 15:16   ` Anthony Liguori
2010-09-21 15:31     ` Michael S. Tsirkin

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=20100921145236.GA11337@redhat.com \
    --to=mst@redhat.com \
    --cc=bernhard.kohl@nsn.com \
    --cc=chris.krumme@windriver.com \
    --cc=qemu-devel@nongnu.org \
    --cc=thomas.ostler@nsn.com \
    /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.