All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Markus Armbruster" <armbru@redhat.com>,
	Libvirt <libvir-list@redhat.com>,
	"Peter Krempa" <pkrempa@redhat.com>,
	"László Érsek" <lersek@redhat.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	Qemu-block <qemu-block@nongnu.org>
Subject: Re: [Qemu-devel] [libvirt] Configuring pflash devices for OVMF firmware
Date: Mon, 28 Jan 2019 13:06:34 +0000	[thread overview]
Message-ID: <CAFEAcA-jwBhBXQb-SHT=b_Vy5Sq+M2iaMP2XtVn_2HQvzaEoVQ@mail.gmail.com> (raw)
In-Reply-To: <20190128124027.776wwcqrckalvr7x@sirius.home.kraxel.org>

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.
(Migration compat is left as an exercise for the reader :-))

thanks
-- PMM

  reply	other threads:[~2019-01-28 13:06 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 [this message]
2019-01-28 14:55       ` Laszlo Ersek
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='CAFEAcA-jwBhBXQb-SHT=b_Vy5Sq+M2iaMP2XtVn_2HQvzaEoVQ@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=armbru@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=libvir-list@redhat.com \
    --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.