On Fri, Oct 25 2024, Kashyap Chamarthy <kcham...@redhat.com> wrote: > On Fri, Oct 25, 2024 at 12:17:19PM +0200, Eric Auger wrote: > > Hi Eric, > > I'm new to Arm, so please bear with my questions :) > >> This RFC series introduces a KVM host "custom" model. > > (a) On terminology: as we know, in the x86 world, QEMU uses these > terms[1]: > > - Host passthrough > - Named CPU models > - Then there's the libvirt abstraction, "host-model", that aims to > provide the best of 'host-passthrough' + named CPU models. > > Now I see the term "host 'custom' model" here. Most > management-layer tools and libvirt users are familiar with the > classic terms "host-model" or "custom". If we now say "host > 'custom' model", it can create confusion. I hope we can settle on > one of the existing terms, or create a new term if need be. > > (I'll share one more thought on how layers above libvirt tend to use > the term "custom", as a reply to patch 21/21, "arm/cpu-features: > Document custom vcpu model".)
I came up with the "custom" name just to have something to differentiate from the currently existing "host" model (which supports a number of properties that do not translate to id regs.) It is certainly not set in stone; I expect us to end up with named models and a handling of the "host" model which is more similar to what is done for other archs. Maybe we can then rename "custom" to "franken" so that people do not try to use it for productive work ;) > > (b) The current CPU features doc[2] for Arm doesn't mention "host > passthrough" at all. It is only implied by the last part of this > paragraph, from the section titled "A note about CPU models and > KVM"[3]: > > "Named CPU models generally do not work with KVM. There are a few > cases that do work [...] but mostly if KVM is enabled the 'host' > CPU type must be used." > > Related: in your reply[4] to Dan in this series, you write: "Having > named models is the next thing". So named CPU models will be a > thing in Arm, too? Then the above statement in the Arm > 'cpu-features' will need updating :-) The currently existing named models are for cpus like cortex-a57; you can use them for KVM if you happen to run on a matching host cpu, but they only really make sense for use with tcg. I currently think that an Armv9.0 or whatever model would make the most sense, but that's certainly still up for discussion :)
