On Wed, Mar 22, 2023 at 06:10:18AM -0300, Daniel Henrique Barboza wrote:
Today, trying to boot a RISC-V Fedora Rawhide image in a RISC-V QEMU domain results in the following error:
==== error: Failed to start domain 'riscv-fedora' error: internal error: process exited while connecting to monitor: 2023-03-20T17:31:02.650862Z qemu-system-riscv64: Some ROM regions are overlapping These ROM regions might have been loaded by direct user request or by default. They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory. Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses. ====
This happens because the default RISC-V QEMU firmware, OpenSBI, is always loaded unless "-bios none" is passed in the command line, and the Fedora Rawhide guest kernel has its own ROM. Other machines such as PPC64 'pseries' shows the same behavior: the default firmware is always loaded unless specified otherwise with the '-bios' option.
At this moment we don't have XML support for '-bios none'. Using "<qemu:commandline>" works but it will leave the domain in a tainted state. It'll also have unpredictable consequences with the autoselect firmware feature libvirt has.
Add a new loader type 'none' that, if no path is specified and we're not use firmware autoselection, will tell QEMU that no default firmware should be used:
<os> <loader type='none'/> (...) </os>
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> --- src/conf/domain_conf.c | 5 +++-- src/conf/domain_validate.c | 2 +- src/conf/schemas/domaincommon.rng | 1 + 3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 9ef50c818b..d7a5cd094b 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -16837,7 +16837,7 @@ virDomainLoaderDefParseXMLLoader(virDomainLoaderDef *loader, return -1;
if (virXMLPropEnum(loaderNode, "type", virDomainLoaderTypeFromString, - VIR_XML_PROP_NONZERO, &loader->type) < 0) + VIR_XML_PROP_NONE, &loader->type) < 0) return -1;
if (!(loader->path = virXMLNodeContentString(loaderNode))) @@ -26259,7 +26259,8 @@ virDomainLoaderDefFormat(virBuffer *buf, virBufferAsprintf(&loaderAttrBuf, " secure='%s'", virTristateBoolTypeToString(loader->secure));
- if (loader->type != VIR_DOMAIN_LOADER_TYPE_NONE) + if (loader->type != VIR_DOMAIN_LOADER_TYPE_NONE || + (loader->type == VIR_DOMAIN_LOADER_TYPE_NONE && !loader->path)) virBufferAsprintf(&loaderAttrBuf, " type='%s'", virDomainLoaderTypeToString(loader->type));
VIR_DOMAIN_LOADER_TYPE_NONE is a constant we're already using internally to track when the user has not given any <loader> element at all. It is not a good idea to overload for this for the user explicitly requesting a config. 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 :|