[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH v1 2/3] qemu: Implement extended loader and nvram

On 08/08/14 14:08, Paolo Bonzini wrote:
> Il 08/08/2014 12:17, Michal Privoznik ha scritto:
>> +        if (loader->nvram) {
>> +            virBufferFreeAndReset(&buf);
>> +            virBufferAsprintf(&buf,
>> +                              "file=%s,if=pflash,format=raw,unit=1",
>> +                              loader->nvram);
>> +
>> +            virCommandAddArg(cmd, "-drive");
>> +            virCommandAddArgBuffer(cmd, &buf);
>> +        }
> Note that other machines may not need unit=1, for example pseries
> doesn't need it (it uses -bios for the firmware, not -drive if=pflash).
>  It would be nice to make this easily configurable.
> Alternatively you could use unit=1 if there is a <loader type='pflash'>
> element, and unit=0 otherwise.  We can then patch QEMU to reject unit=1
> on machines that use -bios + -drive if=pflash,unit=0.
> Laszlo, what happens on x86 with -bios + -drive if=pflash,unit=0?

I checked that earlier (independently of unit=... in the pflash drive).
With -bios, you only change the bios filename:

            case QEMU_OPTION_bios:
                qemu_opts_set(qemu_find_opts("machine"), 0, "firmware",


    bios_name = qemu_opt_get(machine_opts, "firmware");

Code using bios_name is not reached when a pflash drive is present: that
would be old_pc_system_rom_init() in "hw/i386/pc_sysfw.c", but its only
caller, pc_system_firmware_init(), doesn't call it if there's at least
one pflash drive (and you're not running an ISA PC).

... I did find the "firmware" machine property too, but it seems to be
used only on s390x.

So, in total, as long as you run a PCI-enabled PC (esp. i440fx) machine
type, -bios is simply ignored when a pflash drive is present.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]