On Mon, Oct 16, 2023 at 03:39:40PM +1000, Alistair Francis wrote: > On Fri, Aug 11, 2023 at 5:01 PM Andrew Jones <ajo...@ventanamicro.com> wrote: > > > > On Thu, Aug 10, 2023 at 02:07:17PM -0400, Alistair Francis wrote: > > > On Tue, Aug 8, 2023 at 6:10 PM Vineet Gupta <vine...@rivosinc.com> wrote: > > > > > > > > > > > > > > > > On 8/8/23 14:06, Daniel Henrique Barboza wrote: > > > > > (CCing Alistair and other reviewers) > > > > > > > > > > On 8/8/23 15:17, Vineet Gupta wrote: > > > > >> Again this helps with better testing and something qemu has been > > > > >> doing > > > > >> with newer features anyways. > > > > >> > > > > >> Signed-off-by: Vineet Gupta <vine...@rivosinc.com> > > > > >> --- > > > > > > > > > > Even if we can reach a consensus about removing the experimental (x- > > > > > prefix) status > > > > > from an extension that is Frozen instead of ratified, enabling stuff > > > > > in the default > > > > > CPUs because it's easier to test is something we would like to avoid. > > > > > The rv64 > > > > > CPU has a random set of extensions enabled for the most different and > > > > > undocumented > > > > > reasons, and users don't know what they'll get because we keep beefing > > > > > up the > > > > > generic CPUs arbitrarily. > > > > > > The idea was to enable "most" extensions for the virt machine. It's a > > > bit wishy-washy, but the idea was to enable as much as possible by > > > default on the virt machine, as long as it doesn't conflict. The goal > > > being to allow users to get the "best" experience as all their > > > favourite extensions are enabled. > > > > > > It's harder to do in practice, so we are in a weird state where users > > > don't know what is and isn't enabled. > > > > > > We probably want to revisit this. We should try to enable what is > > > useful for users and make it clear what is and isn't enabled. I'm not > > > clear on how best to do that though. > > > > > > Again, I think this comes back to we need to version the virt machine. > > > I might do that as a starting point, that allows us to make changes in > > > a clear way. > > > > While some extensions will impact the machine model, as well as cpu > > models, versioning the machine model won't help much with ambiguity in > > cpu model extension support. Daniel's proposal of having a base cpu mode, > > which, on top, users can explicitly enable what they want (including with > > profile support which work like a shorthand to enable many extensions at > > once), is, IMO, the best way for users to know what they get. Also, the > > 'max' cpu model is the best way to "quickly get as much as possible" for > > testing. To know what's in 'max', or named cpu models, we need to > > implement qmp_query_cpu_model_expansion(). Something that could be used > > from the command line would also be nice, but neither x86 nor arm provide > > that (they have '-cpu help', but arm doesn't output anything for cpu > > features and x86 dumps all features out without saying what's enabled for > > any particular cpu model...) > > > > I know x86 people have in the past discussed versioning cpu models, but > > I don't think that should be necessary for riscv with the base+profile > > approach. A profile would effectively be a versioned cpu model in that > > case. > > > > Finally, I'd discourage versioning the virt machine type until we need > > to worry about users creating riscv guest images that they are unwilling > > to modify, despite wanting to update their QEMU versions. And, even then, > > What's the problem with versioning the virt machine though?
The initial versioning support is no big deal, just a couple new functions and macros. And, new versions which don't change anything or just change the current state of preexisting properties and attributes also have very little developer work. However, when changes require adding compat variables, which scatter around if's to manage things in one way for one machine version and another way for others, then code starts to get more difficult to maintain. And, since adding compat variables is known to cause a maintenance burden, then just about every change the machine model gets will lead to time spent discussing whether or not a compat variable is necessary. But, none of that is the worst part of versioned machines. The worst part is that the test matrix explodes. Typically all test cases will get run N times where N is the number of supported machine types, even if for most test cases the machine type doesn't make a difference. So that's a waste of time and energy. And, if nobody really cares about the old machine types, then running test cases which do depend on the machine type is still a waste of time and energy. And, of course, machine types which are just a number bump, definitely lead to waste. > > I'm thinking that in the future we would want to switch from PLIC to > AIA; change the memory map; or change the default extensions (maybe to > a profile). All of those would require a versioned virt machine. Having never versioned the machine type before, we're going break command lines whether we put these types of changes behind machine versions or into machine properties. Currently a command line only specifies 'virt', so unless we leave 'virt' pointing at the current, which will be the oldest, machine type forever, then users would need to change their command lines to point at virt-1.0 or whatever in order to preserve their configurations anyway. I think, particularly considering the current state of RISC-V in production environments (not much), that we could instead require users to change their command lines to be more explicit about what they want, by using machine properties. Regarding the 'virt' name, Arm also has 'virt' which is always an alias to the latest virt-x.y machine. This works best for users who use libvirt, since libvirt will convert the alias to the versioned name when storing it in the XML. So, IMO, RISC-V should focus on libvirt support before QEMU versioning, which also gets RISC-V closer to being used in production, where machine versions are more important. As for extensions and profiles, IMO, they shouldn't be coupled with the machine type. Either the max CPU type should be used by default or users should be required to select the CPU type, i.e. no default. Thanks, drew
