Laszlo Ersek <ler...@redhat.com> writes: > On 11/22/13 13:21, Markus Armbruster wrote: >> Laszlo Ersek <ler...@redhat.com> writes: >> >>> This patch allows the user to usefully specify >>> >>> -drive file=img_1,if=pflash,format=raw,readonly \ >>> -drive file=img_2,if=pflash,format=raw >>> >>> on the command line. The flash images will be mapped under 4G in their >>> reverse unit order -- that is, with their base addresses progressing >>> downwards, in increasing unit order. >>> >>> (The unit number increases with command line order if not explicitly >>> specified.) >>> >>> This accommodates the following use case: suppose that OVMF is split in >>> two parts, a writeable host file for non-volatile variable storage, and a >>> read-only part for bootstrap and decompressible executable code. >>> >>> The binary code part would be read-only, centrally managed on the host >>> system, and passed in as unit 0. The variable store would be writeable, >>> VM-specific, and passed in as unit 1. >>> >>> 00000000ffe00000-00000000ffe1ffff (prio 0, R-): system.flash1 >>> 00000000ffe20000-00000000ffffffff (prio 0, R-): system.flash0 >>> >>> (If the guest tries to write to the flash range that is backed by the >>> read-only drive, bdrv_write() in pflash_update() will correctly deny the >>> write with -EACCES, and pflash_update() won't care, which suits us well.) >> >> Before this patch: >> >> You can define as many if=pflash drives as you want. Any with non-zero >> index are silently ignored. >> >> If you don't specify one with index=0, you get a ROM at the top of the >> 32 bit address space, contents taken from -bios (default "bios.bin"). >> Up to its last 128KiB are aliased at the top of the ISA address space. >> >> If you do specify one with index=0, you get a pflash device at the top >> of the 32 bit address space, with contents from the drive, and -bios is >> silently ignored. Up to its last 128KiB are copied to a ROM at the top >> of the (20 bit) ISA address space. >> >> After this patch (please correct misunderstandings): >> >> Now the drives after the first unused index are silently ignored. >> >> If you don't specify one with index=0, no change. >> >> If you do, you now get N pflash devices, where N is the first unused >> index. Each pflash's contents is taken from the respective drive. The >> flashes are mapped at the top of the 32 bit address space in reverse >> index order. -bios is silently ignored, as before. Up to the last >> 128KiB of the index=0 flash are copied to a ROM at the top of the ISA >> address space. >> >> Thus, no change for index=0. For index=1..N, we now get additional >> flash devices. >> >> Correct? > > Yes.
Thus, we grab *all* if=pflash drives for this purpose. Your stated use case wants just two. Hmm. Are we sure we'll never want to map an if=pflash device somewhere else? I'm asking because such ABI things are a pain to change later on...