Re: GET_RNG_SEED hypercall ABI? (Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm)

[Paolo Bonzini]

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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/