[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash
From: |
Markus Armbruster |
Subject: |
Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash |
Date: |
Wed, 09 Nov 2022 16:26:53 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Daniel P. Berrangé <berrange@redhat.com> writes:
> On Mon, Nov 07, 2022 at 06:32:01PM +0100, Andrew Jones wrote:
[...]
>> Padding is a good idea, but too much causes other problems. When building
>> lightweight VMs which may pull the firmware image from a network,
>> AArch64 VMs require 64MB of mostly zeros to be transferred first, which
>> can become a substantial amount of the overall boot time[*]. Being able to
>> create images smaller than the total flash device size, but still add some
>> pad for later growth, seems like the happy-medium to shoot for.
>
> QEMU configures the firmware using -blockdev,
Yes, even though the devices in question are not block devices.
> so can use any file
> format that QEMU supports at the block layer. IOW, you can store
> the firmware in a qcow2 file and thus you will never fetch any
> of the padding zeros to be transferred. That said I'm not sure
> that libvirt supports anything other than a raw file today.
Here's another idea. The "raw" format supports exposing a slice of the
underlying block node (options @offset and @size). It could support
padding. Writing to the padding should then grow the underlying node.
Taking a step back to look at the bigger picture... there are three
issues, I think:
(A) Storing padding on disk is wasteful.
Use a file system that supports sparse files, or an image format
that can represent the padding efficiently.
(B) Reading padding into memory is wasteful.
Matters mostly when a network is involved. Use an image format that
can represent the padding efficiently.
(C) Dirtying memory for padding is wasteful.
I figure KSM could turn zero-padding into holes.
We could play with mmap() & friends.
Other ideas?
Any solution needs to work both for read-only and read/write padding.
Throwing away data written to the padding on cold restart is not what
I'd regard as "works".
- Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash, (continued)
- Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash, Philippe Mathieu-Daudé, 2022/11/07
- Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash, Sunil V L, 2022/11/07
- Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash, Alex Bennée, 2022/11/07
- Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash, Daniel P . Berrangé, 2022/11/07
- Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash, Andrew Jones, 2022/11/07
- Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash, Daniel P . Berrangé, 2022/11/07
- Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash, Philippe Mathieu-Daudé, 2022/11/08
- Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash, Andrew Jones, 2022/11/08
- Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash, Daniel P . Berrangé, 2022/11/08
- Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash,
Markus Armbruster <=
- Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash, Daniel P . Berrangé, 2022/11/09
- Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash, Markus Armbruster, 2022/11/09
- Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash, Daniel P . Berrangé, 2022/11/09
- Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash, Peter Maydell, 2022/11/07
- Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash, Markus Armbruster, 2022/11/08
- Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash, Sunil V L, 2022/11/09