On Thu, Dec 19, 2024 at 12:26:29PM +0000, Marc Zyngier wrote: > On Thu, 19 Dec 2024 11:35:16 +0000, > Kashyap Chamarthy <kcham...@redhat.com> wrote: > > > > On Thu, Dec 12, 2024 at 11:04:30AM +0100, Eric Auger wrote: > > > > Hi Eric, > > > > > On 12/12/24 10:36, Cornelia Huck wrote: > > > > On Thu, Dec 12 2024, Daniel P. Berrangé <berra...@redhat.com> wrote: > > > > [...] > > > > > >> Consider you mgmt app wants to set a CPU model that's common across > > > >> heterogeneous hardware. They don't neccessarily want/need to be > > > >> able to live migrate between heterogeneous CPUs, but for simplicity > > > >> of configuration desire to set a single named CPU across all guests, > > > >> irrespective of what host hey are launched on. The ARM spec baseline > > > >> named models would give you that config simplicity. > > > > If we use architecture extensions (i.e. Armv8.x/9.x) as baseline, I'm > > > > seeing some drawbacks: > > > > - a lot of work before we can address some specific use cases > > > > - old models can get new optional features > > > > - a specific cpu might have a huge set of optional features on top of > > > > the baseline model > > > > > > > > Using a reference core such as Neoverse-V2 probably makes more sense > > > > (easier to get started, less feature diff?) It would still make a good > > > > starting point for a simple config. > > > > > > > Actually from a dev point of view I am not sure it changes much to have > > > either ARM spec rev baseline or CPU ref core named model. > > > > > > One remark is that if you look at > > > https://developer.arm.com/documentation/109697/2024_09?lang=en > > > you will see there are quite a lot of spec revisions and quite a few of > > > them are actually meaningful in the light of currently avaiable and > > > relevant HW we want to address. What I would like to avoid is to be > > > obliged to look at all of them in a generic manner while we just want to > > > address few cpu ref models. > > > > > > Also starting from the ARM spec rev baseline the end-user may need to > > > add more feature opt-ins to be close to a specific cpu model. So I > > > foresee extra complexity for the end-user. > > > > (Assuming I'm parsing your last para right; correct me if not.) > > > > Isn't a user wanting to add extra CPU flags (on top of a baseline) a > > "normal behaviour" and not "extra complexity"? Besides coming close to > > a specific CPU model, there's the additional important use-case of CPU > > flags that provide security mitigation. > > > > Consider this: > > > > Say, there's a serious security issue in a released ARM CPU. As part of > > the fix, two new CPU flags need to be exposed to the guest OS, call them > > "secflag1" and "secflag2". Here, the user is configuring a baseline > > model + two extra CPU flags, not to get close to some other CPU model > > but to mitigate itself against a serious security flaw. > > If there's such a security issue, that the hypervisor's job to do so, > not userspace. See what KVM does for CSV3, for example (and all the > rest of the side-channel stuff). > > You can't rely on userspace for security, that'd be completely > ludicrous.
Actually that's a normal situation QEMU has to deal with. QEMU needs to be able to expose a deterministic fixed ABI to the guest VM, and that includes control over what CPU features are exposed to it. In most cases, the hypervisor cannot arbitrary force enable new guest features without agreement from QEMU. If a guest happens to be using '-cpu host', then when a new CPU flag arrives as part of a security fix, there is at least no CPU config change required. QEMU may or may not need changes, in order that the behaviour associated with the new CPU flag is correctly handled. If the guest is using a named CPU model, as well as modifying QEMU to know about the new flag, the host admin needs to explicitly decide whether & when to expose the new CPU flag for each guest VM on the host. Until the new CPU flag is exposed to the guest, while the host itself may be able to remain protected to the new security issue, the guest OS is likely remain vulnerable, or have degraded operation in some way. 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 :|
