qemu-riscv
[Top][All Lists]
Advanced

[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:45:18 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Wed, Nov 09, 2022 at 04:26:53PM +0100, Markus Armbruster wrote:
>> 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?
>
> Is (C) actually a separate issue ?  I thought it was simply the
> result of (B) ?  ie if we skip reading the zero padding, we won't
> be dirtying the memory with lots of zeros. we'll have mmap'd the
> full 64 MB, but most won't be paged in since we wouldn't write
> the zeros to it. Only if the guest writes to those areas do we
> need to then flush it back out.

I expressed myself poorly.  All three are related, but there's still a
distinction between each of them in my thinking.

Say we use an image format that compresses data.  Represents the padding
efficiently.  Storage on disk is efficient (A), and so is reading it
(B).  Trouble is decompressing it to memory dirties the memory unless we
take care not to write all-zero pages (C).

Clearer now?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]