[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190819062552.GC4841@zn.tnic>
Date: Mon, 19 Aug 2019 08:25:52 +0200
From: Borislav Petkov <bp@...en8.de>
To: Thomas Hellström (VMware)
<thomas_os@...pmail.org>
Cc: linux-kernel@...r.kernel.org, pv-drivers@...are.com,
Thomas Hellstrom <thellstrom@...are.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
Doug Covelli <dcovelli@...are.com>
Subject: Re: [PATCH 2/4] x86/vmware: Add a header file for hypercall
definitions
On Mon, Aug 19, 2019 at 12:28:05AM +0200, Thomas Hellström (VMware) wrote:
> Unfortunately we can't use it, because it's unconditionally set on AMD even
> if the VMware hypervisor
> doesn't support it (by version or by configuration).
AMD sets it because they don't support VMCALL. Nothing stops us from
making that conditional depending on what the hypervisor can/supports.
I'm thinking it would be even cleaner if we use those two flags:
X86_FEATURE_VMMCALL
X86_FEATURE_VMCALL
to denote hw support for either one or the other instruction and switch
accordingly. Just like KVM does.
In your case, the HV would set the preferred flag in
arch/x86/kernel/cpu/vmware.c - just like the others do in their
respective CPU init files - and the alternatives code would switch to it
when it runs.
Or is there more? :)
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Powered by blists - more mailing lists