[svsm-devel] Launch coconut-svsm using IGVM
Roy Hopkins
roy.hopkins at suse.com
Wed Apr 3 15:13:54 CEST 2024
On Thu, 2024-03-28 at 18:06 +0000, Claudio Siqueira de Carvalho wrote:
> On Thu, 2024-03-28 at 11:54 -0500, Tom Lendacky wrote:
> > On 3/27/24 16:49, Tom Lendacky wrote:
> > > On 2/9/24 09:51, Jörg Rödel wrote:
> > > > Hi Claudio,
> > > >
> > > > On Fri, Feb 09, 2024 at 02:46:03PM +0000, Claudio Siqueira de Carvalho
> > > > wrote:
> > > > > I was doing some research on IGVM, but I did not find any example.
> > > > > Does
> > > > > anybody
> > > > > have an example of an IGVM file and a QEMU command line that I could
> > > > > use to
> > > > > launch the coconut-svsm?
> > > > >
> > > > > This might be helpful for other people too.
> > > >
> > > > The COCONUT build process will generate two IGVM files, one for use with
> > > > QEMU and one for use with Hyper-V.
> > > >
> > > > To use it with QEMU, you need an IGVM-enabled QEMU, instructions on how
> > > > to get one can be found in here:
> > > >
> > > >
> > > > https://github.com/roy-hopkins/svsm/blob/igvm_install_doc/Documentation/IN
> > > > STALL.md
> > > >
> > > > This is a file from Roy's pending PR on updating the documentation for
> > > > the IGVM switch.
> > >
> > > I just tried building everything fresh on a new system based on the
> > > installation instructions and can't get the firmware to launch. Doing some
> > > debugging, the firmware loading appears to be off by a page (0x1000). In
> > > other words, the code that should be at the CS:RIP 0xfffffff0 is actually
> > > located at 0xffffeff0, with all 0's at 0xfffffff0.
> > >
> > > I don't have a full grasp on the Qemu IGVM support to understand if it is
> > > the IGVM file that is built wrong or the Qemu IGVM support that ends up
> > > off by a page. It appears that the firmware is handled as the last item in
> > > igvm_process() and if process_mem_page() is invoked with "i - 1" instead
> > > of "i", then the firmware begins booting.
> >
> > Just to supply a bit more info, the failing launch ends with the following:
> >
> > ...
> > [SVSM] Launching Firmware
> > [SVSM] Launching request-processing task on CPU 0
> > qemu-system-x86_64: warning: memory fault: GPA 0x0 size 0x1000 flags 0x8
> > qemu-system-x86_64: cpus are not resettable, terminating
> >
> >
> > The following patch to Qemu works around the issue, but I'm unsure if this
> > is a proper fix. The error can either be in Qemu or the IGVM creation
> > process.
>
> I am also having the same problem. If I bisected it right, the problem seems
> to
> be in the igvmbuilder.
>
> https://github.com/coconut-svsm/svsm/issues/311
Sorry for the delay in replying - I missed this over the Easter holidays. I've
responded on the github issue above but replying here for completeness.
The problem was actually caused by a bug in the IGVM handling in QEMU which did
not manifest itself until the SVSM commit Claudio highlighted. I had already
found and fixed it but it was only available in the opensuse/tumbleweed branch.
I've now opened a PR that fixes this amongst other changes which has now been
merged into the coconut `svsm-igvm` branch:
https://github.com/coconut-svsm/qemu/tree/svsm-igvm
Regards,
Roy
>
> Thanks,
> Claudio
>
> >
> > diff --git a/backends/igvm.c b/backends/igvm.c
> > index df663b300b..1923d31ad6 100644
> > --- a/backends/igvm.c
> > +++ b/backends/igvm.c
> > @@ -675,7 +675,7 @@ void igvm_process(ConfidentialGuestSupport *cgs)
> > * to reduce the number of memory regions we create. Make sure the
> > last group is
> > * processed with this call.
> > */
> > - process_mem_page(cgs, i, NULL);
> > + process_mem_page(cgs, i - 1, NULL);
> >
> > QTAILQ_FOREACH(parameter, ¶meter_data, next)
> > {
> >
> > Thanks,
> > Tom
> >
> > >
> > > Thanks,
> > > Tom
> > >
> > > >
> > > > Hope that helps.
> > > >
> > > > Regards,
> > > >
> > > > Joerg
More information about the Svsm-devel
mailing list