All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>,
	Gerd Hoffmann <kraxel@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>,
	Libvirt <libvir-list@redhat.com>,
	Peter Krempa <pkrempa@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Qemu-block <qemu-block@nongnu.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [Qemu-devel] [libvirt] Configuring pflash devices for OVMF firmware
Date: Mon, 28 Jan 2019 15:55:54 +0100	[thread overview]
Message-ID: <5daf9f5e-cbda-8642-f4f6-46939fe223d1@redhat.com> (raw)
In-Reply-To: <CAFEAcA-jwBhBXQb-SHT=b_Vy5Sq+M2iaMP2XtVn_2HQvzaEoVQ@mail.gmail.com>

On 01/28/19 14:06, Peter Maydell wrote:
> On Mon, 28 Jan 2019 at 12:40, Gerd Hoffmann <kraxel@redhat.com> wrote:
>> The tricky part is the access control here.  On physical hardware you
>> typically have one flash rom, say 16M below 4G (on x86).
>>
>> Our pflash device doesn't allow to define multiple regions, so we use
>> multiple pflash devices instead, each with different access permissions
>> (code vs. vars).  Because of that they are more dynamic than they are on
>> phyiscal hardware, x86 sizes them according to the size of the firmware
>> images (arm is easier here, we have fixed size and location no matter
>> how big the firmware images are).
>>
>> So I think the options we have are:
>>   (a) leave pflash as-is, which pretty much implies physaddr and size
>>       must be user-configurable.
>>   (b) add support for multiple regions to pflash, so one can attach
>>       multiple blockdev at different offsets to a single pflash device.
> 
> The latter makes more sense to me -- we should model what the
> hardware actually has, because the guest can tell the difference.

Regarding OVMF, I kept the flash driver intentionally in the dark about
split vs. unified pflash, so OVMF will not care, as long as the same
GPAs behave the same as before.

Regarding ArmVirtQemu, I'm not so sure. It think it already depends on
two separate pflash chips, through the DTB that QEMU exposes. So
unifying the chips (albeit with multiple regions) might actually confuse
the firmware. I'm CC'ing Ard, he's done some work on the ARM NOR flash
driver recently, incl. updates to its usage in ArmVirtQemu:

* https://github.com/tianocore/edk2/commit/5e27deed438b

  [edk2] [PATCH v2 3/4]
  ArmVirtPkg/NorFlashQemuLib: disregard our primary FV

* https://github.com/tianocore/edk2/commit/51bb05c79595

  [edk2] [PATCH v2 4/4]
  ArmVirtPkg/QemuVirtMemInfoLib: trim the MMIO region mapping

Thanks
Laszlo

> (Migration compat is left as an exercise for the reader :-))
> 
> thanks
> -- PMM
> 

  reply	other threads:[~2019-01-28 15:09 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-25 15:03 [Qemu-devel] Configuring pflash devices for OVMF firmware Markus Armbruster
2019-01-28  7:58 ` Laszlo Ersek
2019-01-28 10:39 ` Peter Maydell
2019-01-28 12:40   ` [Qemu-devel] [libvirt] " Gerd Hoffmann
2019-01-28 13:06     ` Peter Maydell
2019-01-28 14:55       ` Laszlo Ersek [this message]
2019-01-28 14:58         ` Peter Maydell
2019-01-28 15:03           ` Laszlo Ersek
2019-01-30  7:36       ` Markus Armbruster
2019-01-30  8:00         ` Gerd Hoffmann
2019-01-30  7:24   ` [Qemu-devel] " Markus Armbruster
2019-01-30 15:24     ` Peter Maydell
2019-01-30 16:44       ` Laszlo Ersek
2019-01-30 17:24         ` Peter Maydell
2019-01-31  8:52           ` Markus Armbruster
2019-01-31 10:01             ` Peter Maydell
2019-01-31 10:24               ` Markus Armbruster
2019-01-31 10:34                 ` Peter Maydell
2019-01-31 12:05                   ` Markus Armbruster
2019-01-30 14:13   ` Markus Armbruster
2019-01-30 14:33     ` Paolo Bonzini
2019-01-30 16:38       ` Laszlo Ersek
2019-01-31  8:33         ` Markus Armbruster
2019-01-31  9:19           ` Paolo Bonzini
2019-01-31  9:37             ` Markus Armbruster
2019-01-31 12:02               ` Laszlo Ersek
2019-01-31 12:10               ` Paolo Bonzini
2019-01-31 12:51                 ` Markus Armbruster
2019-01-31  8:40       ` Markus Armbruster
2019-01-31  9:19         ` Paolo Bonzini
2019-01-31  9:41           ` Markus Armbruster
2019-01-31 10:12             ` Paolo Bonzini
2019-01-31 12:12               ` Markus Armbruster
2019-01-31 22:57                 ` Paolo Bonzini
2019-01-31 23:28                   ` Alexandro Sanchez Bach
2019-01-31 23:54                     ` Paolo Bonzini
2019-02-01  2:49                       ` Ning, Yu
2019-02-04 10:00                         ` Paolo Bonzini
2019-02-01  8:58                   ` Markus Armbruster
2019-01-31 11:57           ` Laszlo Ersek
2019-02-19  7:19       ` Markus Armbruster
2019-02-22 13:28         ` Markus Armbruster
2019-02-07  9:30 ` Markus Armbruster
2019-02-07 12:31   ` Laszlo Ersek
2019-02-07 13:49     ` Markus Armbruster

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=5daf9f5e-cbda-8642-f4f6-46939fe223d1@redhat.com \
    --to=lersek@redhat.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=armbru@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=pkrempa@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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.