On 11/01/2018 23:15, Paul Mackerras wrote: > QEMU can then have a minimum security level set on the command line, > check that against the host capabilities, and only advertise the > minimum level to guests. Thus QEMU might tell the guest via the > H_GET_CPU_CHARACTERISTICS hypercall that it needs to apply workarounds > even on a host which is actually fixed (the workaround instructions > would be no-ops in that case), so that the guest can then be migrated > to a host which needs the workarounds. Agreed. > As to the representation, we could have defined an ioctl to return the > "character" and "behaviour" words just like H_GET_CPU_CHARACTERISTICS. > We would need the "behaviour" word because that's how we will tell the > guest which workarounds it doesn't need to implement, on machines > which don't have one or more of the vulnerabilities. Oh, my (probably wrong) understanding was that "behavior" can be chosen exclusively by QEMU, while "characteristics" are dictated by the host CPU. > However, QEMU > can't pass that information unmodified to the guest in general, and I > think David felt the logic would be clearer working from a separate > state for each vulnerability rather than having to decode that > information from the "character" and "behaviour" words. I think converting from characteristics to single vulnerabilities is QEMU's job. For KVM I prefer an API that is easier to extend and doesn't require a proliferation of capabilities. Thanks, Paolo
