From: Paolo Bonzini <pbonzini@redhat.com>
To: Brian Gerst <brgerst@gmail.com>
Cc: whiteheadm@acm.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: kvm: Restrict X86_FEATURE_VMMCALL to x86_64 platform
Date: Wed, 1 Aug 2018 17:27:29 +0200 [thread overview]
Message-ID: <db964be1-623d-979a-3321-58a6d87a188e@redhat.com> (raw)
In-Reply-To: <CAMzpN2jY7AC2Kmp7rr+cP2Xynx66fWnzEXs9_JhbNpsqix0_Vg@mail.gmail.com>
On 01/08/2018 17:21, Brian Gerst wrote:
> On Tue, Jul 31, 2018 at 9:00 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>> On 31/07/2018 14:57, tedheadster wrote:
>>>>
>>>> This shouldn't be necessary; for systems that don't have virtualization
>>>> extensions, the comment explains why setting X86_FEATURE_VMMCALL is safe.
>>>>
>>>> But it is also wrong, because you can run a 32-bit kernel as a guest on
>>>> a 64-bit processor, and then it should set X86_FEATURE_VMMCALL because
>>>> the processor has the vmmcall instruction and not Intel's vmcall.
>>>>
>>>
>>> Paolo,
>>> I'm running this on a bare metal machine (no virtualization) with a
>>> 32-bit AMD i486 class cpu. Should the feature be showing up in
>>> /proc/cpuinfo under the 'flags' line? It does on my machine, and it
>>> looked wrong to me.
>>
>> It's a bit silly, but it's not particularly wrong.
>
> Why is there even a specific feature flag for VMMCALL? Isn't
> X86_FEATURE_SVM sufficient to differentiate which opcode to use?
No, X86_FEATURE_SVM is there in the host while X86_FEATURE_VMMCALL is
used in the guest.
Paolo
prev parent reply other threads:[~2018-08-01 15:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-30 19:40 Matthew Whitehead
2018-07-31 7:39 ` Paolo Bonzini
2018-07-31 12:57 ` tedheadster
2018-07-31 12:59 ` Paolo Bonzini
2018-08-01 15:21 ` Brian Gerst
2018-08-01 15:27 ` Paolo Bonzini [this message]
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=db964be1-623d-979a-3321-58a6d87a188e@redhat.com \
--to=pbonzini@redhat.com \
--cc=brgerst@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=whiteheadm@acm.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®