Il 27/08/2014 01:58, Andy Lutomirski ha scritto: > hpa pointed out that the ABI that I chose (an MSR from the KVM range > and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice > to allocate an MSR that everyone involved can agree on and, rather > than relying on a cpuid bit, just have the guest probe for the MSR. > > This leads to a few questions: > > 1. How do we allocate an MSR? (For background, this would be an MSR > that either returns 64 bits of best-effort cryptographically secure > random data or fails with #GP.) Ask Intel? :) > 2. For KVM, what's the right way to allow QEMU to turn the feature on > and off? Is this even necessary? KVM currently doesn't seem to allow > QEMU to turn any of its MSRs off; it just allows QEMU to ask it to > stop advertising support. Note that QEMU is not involved in the implementation of your feature, only in advertising it. You could look at CPUID at runtime, but that would mean teaching KVM to look for the KVMKVMKVM\0\0\0 signature in the CPUID data supplied by userspace. I don't think this is particularly useful. > 3. QEMU people, can you please fix your RDMSR emulation to send #GP on > failure? I can work around it for this MSR in the Linux code, but for > Pete's sake... :( Sure, I will look at it. Though I expect it was done because of MSRs that are missing in QEMU (similar to how Linux doesn't #GP if compiled with pvops). Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
