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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 14/01/15 11:37, Jan Beulich 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.

EFER.LME is reserved if !FEATURE_LM, so attempts to set really should fault.

It is entirely possible that the featureset is not being set up
correctly, and making Xen stricter has caught the error.

~Andrew


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