From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [xen-unstable test] 33399: regressions - FAIL Date: Thu, 15 Jan 2015 15:06:01 +0000 Message-ID: <54B7D759.1010900@citrix.com> References: <54B658880200007800054B4C@mail.emea.novell.com> <54B65181.1030805@citrix.com> <54B663060200007800054C49@mail.emea.novell.com> <54B7D95302000078000556A2@mail.emea.novell.com> <54B7E264020000780005574E@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YBm1L-00041i-VD for xen-devel@lists.xenproject.org; Thu, 15 Jan 2015 15:07:40 +0000 In-Reply-To: <54B7E264020000780005574E@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , ian.jackson@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On 15/01/15 14:53, Jan Beulich wrote: >>>> On 15.01.15 at 15:14, wrote: >> But I think I made a wrong assumption above regarding the >> guest size: test-amd64-i386-xl-win7-amd64 produces a 64-bit >> guest with a 32-bit tool stack, so the crucial part of all the >> tests failing is not the guest's bitness, but tool stack's. So I'll >> next look into which of the three feature flags might be off >> when inspected from a 32-bit Dom0, as I now suspect that the >> guest simply doesn't get its CPUID bits correctly set up by a >> 32-bit Dom0 (i.e. the patch might just have uncovered a latent >> bug). > And there you go: The hypervisor deliberately clears the > syscall feature flag for 32-bit PV guests on non-AMD CPUs, and > hardware appears to do so too when CPUID gets executed from > a non-64-bit CS (i.e. no matter whether you execute raw or > "Xen-ified" CPUID there, you won't see that flag set). Yet 64-bit > guests won't be bothered to check whether the flag is enabled, > as x86-64 requires the feature to be there. As AMD had supported syscall in 32bit systems for a long time, I presume it is only Intel where the feature bit in cpuid changes depending on cs.L > > But I think even if this could be taken care of in the tool stack, > it's better to have hvm_cpuid() mimic that behavior, i.e. force > FEATURE_SYSCALL on when hvm_guest_x86_mode() == 8. This seems like the least bad of the available options, but this is going to be another level of complication for my domain cpuid changes. ~Andrew