All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
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:40:27 +0100	[thread overview]
Message-ID: <20190128124027.776wwcqrckalvr7x@sirius.home.kraxel.org> (raw)
In-Reply-To: <CAFEAcA9b+7m1hL9atdm2_0fq66HPGWDhpAfZCRfPbegr2hKyGg@mail.gmail.com>

  Hi,

> > Issue (1) isn't too hard: we add the device to the dynamic sysbus device
> > white-list, move a sysbus_mmio_map() from pflash_cfi01_realize() into
> > pflash_cfi01_realize().  The latter requires a new device property to
> > configure the base address.  I got a working prototype.  Since this
> > makes the device model's name and properties ABI, review would be
> > advisable.
> 
> Flash devices exist on the board at specific addresses, so they
> should in general be created by the board model. Creating them
> by the user on the command line is a mess because then the
> user has to know the right base address. And then the board
> code needs to do something for "if the user didn't create this
> then we need to do it", because the flash device should exist
> in the model whether the user cared about its contents or not.

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.

cheers,
  Gerd

  reply	other threads:[~2019-01-28 12:40 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   ` Gerd Hoffmann [this message]
2019-01-28 13:06     ` [Qemu-devel] [libvirt] " Peter Maydell
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=20190128124027.776wwcqrckalvr7x@sirius.home.kraxel.org \
    --to=kraxel@redhat.com \
    --cc=armbru@redhat.com \
    --cc=lersek@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.