qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Roy Hopkins <roy.hopkins@suse.com>
To: Ani Sinha <anisinha@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Daniel Berrange" <berrange@redhat.com>,
	"Stefano Garzarella" <sgarzare@redhat.com>,
	"Marcelo Tosatti" <mtosatti@redhat.com>,
	"Michael Tsirkin" <mst@redhat.com>,
	"Cornelia Huck" <cohuck@redhat.com>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Sergio Lopez Pascual" <slp@redhat.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Alistair Francis" <alistair@alistair23.me>,
	"Peter Xu" <peterx@redhat.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Igor Mammedov" <imammedo@redhat.com>,
	"Tom Lendacky" <thomas.lendacky@amd.com>,
	"Michael Roth" <michael.roth@amd.com>,
	"Jörg Roedel" <jroedel@suse.com>
Subject: Re: [PATCH v2 06/10] i386/pc_sysfw: Ensure sysfw flash configuration does not conflict with IGVM
Date: Tue, 07 May 2024 15:32:49 +0100	[thread overview]
Message-ID: <2bd15d1f23169ca7effb9803b53c9273132ac4ca.camel@suse.com> (raw)
In-Reply-To: <54875E49-0710-4DD9-A6A6-79BEA4F09EFF@redhat.com>

On Thu, 2024-04-04 at 18:06 +0530, Ani Sinha wrote:
> 
> 
> > On 3 Apr 2024, at 16:41, Roy Hopkins <roy.hopkins@suse.com> wrote:
> > 
> > When using an IGVM file the configuration of the system firmware is
> > defined by IGVM directives contained in the file. In this case the user
> > should not configure any pflash devices.
> > 
> > This commit skips initialization of the ROM mode when pflash0 is not set
> > then checks to ensure no pflash devices have been configured when using
> > IGVM, exiting with an error message if this is not the case.
> > 
> > Signed-off-by: Roy Hopkins <roy.hopkins@suse.com>
> > ---
> > hw/i386/pc_sysfw.c | 23 +++++++++++++++++++++--
> > 1 file changed, 21 insertions(+), 2 deletions(-)
> > 
> > diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
> > index 3efabbbab2..2412f26225 100644
> > --- a/hw/i386/pc_sysfw.c
> > +++ b/hw/i386/pc_sysfw.c
> > @@ -226,8 +226,13 @@ void pc_system_firmware_init(PCMachineState *pcms,
> >     }
> > 
> >     if (!pflash_blk[0]) {
> > -        /* Machine property pflash0 not set, use ROM mode */
> > -        x86_bios_rom_init(MACHINE(pcms), "bios.bin", rom_memory, false);
> > +        /*
> > +         * Machine property pflash0 not set, use ROM mode unless using
> > IGVM,
> > +         * in which case the firmware must be provided by the IGVM file.
> 
> What if the igvm file does not contain a firmware? Can we have a check for
> that case somewhere and assert if firmware is absent?
> 
I don't think we can easily check for presence of firmware. In fact, using IGVM
means that you can effectively launch a guest without traditional firmware. A
good example of this is if you use IGVM to deploy an SVSM module that is used to
help with guest migration. In this case, the SVSM code would be placed in memory
(by the IGVM directives) and the initial CPU state configured to launch the SVSM
kernel directly.

> > +         */
> > +        if (!cgs_is_igvm(MACHINE(pcms)->cgs)) {
> > +            x86_bios_rom_init(MACHINE(pcms), "bios.bin", rom_memory,
> > false);
> > +        }
> >     } else {
> >         if (kvm_enabled() && !kvm_readonly_mem_enabled()) {
> >             /*
> > @@ -243,6 +248,20 @@ void pc_system_firmware_init(PCMachineState *pcms,
> >     }
> > 
> >     pc_system_flash_cleanup_unused(pcms);
> > +
> > +    /*
> > +     * The user should not have specified any pflash devices when using
> > IGVM
> > +     * to configure the guest.
> > +     */
> > +    if (cgs_is_igvm(MACHINE(pcms)->cgs)) {
> > +        for (i = 0; i < ARRAY_SIZE(pcms->flash); i++) {
> > +            if (pcms->flash[i]) {
> > +                error_report("pflash devices cannot be configured when "
> > +                             "using IGVM");
> > +                exit(1);
> > +            }
> > +        }
> > +    }
> 
> I have not tested this change but looking at pc_system_flash_create() creates
> flash[0] and flash[1] for all cases (well except for isapc machines). So for
> igvm case, would this not cause an exit all the time?
> 
Although the flash devices are created, if they are not configured then they are
removed by the call to pc_system_flash_cleanup_unused() above, meaning that this
check succeeds in the IGVM case.

> > }
> > 
> > void x86_firmware_configure(void *ptr, int size)
> > -- 
> > 2.43.0
> > 
> 

Regards,
Roy


  reply	other threads:[~2024-05-07 14:33 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1712141833.git.roy.hopkins@suse.com>
2024-04-03 11:11 ` [PATCH v2 01/10] meson: Add optional dependency on IGVM library Roy Hopkins
2024-04-16 14:13   ` Daniel P. Berrangé
2024-05-01  8:53     ` Roy Hopkins
2024-04-03 11:11 ` [PATCH v2 02/10] backends/confidential-guest-support: Add IGVM file parameter Roy Hopkins
2024-04-16 13:29   ` Daniel P. Berrangé
2024-04-03 11:11 ` [PATCH v2 03/10] backends/confidential-guest-support: Add functions to support IGVM Roy Hopkins
2024-04-04  8:00   ` Philippe Mathieu-Daudé
2024-04-16 13:31     ` Daniel P. Berrangé
2024-05-07 14:08       ` Roy Hopkins
2024-04-03 11:11 ` [PATCH v2 04/10] backends/igvm: Implement parsing and processing of IGVM files Roy Hopkins
2024-04-04  7:58   ` Philippe Mathieu-Daudé
2024-05-07 14:19     ` Roy Hopkins
2024-04-16 14:05   ` Daniel P. Berrangé
2024-05-07 14:25     ` Roy Hopkins
2024-04-03 11:11 ` [PATCH v2 05/10] i386/pc: Process IGVM file during PC initialization if present Roy Hopkins
2024-04-16 14:19   ` Daniel P. Berrangé
2024-04-03 11:11 ` [PATCH v2 06/10] i386/pc_sysfw: Ensure sysfw flash configuration does not conflict with IGVM Roy Hopkins
2024-04-04 12:36   ` Ani Sinha
2024-05-07 14:32     ` Roy Hopkins [this message]
2024-04-03 11:11 ` [PATCH v2 07/10] i386/sev: Refactor setting of reset vector and initial CPU state Roy Hopkins
2024-04-03 11:11 ` [PATCH v2 08/10] i386/sev: Implement ConfidentialGuestSupport functions for SEV Roy Hopkins
2024-04-16 14:30   ` Daniel P. Berrangé
2024-05-07 14:34     ` Roy Hopkins
2024-04-03 11:11 ` [PATCH v2 09/10] docs/system: Add documentation on support for IGVM Roy Hopkins
2024-04-03 11:11 ` [PATCH v2 10/10] docs/interop/firmware.json: Add igvm to FirmwareDevice Roy Hopkins

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=2bd15d1f23169ca7effb9803b53c9273132ac4ca.camel@suse.com \
    --to=roy.hopkins@suse.com \
    --cc=alistair@alistair23.me \
    --cc=anisinha@redhat.com \
    --cc=berrange@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=imammedo@redhat.com \
    --cc=jroedel@suse.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=michael.roth@amd.com \
    --cc=mst@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sgarzare@redhat.com \
    --cc=slp@redhat.com \
    --cc=thomas.lendacky@amd.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).