From: Eduardo Habkost <ehabkost@redhat.com> To: Gleb Natapov <gleb@redhat.com> Cc: Borislav Petkov <bp@alien8.de>, LKML <linux-kernel@vger.kernel.org>, Borislav Petkov <bp@suse.de>, "H. Peter Anvin" <hpa@zytor.com>, Paolo Bonzini <pbonzini@redhat.com>, Andre Przywara <andre@andrep.de>, Joerg Roedel <joro@8bytes.org>, X86 ML <x86@kernel.org>, KVM <kvm@vger.kernel.org>, qemu-devel@nongnu.org, libvir-list@redhat.com, Jiri Denemark <jdenemar@redhat.com> Subject: Re: [PATCH 1/6] kvm: Add KVM_GET_EMULATED_CPUID Date: Thu, 26 Sep 2013 11:19:15 -0300 [thread overview] Message-ID: <20130926141915.GV2840@otherpad.lan.raisama.net> (raw) In-Reply-To: <20130924100414.GE17294@redhat.com> On Tue, Sep 24, 2013 at 01:04:14PM +0300, Gleb Natapov wrote: > On Tue, Sep 24, 2013 at 11:57:00AM +0200, Borislav Petkov wrote: > > On Mon, September 23, 2013 6:28 pm, Eduardo Habkost wrote: > > > On Sun, Sep 22, 2013 at 04:44:50PM +0200, Borislav Petkov wrote: > > >> From: Borislav Petkov <bp@suse.de> > > >> > > >> Add a kvm ioctl which states which system functionality kvm emulates. > > >> The format used is that of CPUID and we return the corresponding CPUID > > >> bits set for which we do emulate functionality. > > > > > > Let me check if I understood the purpose of the new ioctl correctly: the > > > only reason for GET_EMULATED_CPUID to exist is to allow userspace to > > > differentiate features that are native or that are emulated efficiently > > > (GET_SUPPORTED_CPUID) and features that are emulated not very > > > efficiently (GET_EMULATED_CPUID)? > > > > Not only that - emulated features are not reported in CPUID so they > > can be enabled only when specifically and explicitly requested, i.e. > > "+movbe". Basically, you want to emulate that feature for the guest but > > only for this specific guest - the others shouldn't see it. Then we may have a problem: some CPU models already have "movbe" included (e.g. Haswell), and patch 6/6 will make "-cpu Haswell" get movbe enabled even if it is being emulated. So if we really want to avoid enabling emulated features by mistake, we may need a new CPU flag in addition to "enforce" to tell QEMU that it is OK to enable emulated features (maybe "-cpu ...,emulate"?). > > > > > If that's the case, how do we decide how efficient emulation should be, > > > to deserve inclusion in GET_SUPPORTED_CPUID? I am guessing that the > > > criterion will be: if enabling it doesn't risk making performance worse, > > > it can get in GET_SUPPORTED_CPUID. > > > > Well, in the MOVBE case, supported means, the host can execute this > > instruction natively. Now, you guys say you can emulate x2apic very > > efficiently and I'm guessing emulating x2apic doesn't bring any > > emulation overhead, thus SUPPORTED_CPUID. > x2apic emulation has nothing to do with x2apic in a host. It is emulated > same way no matter if host has it or not. x2apic is not really cpu > feature, but apic one and apic is fully emulated by KVM anyway. But my question still stands: suppose we had x2apic emulation implemented but for some reason it was painfully slow, we wouldn't want to enable it by mistake. In this case, it would end up on EMULATED_CPUID and not on SUPPORTED_CPUID, right? > > > > > But for single instructions or group of instructions, the distinction > > should be very clear. > > > > At least this is how I see it but Gleb probably can comment too. > > > That's how I see it two. Basically you want to use movbe emulation (as > opposite of virtualization) only if you have binary kernel that compiled > for CPU with movbe (Borislav's use case), or you want to migrate > temporarily from movbe enabled host to non movbe host because downtime > is not an option. We should avoid enabling it "by mistake". "we should avoid enabling it 'by mistake'" sounds like a good criterion for including something on GET_EMULATED_CPUID instead of GET_SUPPORTED_CPUID. In that case, I believe QEMU should use GET_EMULATED_CPUID only if explicitly requested in the configuration/command-line (that's not what patch 6/6 does). -- Eduardo
WARNING: multiple messages have this Message-ID (diff)
From: Eduardo Habkost <ehabkost@redhat.com> To: Gleb Natapov <gleb@redhat.com> Cc: KVM <kvm@vger.kernel.org>, libvir-list@redhat.com, Joerg Roedel <joro@8bytes.org>, X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>, qemu-devel@nongnu.org, Andre Przywara <andre@andrep.de>, Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>, Paolo Bonzini <pbonzini@redhat.com>, Jiri Denemark <jdenemar@redhat.com>, Borislav Petkov <bp@suse.de> Subject: Re: [Qemu-devel] [PATCH 1/6] kvm: Add KVM_GET_EMULATED_CPUID Date: Thu, 26 Sep 2013 11:19:15 -0300 [thread overview] Message-ID: <20130926141915.GV2840@otherpad.lan.raisama.net> (raw) In-Reply-To: <20130924100414.GE17294@redhat.com> On Tue, Sep 24, 2013 at 01:04:14PM +0300, Gleb Natapov wrote: > On Tue, Sep 24, 2013 at 11:57:00AM +0200, Borislav Petkov wrote: > > On Mon, September 23, 2013 6:28 pm, Eduardo Habkost wrote: > > > On Sun, Sep 22, 2013 at 04:44:50PM +0200, Borislav Petkov wrote: > > >> From: Borislav Petkov <bp@suse.de> > > >> > > >> Add a kvm ioctl which states which system functionality kvm emulates. > > >> The format used is that of CPUID and we return the corresponding CPUID > > >> bits set for which we do emulate functionality. > > > > > > Let me check if I understood the purpose of the new ioctl correctly: the > > > only reason for GET_EMULATED_CPUID to exist is to allow userspace to > > > differentiate features that are native or that are emulated efficiently > > > (GET_SUPPORTED_CPUID) and features that are emulated not very > > > efficiently (GET_EMULATED_CPUID)? > > > > Not only that - emulated features are not reported in CPUID so they > > can be enabled only when specifically and explicitly requested, i.e. > > "+movbe". Basically, you want to emulate that feature for the guest but > > only for this specific guest - the others shouldn't see it. Then we may have a problem: some CPU models already have "movbe" included (e.g. Haswell), and patch 6/6 will make "-cpu Haswell" get movbe enabled even if it is being emulated. So if we really want to avoid enabling emulated features by mistake, we may need a new CPU flag in addition to "enforce" to tell QEMU that it is OK to enable emulated features (maybe "-cpu ...,emulate"?). > > > > > If that's the case, how do we decide how efficient emulation should be, > > > to deserve inclusion in GET_SUPPORTED_CPUID? I am guessing that the > > > criterion will be: if enabling it doesn't risk making performance worse, > > > it can get in GET_SUPPORTED_CPUID. > > > > Well, in the MOVBE case, supported means, the host can execute this > > instruction natively. Now, you guys say you can emulate x2apic very > > efficiently and I'm guessing emulating x2apic doesn't bring any > > emulation overhead, thus SUPPORTED_CPUID. > x2apic emulation has nothing to do with x2apic in a host. It is emulated > same way no matter if host has it or not. x2apic is not really cpu > feature, but apic one and apic is fully emulated by KVM anyway. But my question still stands: suppose we had x2apic emulation implemented but for some reason it was painfully slow, we wouldn't want to enable it by mistake. In this case, it would end up on EMULATED_CPUID and not on SUPPORTED_CPUID, right? > > > > > But for single instructions or group of instructions, the distinction > > should be very clear. > > > > At least this is how I see it but Gleb probably can comment too. > > > That's how I see it two. Basically you want to use movbe emulation (as > opposite of virtualization) only if you have binary kernel that compiled > for CPU with movbe (Borislav's use case), or you want to migrate > temporarily from movbe enabled host to non movbe host because downtime > is not an option. We should avoid enabling it "by mistake". "we should avoid enabling it 'by mistake'" sounds like a good criterion for including something on GET_EMULATED_CPUID instead of GET_SUPPORTED_CPUID. In that case, I believe QEMU should use GET_EMULATED_CPUID only if explicitly requested in the configuration/command-line (that's not what patch 6/6 does). -- Eduardo
next prev parent reply other threads:[~2013-09-26 14:19 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-09-22 14:44 [PATCH 0/6] kvm: Emulate MOVBE, v3 Borislav Petkov 2013-09-22 14:44 ` [PATCH 1/6] kvm: Add KVM_GET_EMULATED_CPUID Borislav Petkov 2013-09-23 16:28 ` Eduardo Habkost 2013-09-23 16:28 ` [Qemu-devel] " Eduardo Habkost 2013-09-23 16:28 ` Eduardo Habkost 2013-09-24 9:57 ` Borislav Petkov 2013-09-24 9:57 ` [Qemu-devel] " Borislav Petkov 2013-09-24 10:04 ` Gleb Natapov 2013-09-24 10:04 ` [Qemu-devel] " Gleb Natapov 2013-09-26 14:19 ` Eduardo Habkost [this message] 2013-09-26 14:19 ` Eduardo Habkost 2013-09-26 18:55 ` Borislav Petkov 2013-09-26 18:55 ` [Qemu-devel] " Borislav Petkov 2013-09-26 19:20 ` Eduardo Habkost 2013-09-26 19:20 ` [Qemu-devel] " Eduardo Habkost 2013-09-26 20:32 ` Borislav Petkov 2013-09-26 20:32 ` [Qemu-devel] " Borislav Petkov 2013-09-26 20:32 ` Borislav Petkov 2013-09-27 14:21 ` Eduardo Habkost 2013-09-27 14:21 ` [Qemu-devel] " Eduardo Habkost 2013-09-28 10:49 ` Borislav Petkov 2013-09-28 10:49 ` [Qemu-devel] " Borislav Petkov 2013-09-30 16:13 ` Eduardo Habkost 2013-09-30 16:13 ` [Qemu-devel] " Eduardo Habkost 2013-09-30 16:18 ` Borislav Petkov 2013-09-30 16:18 ` [Qemu-devel] " Borislav Petkov 2013-09-22 14:44 ` [PATCH 2/6] kvm, emulator: Use opcode length Borislav Petkov 2013-09-22 14:44 ` [PATCH 3/6] kvm, emulator: Rename VendorSpecific flag Borislav Petkov 2013-09-22 14:44 ` [PATCH 4/6] kvm, emulator: Add initial three-byte insns support Borislav Petkov 2013-10-29 9:50 ` Gleb Natapov 2013-10-29 10:04 ` Borislav Petkov 2013-10-29 10:11 ` Gleb Natapov 2013-09-22 14:44 ` [PATCH 5/6] kvm: Emulate MOVBE Borislav Petkov 2013-09-22 14:44 ` [PATCH 6/6] qemu: Add support for emulated CPU features Borislav Petkov 2013-09-23 17:06 ` Eduardo Habkost 2013-09-23 17:06 ` [Qemu-devel] " Eduardo Habkost 2013-10-29 9:53 ` [PATCH 0/6] kvm: Emulate MOVBE, v3 Gleb Natapov 2013-10-29 10:30 ` Borislav Petkov 2013-10-29 10:35 ` Gleb Natapov 2013-10-29 11:28 ` Borislav Petkov 2013-10-29 11:36 ` Gleb Natapov 2013-10-29 11:53 ` Borislav Petkov 2013-10-29 11:54 ` [PATCH 4/5 -v3.1] kvm, emulator: Add initial three-byte insns support Borislav Petkov 2013-10-29 11:54 ` [PATCH 5/5 -v3.1] kvm: Emulate MOVBE Borislav Petkov 2013-10-30 17:56 ` Paolo Bonzini 2013-10-30 18:03 ` Borislav Petkov 2013-10-30 18:10 ` [PATCH 0/6] kvm: Emulate MOVBE, v3 Paolo Bonzini 2013-10-30 18:44 ` Borislav Petkov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20130926141915.GV2840@otherpad.lan.raisama.net \ --to=ehabkost@redhat.com \ --cc=andre@andrep.de \ --cc=bp@alien8.de \ --cc=bp@suse.de \ --cc=gleb@redhat.com \ --cc=hpa@zytor.com \ --cc=jdenemar@redhat.com \ --cc=joro@8bytes.org \ --cc=kvm@vger.kernel.org \ --cc=libvir-list@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=pbonzini@redhat.com \ --cc=qemu-devel@nongnu.org \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.