On Tue, Mar 22, 2022 at 10:21:41AM +0100, Gerd Hoffmann wrote: > Hi, > > > > If you don't need a pflash device, don't use it: simply map your nvram > > > region as ram in your machine. No need to clutter the pflash model like > > > that. > > Using the pflash device for something which isn't actually flash looks a > bit silly indeed. > > > > > I know it's dirty to hack the pflash device. The purpose is to make the user > > interface unchanged that people can still use > > > > -drive if=pflash,format=raw,unit=0,file=/path/to/OVMF_CODE.fd > > -drive if=pflash,format=raw,unit=1,file=/path/to/OVMF_VARS.fd > > > > to create TD guest. > > Well, if persistent vars are not supported anyway there is little reason > to split the firmware into CODE and VARS files. You can use just use > OVMF.fd with a single pflash device. libvirt recently got support for > that. Agreed. > 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. 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. 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 :|
