On Tue, Mar 22, 2022 at 11:35:18AM +0100, Gerd Hoffmann wrote: > Hi, > > > > Just using -bios OVMF.fd might work too. Daniel tried that recently for > > > sev, but ran into problems with wiring up ovmf metadata parsing for > > > -bios. Don't remember the details though. > > > > It was related to the BIOS shadowing, whereby QEMU loads it at one > > address, and then when CPUs start it is copied to another address. > > Is this the top 128k of the firmware being copied below 1M so the > firmware reset vector is available in real mode address space? It was the 'rom_reset' method in hw/core/loader.c that was involved in the root of the problem, copying the firmware from ROM to RAM. At the time I did try a gross hack that (IIRC) disabled the rom_reset logic, and munged x86_bios_rom_init so that it would force load it straight at the RAM location. I couldn't figure out an attractive way to make this into something supportable, so abandoned the whole idea. Messing with this area of code is a somewhat beyond my level of understanding of x86 boot process anyway. > > This was not compatible with the way AMD SEV wants to do measurement > > of the firmware. May or may not be relevant for TDX, I don't know > > enough about TDX to say. > > TDX boots in 32bit mode, so simply skipping any real mode compatibility > stuff shouldn't cause any problems here. > > Not sure about SEV. There is this SevProcessorReset entry in the ovmf > metadata block. Is that the SEV reset vector? If SEV cpu bringup > doesn't go through real mode either we maybe can just skip the BIOS > shadowing setup for confidential computing guests ... With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
