qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Bernhard Kohl <bernhard.kohl@nsn.com>
To: "ext Michael S. Tsirkin" <mst@redhat.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:18:56 +0200	[thread overview]
Message-ID: <4C98BED0.2040406@nsn.com> (raw)
In-Reply-To: <20100919160759.GB10730@redhat.com>

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'?
> - 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?
> 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

  reply	other threads:[~2010-09-21 14:19 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 [this message]
2010-09-21 14:52     ` Michael S. Tsirkin
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=4C98BED0.2040406@nsn.com \
    --to=bernhard.kohl@nsn.com \
    --cc=chris.krumme@windriver.com \
    --cc=mst@redhat.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 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).