From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH RFC 20/31] x86: Improvements to in-hypervisor cpuid sanity checks Date: Fri, 22 Jan 2016 00:45:44 -0700 Message-ID: <56A1EC3802000078000C9DFF@prv-mh.provo.novell.com> References: <1450301073-28191-1-git-send-email-andrew.cooper3@citrix.com> <1450301073-28191-21-git-send-email-andrew.cooper3@citrix.com> <56A11D3702000078000C9B82@prv-mh.provo.novell.com> <56A113AA.7030600@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56A113AA.7030600@citrix.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: Xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 21.01.16 at 18:21, wrote: > On 21/01/16 17:02, Jan Beulich wrote: >>>>> On 16.12.15 at 22:24, wrote: >>> case 0x80000001: >>> - /* Modify Feature Information. */ >>> - if ( is_pv_32bit_domain(currd) ) >>> - { >>> - __clear_bit(X86_FEATURE_LM % 32, &d); >>> - __clear_bit(X86_FEATURE_LAHF_LM % 32, &c); >>> - } >>> - if ( is_pv_32bit_domain(currd) && >>> - boot_cpu_data.x86_vendor != X86_VENDOR_AMD ) >>> - __clear_bit(X86_FEATURE_SYSCALL % 32, &d); >> But what about these 32-bit specific removals? > > LM, from the deep feature dependency removal in libxc, when it is known > that the domain is 32bit. > > For SYSCALL, as far as I can tell, the logic is wrong. 32bit compat > mode code on Intel can use SYSCALL, as Xen is running in Long mode. > (This is opposite to the AMD case where 32bit compat code cannot use > SYSENTER, because Xen is in Long mode.) Intel doesn't even document a CSTAR MSR. >> Overall this of course makes things quite a bit more readable. > > And there is more to come. > > By the time my cpuid phase 2 plans are complete, all validitiy checks > will be done at the set_cpuid_policy hypercall boundary, meaning that > all these time-of-use checks can be dropped. And arguably it should have been that way from the beginning - re-calculating all of these every time is ineffective, even if the overhead isn't _that_ high. Jan