[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Configuring pflash devices for OVMF firmware
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] Configuring pflash devices for OVMF firmware |
Date: |
Thu, 07 Feb 2019 14:49:25 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Laszlo Ersek <address@hidden> writes:
> Hi Markus,
>
> On 02/07/19 10:30, Markus Armbruster wrote:
>> The thread got long, let me try to summarize, and elaborate a few
>> points.
>>
>> * The problem at hand is configuring firmware residing in flash memory
>> (OVMF requires this) without legacy -drive.
>>
>> * The wider problem is configuring onboard devices. Our general device
>> configuration interface doesn't cover them. Instead, we have a zoo of
>> ad hoc interfaces that are much more limited. Some of them we'd
>> rather deprecate (-drive, -net), but can't until we have a suitable
>> replacements.
>>
>> I think a board should be a composite object that exposes properties
>> of its own and its parts, just like other composite devices, so that
>> "create, set properties, realize" just works. That would extend our
>> common device configuration mechanism naturally to onboard devices.
>>
>> A PC board's flash memory device would be just another part. It could
>> be something like /machine/q35/cfi.pflash01/ in the QOM tree. To
>> configure it, you'd set its properties, such as
>> /machine/q35/cfi.pflash01/drive.
>>
>> Note that this requires a way to set an existing device's properties.
>> Perhaps qom-set already works.
>>
>> * While I do believe we should tackle the wider problem, I'd rather not
>> sit on the narrow problem until we crack it. So, what can we do about
>> it?
>>
>> - Paolo proposed to add block backend properties to the PC machine,
>> settable like -machine pflash0=BLOCK-BACKEND.
>>
>> Possible drawback: if we add /machine/q35/pflash0 to the QOM tree
>> now, and later replace it by /machine/q35/cfi.pflash01/drive, we'll
>> have to deal with yet another machine type variation. We'll live.
>>
>> - I proposed to sidestep our onboard device configuration problem by
>> adding the cfi.pflash01 devices with our existing general device
>> configuration interface: -device. Possible since the onboard
>> cfi.pflash01 devices are optional. Requires a small extension to
>> the firmware descriptors, and a bit of extra work in libvirt to
>> process that extension. I think it's workable, but Paolo's idea is
>> simpler.
>>
>> I can give Paolo's idea a try. Objections?
>>
>> * A flash device supporting multiple regions is desirable, because it's
>> what physical hardware has. We currently use multiple flash devices
>> instead. We'll be stuck with them for existing machine types due to
>> guest ABI and migration compatibility.
>>
>> * cfi.pflash01 currently requires users to opt out of "bad, do not use".
>> It should require opt in, to guard against accidental new uses of
>> "bad".
>>
>>
>> PS: Big thanks to László, whose patient guidance helped me map this part
>> of the jungle.
>>
>
> I've read the above carefully.
>
> At the QEMU design level, I don't have any opinion or preference; there
> I simply don't know enough -- and don't suffer from bad decisions enough
> -- to make sensible comments.
>
> Regarding the choice betwen "-machine pflash0=BLOCK-BACKEND" and
> "-device pflash": I don't object to exploring the former first.
>
> I'd just like to note that "-machine pflash0=BLOCK-BACKEND" will also
> require changes to the firmware descriptor schema. Not to the types that
> the schema defines -- and therefore concrete descriptor *documents* that
> already conform to the schema wouldn't be affected --, but to the
> documentation that the schema directs at management applications.
>
> The schema is supposed to specify (in the documentation) QEMU command
> line options for management applications. If we add "-machine
> pflash0=BLOCK-BACKEND", then even if the types in the schema stay the
> same, some mappings to the QEMU cmdline will have to be re-documented.
Good point.
> Of course, that's still easier / less intrusive than changing the types!
> ... Which does make me prefer "-machine pflash0=BLOCK-BACKEND", if I'm
> being honest.
>
> (I hope my followup isn't totally useless. I certainly didn't want to
> ignore your summary.)
Pointing out the need to update these comments is anything but useless.
Thanks!