Hi, > UEFI guests seem not to be affected in any way, no matter amount of RAM > or CPU model (well, of course, since it's a SeaBIOS commit! :-D What I > mean is that there seems to be nothing in edk2 that induces the same > behavior).
That used to be a problem with UEFI too. > A way of working this around (beside switching to UEFI or to cpu=host) > is to turn on host-phys-bits, e.g., with '<maxphysaddr > mode="passthrough"/>' in the XML. Sounds like the phys-bits of your vcpus is larger than the value the host actually supports. So if the firmware tries to use the whole address space available things break. Both UEFI and SeaBIOS have a similar heuristic to figure whenever they can trust phys-bits or not, and those checks consider upstream qemu behavior (use phys-bits=40 for all cpu types except 'host'). When this came up with UEFI the root cause turned out to be that suse qemu derived from upstream qemu. There have been phys-bits values other than 40 which where not valid (i.e. larger than supported by the host). I don't know how that was solved in the end. But given that we see similar problems again with SeaBIOS I suspect it was patched in suse OVMF not suse qemu. > It is, however, a bit impractical to have to do this for all the VMs > that one may have... Especially if they're a lot! :-) I'd actually recommend to run all VMs with host-phys-bits=on (and use host-phys-bits-limit=value if you need phys-bits being equal on all machines of a heterogeneous cluster for live migration compatibility). phys-bits being too big never was a valid configuration. It only happened to work because the firmware was very conservative with address space usage. That strategy became increasingly problematic though. These days GPUs and NPUs can have gigabytes of device memory and equally large pci memory bars ... take care, Gerd
