On Fri, Apr 14, 2023 at 06:26:02 -0700, Andrea Bolognani wrote: > On Thu, Apr 13, 2023 at 08:23:25AM -0600, Jim Fehlig wrote: > > On 4/6/23 08:27, Andrea Bolognani wrote: > > > On Thu, Apr 06, 2023 at 06:10:11AM -0700, Andrea Bolognani wrote: > > > > In conclusion, there currently doesn't seem to exist a way to define > > > > a useful integratorcp-based VM in libvirt, which IMO means we can > > > > safely change the default machine type for Arm architectures without > > > > any concerns about breaking existing VMs. > > > > > > > > I will look into whether the same can be said for RISC-V > > > > architectures. Hopefully that's the case. > > > > > > Yeah, the spike machine on RISC-V is unusable in basically the same > > > ways that the integratorcp machine is on Arm. Let's just change the > > > default to virt on all of those then :) > > > > Thanks for the confirmation. I should have time to work on this over the > > next days. I haven't looked in detail yet, but I get the feeling there is > > more to it than changing a few variables :-). Beyond code, do you have a > > mental checklist of the items that will need adjusted? E.g. docs, examples, > > tests, etc? > > I might be excessively optimistic, but I truly believe it could be as > simple as changing a couple of lines in the QEMU driver :) > > I don't think we rely on default machine types anywhere in the test > suite, and even if we were only minor touch-ups would probably be > necessary. The test suite does use/validate/assign machine types, but I've already removed the all of the fake-machine type infrastructure for RISC-V so you only get to use the qemuCapabilities object populated from what we have in tests/qemucapabilitiesdata/. There doesn't seem to be any qemuxml2argv test case referencing 'spike' so obviously the default machine is not covered by tests. That also means that the test suite will not break :)
