[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, &parameter_data, next)
> >       {
> > 
> > Thanks,
> > Tom
> > 
> > > 
> > > Thanks,
> > > Tom
> > > 
> > > > 
> > > > Hope that helps.
> > > > 
> > > > Regards,
> > > > 
> > > >     Joerg



More information about the Svsm-devel mailing list