From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH -v2] kvm: Emulate MOVBE Date: Sun, 21 Apr 2013 12:46:51 +0300 Message-ID: <20130421094651.GA8997@redhat.com> References: <20130411001815.GA17544@pd.tnic> <20130411142818.GA17919@redhat.com> <20130411153733.GE27062@pd.tnic> <20130414074107.GD17919@redhat.com> <20130414173215.GD20547@pd.tnic> <20130416174236.GE5807@redhat.com> <20130417110433.GD11807@pd.tnic> <20130417133829.GH1682@redhat.com> <20130417140200.GE11807@pd.tnic> <20130418224848.GA20712@pd.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andre Przywara , kvm@vger.kernel.org, =?utf-8?B?SsO2cmcgUsO2ZGVs?= , "H. Peter Anvin" , x86-ml To: Borislav Petkov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:43863 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752994Ab3DUJrI (ORCPT ); Sun, 21 Apr 2013 05:47:08 -0400 Content-Disposition: inline In-Reply-To: <20130418224848.GA20712@pd.tnic> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Apr 19, 2013 at 12:48:48AM +0200, Borislav Petkov wrote: > On Wed, Apr 17, 2013 at 04:02:00PM +0200, Borislav Petkov wrote: > > Right, so basically we want to handle features which were explicitly > > enabled only for this guest as private, only relevant to this > > particular guest run. > > Ok, > > here are two more ideas Joerg and I had today during lunch: > > * reuse KVM_GET_SUPPORTED_CPUID > > we hand-in a struct kvm_cpuid_entry2 with ->function and respective bits > in e[abcd]x set for each CPUID leaf we want to query kvm. > > Once in the kernel, we do the following: > > if ->function is not 0xffffffff, it means userspace wants us to look at > the all set bits in the respective e[abcd]x members. There may be userspaces that set ->function to 0xffffffff (just because they do not init the buffer before calling into the kernel) and this will break them. > > For each set bit, we check whether we emulate the respective feature > and if so, we leave it untouched before returning it to userspace. > Otherwise, we clear it before OR-ing in the host bits and the > good-emulated bits like x2apic. > > Yeah, semantics need to be handled carefully, but it has this > knock-on-door aspect where kvm says that it actually emulates a feature > only if asked, i.e. with the -cpu ...,+ syntax. > > * new ioctl KVM_GET_EMULATED_CPUID > > Might be overkill and might be used only in a limited fashion since we > don't want to emulate *every* feature in kvm. > > Hmmm. I kinda like the first one more while the second one is cleaner. > The first one needs explicit userspace support to work correctly. This should be other way around: old userspace should do the right thing, but may not support new features, new userspace should be able to support new feature. We may extend KVM_GET_SUPPORTED_CPUID instead of adding new one. There is a padding field in kvm_cpuid2 that we could have reused as flags, but unfortunately current implementation does not error if the field is not zero, so if there is a userspace that does not zero the padding it may break. Another options is to reuse high bits of nent as flags (not very nice, but will work). -- Gleb.