[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/2] hw/arm/virt: Support firmware configuration
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH 2/2] hw/arm/virt: Support firmware configuration with -blockdev |
Date: |
Fri, 12 Apr 2019 14:35:12 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Philippe Mathieu-Daudé <address@hidden> 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.
[...]
- [Qemu-devel] [PATCH 1/2] pflash_cfi01: New pflash_cfi01_legacy_drive(), (continued)
- [Qemu-devel] [PATCH 1/2] pflash_cfi01: New pflash_cfi01_legacy_drive(), Markus Armbruster, 2019/04/11
- Re: [Qemu-devel] [PATCH 1/2] pflash_cfi01: New pflash_cfi01_legacy_drive(), Laszlo Ersek, 2019/04/11
- Re: [Qemu-devel] [PATCH 1/2] pflash_cfi01: New pflash_cfi01_legacy_drive(), Laszlo Ersek, 2019/04/11
- Re: [Qemu-devel] [PATCH 1/2] pflash_cfi01: New pflash_cfi01_legacy_drive(), Laszlo Ersek, 2019/04/11
- Re: [Qemu-devel] [PATCH 1/2] pflash_cfi01: New pflash_cfi01_legacy_drive(), Markus Armbruster, 2019/04/12
- Re: [Qemu-devel] [PATCH 1/2] pflash_cfi01: New pflash_cfi01_legacy_drive(), Philippe Mathieu-Daudé, 2019/04/12
- Re: [Qemu-devel] [PATCH 1/2] pflash_cfi01: New pflash_cfi01_legacy_drive(), Markus Armbruster, 2019/04/12
- Re: [Qemu-devel] [PATCH 1/2] pflash_cfi01: New pflash_cfi01_legacy_drive(), Laszlo Ersek, 2019/04/12
[Qemu-devel] [PATCH 2/2] hw/arm/virt: Support firmware configuration with -blockdev, Markus Armbruster, 2019/04/11