Philippe Mathieu-Daudé <phi...@redhat.com> writes: > On 4/11/19 3:56 PM, Markus Armbruster wrote: >> The ARM virt machines put firmware in flash memory. To configure it, >> you use -drive if=pflash,unit=0,... and optionally -drive >> if=pflash,unit=1,... >> >> Why two -drive? This permits setting up one part of the flash memory >> read-only, and the other part read/write. It also makes upgrading >> firmware on the host easier. Below the hood, we get two separate >> flash devices, because we were too lazy to improve our flash device >> models to support sector protection. >> >> The problem at hand is to do the same with -blockdev somehow, as one >> more step towards deprecating -drive. >> >> We recently solved this problem for x86 PC machines, in commit >> ebc29e1beab. See the commit message for design rationale. >> >> This commit solves it for ARM virt basically the same way: new machine >> properties pflash0, pflash1 forward to the onboard flash devices' >> properties. Requires creating the onboard devices in the >> .instance_init() method virt_instance_init(). The existing code to >> pick up drives defined with -drive if=pflash is replaced by code to >> desugar into the machine properties. >> >> There are a few behavioral differences, though: >> >> * The flash devices are always present (x86: only present if >> configured) >> >> * Flash base addresses and sizes are fixed (x86: sizes depend on >> images, mapped back to back below a fixed address) >> >> * -bios configures contents of first pflash (x86: -bios configures ROM >> contents) >> >> * -bios is rejected when first pflash is also configured with -machine >> pflash0=... (x86: bios is silently ignored then) > > Can we start deprecating the -bios command line option? > > Maybe on a per-architecture basis first.
I have no idea. Perhaps we want to keep it as syntactic sugar for convenience. Right now it's something else: an ugly special case. Of course, the name -bios is a bit PC-centric. And even there it makes less sense than it used to. [...]
