Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965227AbaGPOct (ORCPT ); Wed, 16 Jul 2014 10:32:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19991 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965109AbaGPOcp (ORCPT ); Wed, 16 Jul 2014 10:32:45 -0400 Message-ID: <53C68CF3.5070208@redhat.com> Date: Wed, 16 Jul 2014 16:32:19 +0200 From: Paolo Bonzini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Andy Lutomirski CC: Daniel Borkmann , Gleb Natapov , kvm list , "H. Peter Anvin" , "Theodore Ts'o" , "linux-kernel@vger.kernel.org" , Kees Cook , X86 ML , Srivatsa Vaddagiri , Raghavendra K T Subject: Re: [PATCH 0/4] random,x86,kvm: Add and use MSR_KVM_GET_RNG_SEED References: <20140716064110.GV18167@minantech.com> <53C62563.6050106@redhat.com> <53C62B68.50702@redhat.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Il 16/07/2014 16:07, Andy Lutomirski ha scritto: > This patch has nothing whatsoever to do with how much I trust the CPU > vs the hypervisor. It's for the enormous installed base of machines > without RDRAND. Ok. I think an MSR is fine, though I don't think it's useful for the guest to use it if it already has RDRAND and/or RDSEED. > > In any case, is there a matching QEMU patch somewhere? > > What QEMU change is needed? I admit I'm a bit vague on how QEMU and > KVM cooperate here, but there's no state to save and restore. I guess > that QEMU wants the ability to turn this on and off for migration. > How does that work? I couldn't spot the KVM code that allows this > type of control. It is QEMU who decides the CPUID bits that are visible to the guest. By default it blocks bits that it doesn't know about. You would need to add the bit in the kvm_default_features and kvm_feature_name arrays. For migration, we have "versioned" machine types, for example pc-2.1. Once the versioned machine type exists, blocking the feature is a one-liner like x86_cpu_compat_disable_kvm_features(FEAT_KVM, KVM_FEATURE_NAME); Unfortunately, QEMU is in hard freeze, so you'd likely be the one creating pc-2.2. This is a boilerplate but relatively complicated patch. But let's cross that bridge when we'll reach it. For now, you can simply add the bit to the two arrays above. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/