All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: "Eduardo Habkost" <eduardo@habkost.net>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	qemu-devel@nongnu.org,
	"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
	"Dov Murik" <dovmurik@linux.ibm.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [PATCH 2/2] hw/i386: support loading OVMF using -bios too
Date: Mon, 17 Jan 2022 03:53:05 -0500	[thread overview]
Message-ID: <20220117035119-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <66f3f633-3a61-163a-a0f4-622ef988611f@amsat.org>

On Sun, Jan 16, 2022 at 10:05:58PM +0100, Philippe Mathieu-Daudé wrote:
> On 14/1/22 19:07, Michael S. Tsirkin wrote:
> > On Thu, Jan 13, 2022 at 04:55:11PM +0000, Daniel P. Berrangé wrote:
> > > Traditionally the OVMF firmware has been loaded using the pflash
> > > mechanism. This is because it is usually provided as a pair of
> > > files, one read-only containing the code and one writable to
> > > provided persistence of non-volatile firmware variables.
> > > 
> > > The AMD SEV build of EDK2, however, is provided as a single
> > > file that contains only the code. This is intended to be used
> > > read-only and explicitly does not provide any ability for
> > > persistance of non-volatile firmware variables. While it is
> > > possible to configure this with the pflash mechanism, by only
> > > providing one of the 2 pflash blobs, conceptually it is a
> > > little strange to use pflash if there won't be any persistent
> > > data.
> 
> It certainly would be simpler to have a ROM for the CODE part.
> IIUC using CFI pflash allows the firmware to poll the underlying
> device size.
> 
> > > A stateless OVMF build can be loaded with -bios, however, QEMU
> > > does not currently initialize SEV in that scenario. This patch
> > > introduces the call needed for SEV initialization of the
> > > firmware.
> > > 
> > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > > ---
> > >   hw/i386/x86.c | 5 +++++
> > >   1 file changed, 5 insertions(+)
> > > 
> > > diff --git a/hw/i386/x86.c b/hw/i386/x86.c
> > > index b84840a1bb..c79d84936f 100644
> > > --- a/hw/i386/x86.c
> > > +++ b/hw/i386/x86.c
> > > @@ -45,6 +45,7 @@
> > >   #include "target/i386/cpu.h"
> > >   #include "hw/i386/topology.h"
> > >   #include "hw/i386/fw_cfg.h"
> > > +#include "hw/i386/pc.h"
> > >   #include "hw/intc/i8259.h"
> > >   #include "hw/rtc/mc146818rtc.h"
> > >   #include "target/i386/sev.h"
> > 
> > This builds fine because there's a stub in pc_sysfw_ovmf-stubs.c
> > 
> > The unfortunate thing about this however is that it's too easy to pull
> > in a PC dependency, and people building with CONFIG_PC will not notice
> > until it breaks for others.
> > 
> > Is it time we split pc.h further and had pc_sysfw_ovmf.h ?
> 
> While "pc*" is specific to the PC machines, "x86*" is shared between
> PC and microvm. "pc.h" must not be included in "x86.c". The shared
> method introduced in the previous patch becomes
> x86_system_ovmf_initialize_sev(). The dual pflash mechanism is proper
> to OVMF, so having this method in "x86.h" seems correct.
> 
> Phil.

Well.  E.g. pc_system_parse_ovmf_flash is defined in hw/i386/pc_sysfw_ovmf.c
and declared in pc.h. If you want to move all pc_sysfw_ovmf.c
declarations to x86.h that might be fine, but please do not
split declarations between multiple headers, that's messy.
And really, when in doubt do a separate header is a good rule.

-- 
MST



  reply	other threads:[~2022-01-17  8:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-13 16:55 [PATCH 0/2] Improved support for AMD SEV firmware loading Daniel P. Berrangé
2022-01-13 16:55 ` [PATCH 1/2] hw/i386: refactor logic for setting up SEV firmware Daniel P. Berrangé
2022-01-13 16:55 ` [PATCH 2/2] hw/i386: support loading OVMF using -bios too Daniel P. Berrangé
2022-01-14 18:07   ` Michael S. Tsirkin
2022-01-16 21:05     ` Philippe Mathieu-Daudé via
2022-01-17  8:53       ` Michael S. Tsirkin [this message]
2022-01-17  7:34 ` [PATCH 0/2] Improved support for AMD SEV firmware loading Dov Murik
2022-01-17 11:56   ` Daniel P. Berrangé
2022-01-17 12:12   ` Brijesh Singh
2022-01-20 10:15     ` Daniel P. Berrangé

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=20220117035119-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=dovmurik@linux.ibm.com \
    --cc=eduardo@habkost.net \
    --cc=f4bug@amsat.org \
    --cc=kraxel@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.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.