On Wed, Jul 16, 2014 at 1:20 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: > On 07/16/2014 09:21 AM, Gleb Natapov wrote: >> On Wed, Jul 16, 2014 at 09:13:23AM -0700, H. Peter Anvin wrote: >>> On 07/16/2014 09:08 AM, Paolo Bonzini wrote: >>>> Il 16/07/2014 18:03, H. Peter Anvin ha scritto: >>>>> I suggested emulating RDRAND *but not set the CPUID bit*. We already >>>>> developed a protocol in KVM/Qemu to enumerate emulated features (created >>>>> for MOVBE as I recall), specifically to service the semantic "feature X >>>>> will work but will be substantially slower than normal." >>>> >>>> But those will set the CPUID bit. There is currently no way for KVM >>>> guests to know if a CPUID bit is real or emulated. >>>> >>> >>> OK, so there wasn't any protocol implemented in the end. I sit corrected. >>> >> That protocol that was implemented is between qemu and kvm, not kvm and a guest. >> > > Either which way, the notion was to have a PV CPUID bit like the > proposed kvm_get_rng_seed bit, but to have it exercised by executing RDRAND. > > The biggest reason to *not* do this would be that with an MSR it is not > available to guest user space, which may be better under the circumstances. On the theory that I see no legitimate reason to expose this to guest user space, I think we shouldn't expose it. If we wanted to add a get_random_bytes syscall, that would be an entirely different story, though. Should I send v3 as one series or should I split it into host and guest parts? --Andy -- 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
