* [xen-unstable test] 33399: regressions - FAIL
@ 2015-01-14 10:33 xen.org
2015-01-14 10:52 ` Jan Beulich
0 siblings, 1 reply; 9+ messages in thread
From: xen.org @ 2015-01-14 10:33 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
[-- Attachment #1: Type: text/plain, Size: 8813 bytes --]
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
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail like 33112
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 10 migrate-support-check fail never pass
test-amd64-amd64-libvirt 9 guest-start fail never pass
test-amd64-i386-libvirt 9 guest-start fail never pass
test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass
test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass
test-armhf-armhf-libvirt 9 guest-start fail never pass
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop fail never pass
test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop fail never pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass
test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass
test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass
version targeted for testing:
xen 762c08496e9732822f172801d5576cd24fff784a
baseline version:
xen 36174af3fbeb1b662c0eadbfa193e77f68cc955b
------------------------------------------------------------
People who touched revisions under test:
Alexandra Sandulescu <alecsandra.sandulescu@gmail.com>
Andrew Cooper <andrew.cooper3@citrix.com>
Boris Ostrovsky <boris.ostrovsky@oracle.com>
Chao Peng <chao.p.peng@linux.intel.com>
Christoph Egger <chegger@amazon.de>
Ed Swierk <eswierk@skyportsystems.com>
Euan Harris <euan.harris@citrix.com>
Ian Campbell <ian.campbell@citrix.com>
Ian Campbell <ijc@hellion.org.uk>
Ian Jackson <Ian.Jackson@eu.citrix.com>
Ian Jackson <iwj@mariner.uk.xensource.com>
Jan Beulich <jbeulich@suse.com>
Juergen Gross <jgross@suse.com>
Julien Grall <julien.grall@linaro.org>
Karim Allah Ahmed <karim.allah.ahmed@gmail.com>
Keir Fraser <keir@xen.org>
Kevin Tian <kevin.tian@intel.com>
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Liang Li <liang.z.li@intel.com>
Liu Jinsong <jinsong.liu@alibaba-inc.com>
Mihai Donțu <mdontu@bitdefender.com>
Olaf Hering <olaf@aepfle.de>
Paul Durrant <paul.durrant@citrix.com>
Robert Hu <robert.hu@intel.com>
Roger Pau Monné <roger.pau@citrix.com>
Răzvan Cojocaru <rcojocaru@bitdefender.com>
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thomas Leonard <talex5@gmail.com>
Tim Deegan <tim@xen.org>
Uma Sharma <uma.sharma523@gmail.com>
Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
Wei Liu <wei.liu2@citrix.com>
Wei Ye <wei.ye@intel.com>
Yang Hongyang <yanghy@cn.fujitsu.com>
Yang Zhang <yang.z.zhang@intel.com>
Yu Zhang <yu.c.zhang@linux.intel.com>
------------------------------------------------------------
jobs:
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumpuserxen pass
build-i386-rumpuserxen pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-pvh-amd fail
test-amd64-i386-rhel6hvm-amd pass
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 fail
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 fail
test-amd64-i386-freebsd10-amd64 fail
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 fail
test-amd64-amd64-rumpuserxen-amd64 pass
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-win7-amd64 fail
test-amd64-i386-xl-win7-amd64 fail
test-amd64-i386-xl-credit2 pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumpuserxen-i386 pass
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-rhel6hvm-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt fail
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt fail
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair fail
test-amd64-amd64-xl-sedf-pin pass
test-amd64-amd64-xl-sedf pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-amd64-xl-qemut-winxpsp3 fail
test-amd64-i386-xl-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemuu-winxpsp3 fail
test-amd64-i386-xl-qemuu-winxpsp3 fail
test-amd64-amd64-xl-winxpsp3 fail
test-amd64-i386-xl-winxpsp3 fail
------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Not pushing.
(No revision log; it would be 1445 lines long.)
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [xen-unstable test] 33399: regressions - FAIL
2015-01-14 10:33 [xen-unstable test] 33399: regressions - FAIL xen.org
@ 2015-01-14 10:52 ` Jan Beulich
2015-01-14 11:22 ` Andrew Cooper
0 siblings, 1 reply; 9+ messages in thread
From: Jan Beulich @ 2015-01-14 10:52 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
>>> On 14.01.15 at 11:33, <Ian.Jackson@eu.citrix.com> 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).
Jan
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [xen-unstable test] 33399: regressions - FAIL
2015-01-14 10:52 ` Jan Beulich
@ 2015-01-14 11:22 ` Andrew Cooper
2015-01-14 11:37 ` Jan Beulich
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Cooper @ 2015-01-14 11:22 UTC (permalink / raw)
To: Jan Beulich, xen-devel; +Cc: ian.jackson
On 14/01/15 10:52, Jan Beulich wrote:
>>>> On 14.01.15 at 11:33, <Ian.Jackson@eu.citrix.com> 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.
~Andrew
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [xen-unstable test] 33399: regressions - FAIL
2015-01-14 11:22 ` Andrew Cooper
@ 2015-01-14 11:37 ` Jan Beulich
2015-01-14 12:07 ` Andrew Cooper
2015-01-15 14:14 ` Jan Beulich
0 siblings, 2 replies; 9+ messages in thread
From: Jan Beulich @ 2015-01-14 11:37 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel, ian.jackson
>>> On 14.01.15 at 12:22, <andrew.cooper3@citrix.com> wrote:
> On 14/01/15 10:52, Jan Beulich wrote:
>>>>> On 14.01.15 at 11:33, <Ian.Jackson@eu.citrix.com> 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.
Jan
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [xen-unstable test] 33399: regressions - FAIL
2015-01-14 11:37 ` Jan Beulich
@ 2015-01-14 12:07 ` Andrew Cooper
2015-01-15 14:14 ` Jan Beulich
1 sibling, 0 replies; 9+ messages in thread
From: Andrew Cooper @ 2015-01-14 12:07 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, ian.jackson
On 14/01/15 11:37, Jan Beulich wrote:
>>>> On 14.01.15 at 12:22, <andrew.cooper3@citrix.com> wrote:
>> On 14/01/15 10:52, Jan Beulich wrote:
>>>>>> On 14.01.15 at 11:33, <Ian.Jackson@eu.citrix.com> 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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [xen-unstable test] 33399: regressions - FAIL
2015-01-14 11:37 ` Jan Beulich
2015-01-14 12:07 ` Andrew Cooper
@ 2015-01-15 14:14 ` Jan Beulich
2015-01-15 14:53 ` Jan Beulich
1 sibling, 1 reply; 9+ messages in thread
From: Jan Beulich @ 2015-01-15 14:14 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel, ian.jackson
>>> On 14.01.15 at 12:37, <JBeulich@suse.com> wrote:
>>>> On 14.01.15 at 12:22, <andrew.cooper3@citrix.com> wrote:
>> On 14/01/15 10:52, Jan Beulich wrote:
>>>>>> On 14.01.15 at 11:33, <Ian.Jackson@eu.citrix.com> 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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [xen-unstable test] 33399: regressions - FAIL
2015-01-15 14:14 ` Jan Beulich
@ 2015-01-15 14:53 ` Jan Beulich
2015-01-15 15:06 ` Andrew Cooper
0 siblings, 1 reply; 9+ messages in thread
From: Jan Beulich @ 2015-01-15 14:53 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel, ian.jackson
>>> On 15.01.15 at 15:14, <JBeulich@suse.com> 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.
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.
Jan
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [xen-unstable test] 33399: regressions - FAIL
2015-01-15 14:53 ` Jan Beulich
@ 2015-01-15 15:06 ` Andrew Cooper
2015-01-15 15:10 ` Jan Beulich
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Cooper @ 2015-01-15 15:06 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, ian.jackson
On 15/01/15 14:53, Jan Beulich wrote:
>>>> On 15.01.15 at 15:14, <JBeulich@suse.com> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [xen-unstable test] 33399: regressions - FAIL
2015-01-15 15:06 ` Andrew Cooper
@ 2015-01-15 15:10 ` Jan Beulich
0 siblings, 0 replies; 9+ messages in thread
From: Jan Beulich @ 2015-01-15 15:10 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel, ian.jackson
>>> On 15.01.15 at 16:06, <andrew.cooper3@citrix.com> wrote:
> On 15/01/15 14:53, Jan Beulich wrote:
>>>>> On 15.01.15 at 15:14, <JBeulich@suse.com> 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
Sure.
Jan
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-01-15 15:10 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-01-14 10:33 [xen-unstable test] 33399: regressions - FAIL xen.org
2015-01-14 10:52 ` Jan Beulich
2015-01-14 11:22 ` Andrew Cooper
2015-01-14 11:37 ` Jan Beulich
2015-01-14 12:07 ` Andrew Cooper
2015-01-15 14:14 ` Jan Beulich
2015-01-15 14:53 ` Jan Beulich
2015-01-15 15:06 ` Andrew Cooper
2015-01-15 15:10 ` Jan Beulich
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.