> >> So it's wrapping architecture-specific data in a common >> parameter. Hmm. > > Well, I don't know I'd say "wrapping". You have a common parameter > that points to an object with a well defined interface. The available > implementations of that object will tend to be either zero or one per > architecture, but there's no theoretical reason it has to be. Indeed > we expect at least 2 for x86 (SEV and the Intel one who's name I never > remember). Extra ones are entirely plausible for POWER and maybe s390 > too, when an updated version of PEF or PV inevitably rolls around. > > Some sort of new HTL scheme which could work across multiple archs is > much less likely, but it's not totally impossible either. > >>>>> For now this series covers just AMD SEV and POWER PEF. I'm hoping it >>>>> can be extended to cover the Intel and s390 mechanisms as well, >>>>> though. >>>> >>>> The only approach on s390x to not glue command line properties to the >>>> cpu model would be to remove the CPU model feature and replace it by the >>>> command line parameter. But that would, of course, be an incompatible break. >>> >>> I don't really understand why you're so against setting the cpu >>> default parameters from the machine. The machine already sets basic >>> configuration for all sorts of devices in the VM, that's kind of what >>> it's for. >> >> It's a general design philosophy that the CPU model (especially the host >> CPU model) does not depend on other command line parameters (except the >> accelerator, and I think in corner cases on the machine). Necessary for >> reliable host model probing by libvirt, for example. > > Ok, I've proposed a revision which doesn't require altering the CPU > model elsewhere in this thread. > >> We also don't have similar things for nested virt. > > I'm not sure what you're getting at there. Sorry, back when we introduced nested virt there was a similar (internal?) discussion, to enable/disable it via a machine flag and not via 1..X CPU features. We went for the latter, because it matches the actual architecture and allows for easy migration checks etc. Nested virt also collides with some features currently (e.g., huge page backing for the guest), but not as severe as encrypted virtualization. > >>>> How do upper layers actually figure out if memory encryption etc is >>>> available? on s390x, it's simply via the expanded host CPU model. >>> >>> Haven't really tackled that yet. But one way that works for multiple >>> systems has got to be better than a separate one for each, right? >> >> I think that's an important piece. Especially once multiple different >> approaches are theoretically available one wants to sense from upper layers. > > Fair point. > > So... IIRC there's a general way of looking at available properties > for any object, including the machine. So we can probe for > availability of the "host-trust-limitation" property itself easily > enough. You can have a look at how it's currently probed by libvirt in https://www.redhat.com/archives/libvir-list/2020-June/msg00518.html For now, the s390x check consists of - checking if /sys/firmware/uv is available - checking if the kernel cmdline contains 'prot_virt=1' The sev check is - checking if /sys/module/kvm_amd/parameters/sev contains the value '1' - checking if /dev/sev So at least libvirt does not sense via the CPU model on s390x yet. > > I guess we do need a way of probing for what implementations of the > htl interface are available. And, if we go down that path, if there > are any pre-generated htl objects available. > >> At least on s390x, it really is like just another CPU-visible feature >> that tells the guest that it can switch to protected mode. > > Right.. which is great for you, since you already have a nice > orthogonal interface for that. On POWER, (a) CPU model isn't enough > since you need a running ultravisor as well and (b) CPU feature > detection is already a real mess for.. reasons. I can understand the pain of the latter ... :) -- Thanks, David / dhildenb
