Peter Maydell <peter.maydell@xxxxxxxxxx> writes: > On Mon, 28 Jan 2019 at 12:40, Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: >> The tricky part is the access control here. On physical hardware you >> typically have one flash rom, say 16M below 4G (on x86). >> >> Our pflash device doesn't allow to define multiple regions, so we use >> multiple pflash devices instead, each with different access permissions >> (code vs. vars). Because of that they are more dynamic than they are on >> phyiscal hardware, x86 sizes them according to the size of the firmware >> images (arm is easier here, we have fixed size and location no matter >> how big the firmware images are). >> >> So I think the options we have are: >> (a) leave pflash as-is, which pretty much implies physaddr and size >> must be user-configurable. >> (b) add support for multiple regions to pflash, so one can attach >> multiple blockdev at different offsets to a single pflash device. > > The latter makes more sense to me -- we should model what the > hardware actually has, because the guest can tell the difference. No argument. > (Migration compat is left as an exercise for the reader :-)) It's not just migration compatibility, it's also guest ABI: "the guest can tell the difference". So, old machine types continue to get two flash devices, and new machine types get one. In other words, we're stuck maintaining (a) even if we decide to switch to (b). By itself, not an argument against doing the right thing for new machine types. It's an argument for trying harder doing the right thing from the start next time. I'm not sure whether doing the right thing now is worthwhile from a practical point of view. I figure the need for a region-capable flash device model may well come up again in contexts other than PC firmware. Perhaps we should discount the cost of creating it when weighing the tradeoff for PC. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
