All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: stappers@stappers.nl, "Alex Bennée" <alex.bennee@linaro.org>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2] hw/block: report when pflash backing file isn't aligned
Date: Mon, 18 Feb 2019 12:56:37 +0100	[thread overview]
Message-ID: <36adf8c8-009e-dc91-475b-c3cbf34fbd21@redhat.com> (raw)
In-Reply-To: <87tvh4t1v7.fsf@dusky.pond.sub.org>

On 02/16/19 12:21, Markus Armbruster wrote:
> Laszlo Ersek <lersek@redhat.com> writes:
>> On 02/15/19 17:01, Markus Armbruster wrote:

>>> Using whatever size the image has is sloppy modelling.
>>
>> Maybe so, but it's also very convenient, and also quite important, right
>> now (given the multiple firmware image sizes used in the wild).
>>
>>> A machine may come in minor variations that aren't worth their own
>>> machine type.  One such variation could be a different flash chip size.
>>> Using the image size to select one from the set of fixed sizes is
>>> tolerable.
>>
>> The problem is that this requires coordination between QEMU and firmware
>> development.
>>
>> (Well, I have to agree that the present patch is *already* that kind of
>> coordination;
> 
> We've always had that kind of coordination.  It just happens to be less
> tight in the case of PC firmware in flash than in most other cases.
> 
>>               my point is that when I introduced the 4MB build for OVMF,
>> I didn't have to touch QEMU. In retrospect, I'm extremely thankful for
>> that, as the introduction of the 4MB build was difficult in itself.)
> 
> You don't actually need "flash size is whatever the image size is" for
> that.  "Use image size to select one from the set of fixed sizes" should
> suffice.
> 
> Actually, the PC machines currently comply, just with a rather large
> set: { n * 4KiB | 1 <= n <= 2048 }.
> 
> I very much doubt PC firmware sizes other than powers of two between
> 64KiB and 8MiB matter.  Have you ever seen real flash chips with sizes
> like 64140KiB?

Honestly, I wouldn't know. I haven't seen any physical flash chip (as
in, directing my gaze at it). I also don't know what the usual flash
chip sizes are on physical boards (e.g. I have no clue what my laptop uses).

I think a jump from 4MB to 8MB would be too large. It gives too much of
sudden convenience to firmware developers. I do agree "7MB" looks quite
lame. I really wonder about the flash sizes used on physical UEFI boards.

Thanks,
Laszlo

  reply	other threads:[~2019-02-18 11:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-15 12:28 [Qemu-devel] [PATCH v2] hw/block: report when pflash backing file isn't aligned Alex Bennée
2019-02-15 14:08 ` Laszlo Ersek
2019-02-15 16:01   ` Markus Armbruster
2019-02-15 16:59     ` Markus Armbruster
2019-02-16 17:53       ` Markus Armbruster
2019-02-15 22:48     ` Laszlo Ersek
2019-02-16 11:21       ` Markus Armbruster
2019-02-18 11:56         ` Laszlo Ersek [this message]
2019-02-21 14:57       ` Alex Bennée

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=36adf8c8-009e-dc91-475b-c3cbf34fbd21@redhat.com \
    --to=lersek@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=armbru@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stappers@stappers.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.