Re: [Xen-devel] [xen-unstable test] 33399: regressions - FAIL

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.01.15 at 12:37, <JBeulich@xxxxxxxx> wrote:
>>>> On 14.01.15 at 12:22, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 14/01/15 10:52, Jan Beulich wrote:
>>>>>> On 14.01.15 at 11:33, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
>>>> flight 33399 xen-unstable real [real]
>>>> http://www.chiark.greenend.org.uk/~xensrcts/logs/33399/ 
>>>>
>>>> Regressions :-(
>>>>
>>>> Tests which did not succeed and are blocking,
>>>> including tests which could not be run:
>>>>  test-amd64-i386-freebsd10-amd64  8 guest-start            fail REGR. vs. 
>>>> 33112
>>>>  test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail REGR. vs. 
>>>> 33112
>>>>  test-amd64-i386-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail REGR. 
>>>> vs. 33112
>>>>  test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. 
>>>> vs. 33112
>>>>  test-amd64-i386-xl-qemuu-win7-amd64  7 windows-install    fail REGR. vs. 
>>>> 33112
>>>>  test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 
>>>> 33112
>>>>  test-amd64-i386-xl-qemut-win7-amd64  7 windows-install    fail REGR. vs. 
>>>> 33112
>>> Most if not all of these are falling over 07a6aa869b ("x86/HVM:
>>> make hvm_efer_valid() honor guest features"), which I'm therefore
>>> going to revert as I don't have time right now to investigate (and
>>> I also don't immediately see why I wouldn't have seen this in my
>>> own testing).
>> 
>> I have several debug patches I have used in the past to identify the
>> before, after and the bit(s) Xen objects to with these validation
>> routines.  I was looking to find some tuits to get them suitable for
>> upstream, and perhaps this is a good enough reason.
> 
> Actually I think I see the problem (if my assumption is right that
> the naming above means all 32-bit guests, which admittedly I
> didn't specifically test):
> 
> +    if ( (value & (EFER_LME | EFER_LMA)) &&
> +         !(ext1_edx & cpufeat_mask(X86_FEATURE_LM)) )
> +        return 0;
> +
> 
> I would assume that FEATURE_LM is clear for these guests (implied
> from there not being pae=1 in the guest configs), yet for whatever
> reason they try to set EFER_LME.

That's not the issue; I misread libxl sources - pae is on by default.
But what's worse, no matter whether I use pae=1 or pae=0, I
can't reproduce the problem. And with

(XEN) hvm.c:2975:d1v0 Trying to set reserved bit in EFER: 0x901

all we talk about here are SCE, LME, and NX. The latter two get
their respective feature bits cleared only when !pae (and the
hvmloader messages confirm, via the shadow_gs_test, that long
mode is available and can be entered).

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).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel