[Xen-devel] [qemu-upstream-4.5-testing test] 83042: trouble: broken/fail/pass
flight 83042 qemu-upstream-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/83042/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 3 host-install(3) broken REGR. vs. 82621 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-winxpsp3 13 guest-localmigrate fail REGR. vs. 82621 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 82621 test-amd64-amd64-xl-rtds 6 xen-boot fail like 82621 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeatfail like 82621 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 82621 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 82621 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-qcow2 10 guest-start fail never pass test-armhf-armhf-libvirt-raw 10 guest-start fail never pass test-armhf-armhf-xl-vhd 10 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass version targeted for testing: qemuu90045485cae7ba34334c5f2a6e7b007f2ab7dc2d baseline version: qemuu6d285f1ceb317286c3198a1a13737baa303a814f Last test of basis82621 2016-02-15 04:19:07 Z5 days Testing same since83042 2016-02-18 17:59:34 Z1 days1 attempts People who touched revisions under test: Don Slutz Paolo Bonzini jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl broken test-amd64-i386-xl pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit2 pass test-armhf-armhf-xl-credit2 fail test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel
Re: [Xen-devel] [RFC v2 2/6] x86/init: use linker tables to simplify x86 init and annotate dependencies
On Fri, Feb 19, 2016 at 08:40:49AM -0800, Andy Lutomirski wrote: > On Fri, Feb 19, 2016 at 6:15 AM, Luis R. Rodriguez wrote: > > Any failure on the x86 init path can be catastrophic. > > A simple shift of a call from one place to another can > > easily break things. Likewise adding a new call to > > one path without considering all x86 requirements > > can make certain x86 run time environments crash. > > We currently account for these requirements through > > peer code review and run time testing. We could do > > much better if we had a clean and simple way to annotate > > strong semantics for run time requirements, init sequence > > dependencies, and detection mechanisms for additions of > > new x86 init sequences. > > Please document this in a way that will be useful for people trying to > understand what the code does as opposed to just people who are trying > to understand why you wrote it. More below. Sure. I'm kind of glad people are getting tired of me trying to explain *why* I wrote it though, I figured that might be the harder thing to explain. Hopefully it sinks in. > > +/** > > + * struct x86_init_fn - x86 generic kernel init call > > + * > > + * Linux x86 features vary in complexity, features may require work done at > > + * different levels of the full x86 init sequence. Today there are also two > > + * different possible entry points for Linux on x86, one for bare metal, > > KVM > > + * and Xen HVM, and another for Xen PV guests / dom0. Assuming a > > bootloader > > + * has set up 64-bit mode, roughly the x86 init sequence follows this path: > > + * > > + * Bare metal, KVM, Xen HVM Xen PV / dom0 > > + * startup_64() startup_xen() > > + * \ / > > + * x86_64_start_kernel() xen_start_kernel() > > + * \ / > > + * x86_64_start_reservations() > > + * | > > + * start_kernel() > > + * [ ...] > > + * [ setup_arch() ] > > + * [ ...] > > + * init > > + * > > > I don't think this paragraph below is necessary. I also think it's > very confusing. Keep in mind that the reader has no idea what a > "level" is at this point and that the reader also doesn't need to > think about terms like "paravirtualization yielding". > > > + * x86_64_start_kernel() and xen_start_kernel() are the respective first C > > code > > + * entry starting points. The different entry points exist to enable Xen to > > + * skip a lot of hardware setup already done and managed on behalf of the > > + * hypervisor, we refer to this as "paravirtualization yielding". The > > different > > + * levels of init calls on the x86 init sequence exist to account for these > > + * slight differences and requirements. These different entry points also > > share > > + * a common entry x86 specific path, x86_64_start_reservations(). OK sure, I'll nuke. > > + * > > And here, I don't even know what a "feature" is. Kasan is an example. > > + * A generic x86 feature can have different initialization calls, one on > > each > > + * of the different main x86 init sequences, but must also address both > > entry > > + * points in order to work properly across the board on all supported x86 > > + * subarchitectures. Since x86 features can also have dependencies on other > > + * setup code or features, x86 features can at times be subordinate to > > other > > + * x86 features, or conditions. struct x86_init_fn enables feature > > developers > > + * to annotate dependency relationships to ensure subsequent init calls > > only > > + * run once a subordinate's dependencies have run. When needed custom > > + * dependency requirements can also be spelled out through a custom > > dependency > > + * checker. In order to account for the dual entry point nature of x86-64 > > Linux > > + * for "paravirtualization yielding" and to make annotations for support > > for > > + * these explicit each struct x86_init_fn must specify supported > > + * subarchitectures. The earliest x86-64 code can read the subarchitecture > > + * though is after load_idt(), as such the earliest we can currently rely > > on > > + * subarchitecture for semantics and a common init sequences is on the > > shared > > + * common x86_64_start_reservations(). Each struct x86_init_fn must also > > + * declare a two-digit decimal number to impose an ordering relative to > > other > > + * features when required. > > I'm totally lost in the paragraph above. As an example Kasan could be defined as a struct x86_init_fn with a respective callback on x86_64_start_kernel() (kasan_early_init()) and later setup_arch() (kasan_init()). Since we can't support for struct x86_init_fn calls to start all the
[Xen-devel] [qemu-upstream-4.6-testing test] 83043: regressions - FAIL
flight 83043 qemu-upstream-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/83043/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build fail REGR. vs. 82482 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 82482 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 82482 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass version targeted for testing: qemuu9869880372c8e786502ce140d50158118e29a165 baseline version: qemuu36d4ccc357252ff5506352c4815533f0a3ebc116 Last test of basis82482 2016-02-14 09:52:11 Z6 days Testing same since83043 2016-02-18 18:00:16 Z1 days1 attempts People who touched revisions under test: Don Slutz Paolo Bonzini jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm fail build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl
[Xen-devel] [PATCH 2/2] arm: CONFIG_ARM_{32, 64} defined by Kconfig
CONFIG_ARM_32 and CONFIG_ARM_64 is defined by Kconfig. Signed-off-by: Doug Goldstein --- CC: Ian Campbell CC: Stefano Stabellini --- xen/include/asm-arm/config.h | 6 -- 1 file changed, 6 deletions(-) diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h index a1b968d..c3a2c30 100644 --- a/xen/include/asm-arm/config.h +++ b/xen/include/asm-arm/config.h @@ -7,12 +7,6 @@ #ifndef __ARM_CONFIG_H__ #define __ARM_CONFIG_H__ -#if defined(__aarch64__) -# define CONFIG_ARM_64 1 -#elif defined(__arm__) -# define CONFIG_ARM_32 1 -#endif - #if defined(CONFIG_ARM_64) # define LONG_BYTEORDER 3 #else -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] x86: CONFIG_X86 defined by Kconfig
CONFIG_X86 is defined by Kconfig when building for x86. Signed-off-by: Doug Goldstein --- CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper --- xen/include/asm-x86/config.h | 1 - 1 file changed, 1 deletion(-) diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h index a45d3ee..07f3c1f 100644 --- a/xen/include/asm-x86/config.h +++ b/xen/include/asm-x86/config.h @@ -16,7 +16,6 @@ #define BITS_PER_XEN_ULONG BITS_PER_LONG -#define CONFIG_X86 1 #define CONFIG_PAGING_ASSISTANCE 1 #define CONFIG_X86_LOCAL_APIC 1 #define CONFIG_X86_GOOD_APIC 1 -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen-netfront: set real_num_tx_queues to zreo avoid to trigger BUG_ON
On 02/20/2016 04:27 AM, Gonglei wrote: It's possible for a race condition to exist between xennet_open() and talk_to_netback(). After invoking netfront_probe() then other threads or processes invoke xennet_open (such as NetworkManager) immediately may trigger BUG_ON(). Besides, we also should reset real_num_tx_queues in xennet_destroy_queues(). [ 3324.658057] kernel BUG at include/linux/netdevice.h:508! [ 3324.658057] invalid opcode: [#1] SMP [ 3324.658057] CPU: 0 PID: 662 Comm: NetworkManager Tainted: G [] ? raw_notifier_call_chain+0x16/0x20 [] __dev_open+0xce/0x150 [] __dev_change_flags+0xa1/0x170 [] dev_change_flags+0x29/0x70 [] do_setlink+0x39f/0xb40 [] ? nla_parse+0x32/0x120 [] rtnl_newlink+0x604/0x900 [] ? netlink_unicast+0x193/0x1c0 [] ? security_capable+0x18/0x20 [] ? ns_capable+0x2d/0x60 [] rtnetlink_rcv_msg+0xf5/0x270 [] ? rhashtable_lookup_compare+0x5d/0xa0 [] ? rtnetlink_rcv+0x40/0x40 [] netlink_rcv_skb+0xb9/0xe0 [] rtnetlink_rcv+0x2c/0x40 [] netlink_unicast+0x12d/0x1c0 [] netlink_sendmsg+0x4d3/0x630 [] ? sock_has_perm+0x72/0x90 [] do_sock_sendmsg+0x9f/0xc0 [ 3324.703482] RIP [] xennet_open+0x180/0x182 [xen_netfront] CC: David S. Miller Signed-off-by: Gonglei Full name required for this tag. [...] MBR, Sergei ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 83119: tolerable FAIL - PUSHED
flight 83119 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/83119/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 guest-saverestorefail never pass
test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass
test-amd64-i386-libvirt 12 migrate-support-checkfail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass
test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass
test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass
version targeted for testing:
libvirt 647ac97ab6797fa2de58c1a8d36811a3fb915e94
baseline version:
libvirt cda1cc170f07b45911b3dad03e42c8ebfc210fa1
Last test of basis82949 2016-02-17 04:25:44 Z3 days
Testing same since83119 2016-02-19 04:58:42 Z1 days1 attempts
People who touched revisions under test:
Bjoern Walk
Cole Robinson
Erik Skultety
John Ferlan
Ján Tomko
Martin Kletzander
Matthias Bolte
Michal Privoznik
Peter Krempa
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-armhf-pvopspass
build-i386-pvops pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm fail
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt pass
test-amd64-amd64-libvirt-pairpass
test-amd64-i386-libvirt-pair pass
test-armhf-armhf-libvirt-qcow2 fail
test-armhf-armhf-libvirt-raw fail
test-amd64-amd64-libvirt-vhd pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=libvirt
+ revision=647ac97ab6797fa2de58c1a8d36811a3fb915e94
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push libvirt
647ac97ab6797fa2de58c1a8d36811a3fb915e94
+ branch=libvirt
+ revisio
Re: [Xen-devel] [PATCH v2 05/30] xen/public: Export cpu featureset information in the public API
On 19/02/16 22:03, Joao Martins wrote:
> On 02/19/2016 05:55 PM, Andrew Cooper wrote:
>> On 19/02/16 17:29, Joao Martins wrote:
>>> On 02/05/2016 01:41 PM, Andrew Cooper wrote:
For the featureset to be a useful object, it needs a stable
interpretation, a
property which is missing from the current hw_caps interface.
Additionly, introduce TSC_ADJUST, SHA, PREFETCHWT1, ITSC, EFRO and CLZERO
which will be used by later changes.
To maintain compilation, FSCAPINTS is currently hardcoded at 9. Future
changes will change this to being dynamically generated.
Signed-off-by: Andrew Cooper
>>> Hey Andrew!
>>>
>>> There are a few word motions in this patch:
>> Indeed there are. They are in aid of getting a new clean interface.
>>
>>> [current] [this series]
>>> word 0 -> word 0
>>> word 4 -> word 1
>>> word 1,6 -> word 2,3
>>> word 2 -> word 4
>>> word 7,8 -> word 5,6
>>> -> word 7 (new leaf not previously described)
>>> -> word 8 (new leaf not previously described)
>>> word 3 -> word 9 (linux defined mapping)
>>>
>>> Since you're proposing the stabilization of physinfo.hw_caps
>> Stabilising of physinfo.hw_caps is a side effect, but it has shifted
>> words in the past (c/s 4f4eec3, 6c421a1, 9c907c6). It is not a stable
>> interface from Xen, and cannot be relied upon.
>>
>> It has also never had a published ABI.
>>
> Thanks for the clarification! I thought that it was sort of a stable API
> because
> it was exposed through libxl, but I got the wrong idea entirely.
Supposedly so. In reality, a number of poor decisions were made when
declaring certain things stable.
>
>>> and given that this
>>> is exposed on both sysctl and libxl (through libxl_hwcap) shouldn't its size
>>> match the real one (boot_cpu_data.x86_capability) i.e. NCAPINTS ?
>>> Additionally I
>>> see that libxl_hwcap is also hardcoded to 8 alongside struct
>>> xen_sysctl_physinfo
>>> when it should be 10 ?
>> Hardcoding of the size in sysctl can be worked around. Fixing libxl is
>> harder.
>>
>> The synthetic leaves are internal and should not be exposed.
>>
>>> libxl users could potentially make use of this hwcap field to see what
>>> features
>>> the host CPU supports.
>> The purpose of the new featureset interface is to have stable object
>> which can be used by higher level toolstacks.
>>
>> This is done by pretending that hw_caps never existed, and replacing it
>> wholesale with a bitmap, (specified as variable length and safe to
>> zero-extend), with an ABI in the public header files detailing what each
>> bit means.
> Given that you introduce a new API for libxc (xc_get_cpu_featureset()) perhaps
> an equivalent to libxl could also be added? That wat users of libxl could also
> query about the host and guests supported features. I would be happy to
> produce
> patches towards that.
In principle, this is fine. Part of this is covered by the xen-cpuid
utility in a later patch.
Despite my plans to further rework guest cpuid handling, the principle
of the {raw,host,pv,hvm}_featuresets is expected to stay, and be usable
in their current form.
However, other details such as the hvm hap and shadow mask are expected
to change moving forwards, so shouldn't be made into a stable API.
Note also that the current "inverted" mask is subject to some redesign,
following the "x86: workaround inability to fully restore FPU state"
issue David was working on.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86: CONFIG_X86 defined by Kconfig
On 20/02/16 15:34, Doug Goldstein wrote: > CONFIG_X86 is defined by Kconfig when building for x86. > > Signed-off-by: Doug Goldstein Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-mingo-tip-master test] 83116: regressions - FAIL
flight 83116 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/83116/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684 build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 60684 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate fail REGR. vs. 60684 test-amd64-amd64-xl-xsm 15 guest-localmigratefail REGR. vs. 60684 test-amd64-amd64-libvirt 15 guest-saverestore.2 fail REGR. vs. 60684 test-amd64-amd64-xl 15 guest-localmigratefail REGR. vs. 60684 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2 fail REGR. vs. 60684 test-amd64-amd64-xl-credit2 15 guest-localmigratefail REGR. vs. 60684 test-amd64-amd64-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 60684 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 60684 test-amd64-i386-libvirt-xsm 15 guest-saverestore.2 fail blocked in 60684 test-amd64-i386-libvirt 15 guest-saverestore.2 fail blocked in 60684 test-amd64-i386-xl 15 guest-localmigrate fail blocked in 60684 test-amd64-i386-xl-xsm 15 guest-localmigrate fail blocked in 60684 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked in 60684 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked in 60684 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail blocked in 60684 test-amd64-i386-pair 22 guest-migrate/dst_host/src_host fail blocked in 60684 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 60684 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 60684 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass version targeted for testing: linux58e86b4f400d7a5649d3c4d554f3dedd9f79903e baseline version: linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0 Last test of basis60684 2015-08-13 04:21:46 Z 191 days Failing since 60712 2015-08-15 18:33:48 Z 188 days 134 attempts Testing same since83116 2016-02-19 04:45:15 Z1 days1 attempts jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl fail test-amd64-i386-xl fail test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm
Re: [Xen-devel] [PATCH v2 05/30] xen/public: Export cpu featureset information in the public API
On 02/20/2016 04:17 PM, Andrew Cooper wrote:
> On 19/02/16 22:03, Joao Martins wrote:
>> On 02/19/2016 05:55 PM, Andrew Cooper wrote:
>>> On 19/02/16 17:29, Joao Martins wrote:
On 02/05/2016 01:41 PM, Andrew Cooper wrote:
> For the featureset to be a useful object, it needs a stable
> interpretation, a
> property which is missing from the current hw_caps interface.
>
> Additionly, introduce TSC_ADJUST, SHA, PREFETCHWT1, ITSC, EFRO and CLZERO
> which will be used by later changes.
>
> To maintain compilation, FSCAPINTS is currently hardcoded at 9. Future
> changes will change this to being dynamically generated.
>
> Signed-off-by: Andrew Cooper
Hey Andrew!
There are a few word motions in this patch:
>>> Indeed there are. They are in aid of getting a new clean interface.
>>>
[current] [this series]
word 0 -> word 0
word 4 -> word 1
word 1,6 -> word 2,3
word 2 -> word 4
word 7,8 -> word 5,6
-> word 7 (new leaf not previously described)
-> word 8 (new leaf not previously described)
word 3 -> word 9 (linux defined mapping)
Since you're proposing the stabilization of physinfo.hw_caps
>>> Stabilising of physinfo.hw_caps is a side effect, but it has shifted
>>> words in the past (c/s 4f4eec3, 6c421a1, 9c907c6). It is not a stable
>>> interface from Xen, and cannot be relied upon.
>>>
>>> It has also never had a published ABI.
>>>
>> Thanks for the clarification! I thought that it was sort of a stable API
>> because
>> it was exposed through libxl, but I got the wrong idea entirely.
>
> Supposedly so. In reality, a number of poor decisions were made when
> declaring certain things stable.
>
>>
and given that this
is exposed on both sysctl and libxl (through libxl_hwcap) shouldn't its
size
match the real one (boot_cpu_data.x86_capability) i.e. NCAPINTS ?
Additionally I
see that libxl_hwcap is also hardcoded to 8 alongside struct
xen_sysctl_physinfo
when it should be 10 ?
>>> Hardcoding of the size in sysctl can be worked around. Fixing libxl is
>>> harder.
>>>
>>> The synthetic leaves are internal and should not be exposed.
>>>
libxl users could potentially make use of this hwcap field to see what
features
the host CPU supports.
>>> The purpose of the new featureset interface is to have stable object
>>> which can be used by higher level toolstacks.
>>>
>>> This is done by pretending that hw_caps never existed, and replacing it
>>> wholesale with a bitmap, (specified as variable length and safe to
>>> zero-extend), with an ABI in the public header files detailing what each
>>> bit means.
>> Given that you introduce a new API for libxc (xc_get_cpu_featureset())
>> perhaps
>> an equivalent to libxl could also be added? That wat users of libxl could
>> also
>> query about the host and guests supported features. I would be happy to
>> produce
>> patches towards that.
>
> In principle, this is fine. Part of this is covered by the xen-cpuid
> utility in a later patch.
>
OK.
> Despite my plans to further rework guest cpuid handling, the principle
> of the {raw,host,pv,hvm}_featuresets is expected to stay, and be usable
> in their current form.
That's great to hear. The reason I brought this up is because libvirt has the
idea of cpu model and features associated with it (similar to qemu -cpu
XXX,+feature,-feature stuff but in an hypervisor agnostic manner that other
architectures can also use). libvirt could do mostly everything on its own, but
it still needs to know what the host supports. Based on that it then calculates
the lowest common denominator of cpu features to be enabled or masked out for
guests when comparing to an older family in a pool of servers. Though PV/HVM
(with{,out} hap/shadow) have different feature sets as you mention. So libvirt
might be thrown into error since a certain feature isn't sure to be set/masked
for a certain type of guest. So knowing those (i.e {pv,hvm,...}_featuresets in
advance lets libxl users make more reliable usage of the libxl cpuid policies to
more correctly normalize the cpuid for each type of guest.
>
> However, other details such as the hvm hap and shadow mask are expected
> to change moving forwards, so shouldn't be made into a stable API.
>
> Note also that the current "inverted" mask is subject to some redesign,
> following the "x86: workaround inability to fully restore FPU state"
> issue David was working on.
Ah, Thanks for the heads up!
Joao
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] pre Sandy bridge IOMMU support (gm45)
Le lun. 1 févr. 2016 à 07:35, Jan Beulich a écrit : > >>> On 01.02.16 at 13:28, wrote: > > On Mon, Feb 01, 2016 at 12:59:00AM -0700, Jan Beulich wrote: > >> >>> On 30.01.16 at 02:47, wrote: > >> > On Tue, Jan 26, 2016 at 04:37:05AM -0700, Jan Beulich wrote: > >> >> (re-adding xen-devel) > >> >> > >> >> >>> On 26.01.16 at 12:28, wrote: > >> >> > Iommu=0 let the whole Qubes system work, without enforcing hardware > >> >> > compartimentalisation (iommu is enforced in software mode) > >> >> > > >> >> > When iommu=no-igfx is enforced, shell console boot up works > flawlessly. > > All > >> >> > domu machines get booted up. A system hang will happen at the > moment a > > domu > >> >> > machine does graphic rendering, > >> >> > >> >> And this is (other than I originally implied) without passing through > >> >> the IGD to the DomU? If so, I can't see the difference between a > >> >> guest rendering to its display (and vncviewer or whatever frontend > >> >> you use converting this to rendering on the host) and rendering > >> >> which originates in the host. > >> > > >> > Not sure if relevant, but window content is mapped from PV domU > directly > >> > into X server (in dom0) address space, using xc_map_foreign_pages. It > is > >> > done by hacking XShmAttach function. Not sure what graphics driver do > >> > with it next. Theoretically it could be possible that driver will > direct IGD > >> > to do DMA directly from that place, but I guess it does not. > >> > >> Interesting. This then really needs to be investigated from the > >> Qubes end rather than here. Possible resulting patches, if > >> relevant outside of that unusual setup, would then of course be > >> appreciated to be sent here. > > > Interesting fact: kde corrupts video buffer and make system hang faster then it's xfce counterparts. > > Note that Thierry said "The point is the iommu=no-igfx doesn't fix the > > issue", so either it is totally unrelated issue, or iommu=no-igfx is > > broken. Does iommu=no-igfx have any meaning when IDG is _not_ passed > > through to some domU? > > Yes: Iirc that option turns off the IOMMU responsible for IGD. > > I suppose passing iommu=dom0-passthrough to hypervisor and passing *intel_iommu*=*igfx_off to dom0 *may be what is desired here, but hypervisor refuses to boot without iommu=no-igfx flag. > And generally - is IOMMU used in any way for dom0 > > devices? > > Of course; by how much depends on what options you use (see > the command line doc). > Qubes does't use any specifics. > > > Is Linux kernel able to utilize it for its own purposes (my > > guess: no)? > > Under Xen? If so - indeed, no. > Wouldn't it be more natural if i915 iommu would be deactivated in kernel with *intel_iommu*=*igfx_off option being passed to dom0?* > > > Somehow unrelated: I've tried to get p2m iommu mapping using `xl > > debug-key o`, but it's too long (and xenconsoled isn't fast enough to > > catch it into hypervisor.log). Is is possible to enlarge console ring > > buffer at runtime? > > No. > > > If not, is `conring_size` the right option? > > Yes. > > > How large > > it should be (aprox) for `xl debug-key o` output? > > Depends on the amount of memory page tables need to be created > for as well as how fragmented memory was at the time memory > allocation for domains happens. I'm afraid you can only try it out. > > Jan > > Would it be possible to lend a x200 laptop to the most interested/motivated developer in making i915/iommu work correctly for this laptop? I don't see how I can troubleshoot this deeper by myself alone. Thierry ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 05/30] xen/public: Export cpu featureset information in the public API
On 20/02/16 17:39, Joao Martins wrote:
>
> and given that this
> is exposed on both sysctl and libxl (through libxl_hwcap) shouldn't its
> size
> match the real one (boot_cpu_data.x86_capability) i.e. NCAPINTS ?
> Additionally I
> see that libxl_hwcap is also hardcoded to 8 alongside struct
> xen_sysctl_physinfo
> when it should be 10 ?
Hardcoding of the size in sysctl can be worked around. Fixing libxl is
harder.
The synthetic leaves are internal and should not be exposed.
> libxl users could potentially make use of this hwcap field to see what
> features
> the host CPU supports.
The purpose of the new featureset interface is to have stable object
which can be used by higher level toolstacks.
This is done by pretending that hw_caps never existed, and replacing it
wholesale with a bitmap, (specified as variable length and safe to
zero-extend), with an ABI in the public header files detailing what each
bit means.
>>> Given that you introduce a new API for libxc (xc_get_cpu_featureset())
>>> perhaps
>>> an equivalent to libxl could also be added? That wat users of libxl could
>>> also
>>> query about the host and guests supported features. I would be happy to
>>> produce
>>> patches towards that.
>> In principle, this is fine. Part of this is covered by the xen-cpuid
>> utility in a later patch.
>>
> OK.
>
>> Despite my plans to further rework guest cpuid handling, the principle
>> of the {raw,host,pv,hvm}_featuresets is expected to stay, and be usable
>> in their current form.
> That's great to hear. The reason I brought this up is because libvirt has the
> idea of cpu model and features associated with it (similar to qemu -cpu
> XXX,+feature,-feature stuff but in an hypervisor agnostic manner that other
> architectures can also use). libvirt could do mostly everything on its own,
> but
> it still needs to know what the host supports. Based on that it then
> calculates
> the lowest common denominator of cpu features to be enabled or masked out for
> guests when comparing to an older family in a pool of servers. Though PV/HVM
> (with{,out} hap/shadow) have different feature sets as you mention. So libvirt
> might be thrown into error since a certain feature isn't sure to be set/masked
> for a certain type of guest. So knowing those (i.e {pv,hvm,...}_featuresets in
> advance lets libxl users make more reliable usage of the libxl cpuid policies
> to
> more correctly normalize the cpuid for each type of guest.
Does libvirt currently use hw_caps (and my series will inadvertently
break it), or are you looking to do some new work for future benefit?
Sadly, cpuid levelling is a quagmire and not as simple as just choosing
the common subset of bits. When I started this project I was expecting
it to be bad, but nothing like as bad as it has turned out to be.
As an example, the "deprecates fcs/fds" bit which is the subject of the
"inverted" mask. The meaning of the bit is "hardware no longer supports
x87 fcs/fds, and they are hardwired to zero".
Originally, the point of the inverted mask was to make a "featureset"
which could be levelled sensibly without specific knowledge of the
meaning of each bit. This property is important for forwards
compatibility, and avoiding unnecessary complexity in higher level
toolstack components.
However, with hindsight, attempting to level this bit is pointless. It
is a statement about a change in pre-existing behaviour of an element of
the cpu pipeline, and the pipeline behaviour will not change depending
on how the bit is advertised to the guest. Another bit, "fdp exception
only" is in a similar bucket.
Other issues, which I haven't even tried to tackle in this series, are
items such as the MXCSR mask. The real value cannot be levelled, is
expected to remain constant after boot, and liable to induce #GP faults
on fxrstor if it changes. Alternatively, there is EFER.LMSLE (long mode
segment limit enable) which doesn't even have a feature bit to indicate
availability (not that I can plausibly see an OS actually turning that
feature on).
A toolstack needs to handles all of:
* The maximum "configuration" available to a guest on the available servers.
* Which bits of that can be controlled, and which will simply leak through.
* What the guest actually saw when it booted.
(I use configuration here to include items such as max leaf, max phys
addr, etc which are important to be levelled, but not included in the
plain feature bits in cpuid).
My longterm plans involve:
* Having Xen construct a full "maximum" cpuid policy, rather than just a
featureset.
* Per-domain cpuid policy, seeded from maximum on domain_create, and
modified where appropriate (e.g. hap vs shadow, PV guest switching
between native and compat mode).
* All validity checking for updates in the set_cpuid hypercall rather
than being deferred to the cpuid intercept point.
* A get_cpuid hypercall so a to
[Xen-devel] [linux-linus test] 83118: regressions - trouble: blocked/broken/fail/pass
flight 83118 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/83118/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254 build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 59254 test-amd64-amd64-xl 15 guest-localmigratefail REGR. vs. 59254 test-amd64-amd64-xl-credit2 15 guest-localmigratefail REGR. vs. 59254 test-amd64-i386-xl-xsm 15 guest-localmigratefail REGR. vs. 59254 test-amd64-amd64-xl-xsm 15 guest-localmigratefail REGR. vs. 59254 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate fail REGR. vs. 59254 test-amd64-i386-xl 15 guest-localmigratefail REGR. vs. 59254 test-amd64-amd64-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 59254 test-amd64-i386-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 59254 test-armhf-armhf-xl-multivcpu 8 leak-check/basis(8) fail REGR. vs. 59254 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail REGR. vs. 59254 test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 59254 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 59254 test-armhf-armhf-xl-rtds 11 guest-start fail REGR. vs. 59254 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail baseline untested test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline untested test-armhf-armhf-xl-vhd 8 leak-check/basis(8) fail baseline untested test-amd64-amd64-libvirt 15 guest-saverestore.2 fail blocked in 59254 test-amd64-i386-libvirt 15 guest-saverestore.2 fail blocked in 59254 test-amd64-i386-libvirt-xsm 15 guest-saverestore.2 fail blocked in 59254 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2 fail blocked in 59254 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 59254 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass version targeted for testing: linux705d43dbe10d6e213a75187ac92b
[Xen-devel] [xen-4.6-testing test] 83120: regressions - FAIL
flight 83120 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/83120/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 81632 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail REGR. vs. 81632 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 81632 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 81632 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 81632 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass version targeted for testing: xen 046e5d0218a0600f9a21fd3b5a5ccfbaaf4357b6 baseline version: xen d77bac5c064ffb9dbb5b89b55b89853f1b784ebf Last test of basis81632 2016-02-09 15:11:54 Z 11 days Testing same since83001 2016-02-18 14:40:57 Z2 days2 attempts People who touched revisions under test: Alan.Robinson Andrew Cooper Anthony PERARD Boris Ostrovsky Dirk Behme George Dunlap Ian Campbell Jan Beulich Juergen Gross Kevin Tian jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-
[Xen-devel] [xen-4.5-testing test] 83135: tolerable FAIL - PUSHED
flight 83135 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/83135/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail in 83003 pass in 83135 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail pass in 83003 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 78640 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 83003 blocked in 78736 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 83003 like 78640 test-amd64-amd64-xl-rtds 6 xen-boot fail like 78736 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 78736 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 78736 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 78736 test-armhf-armhf-xl-rtds 11 guest-start fail like 78736 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 83003 never pass test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 83003 never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 10 guest-start fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 10 guest-start fail never pass test-armhf-armhf-libvirt-raw 10 guest-start fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass version targeted for testing: xen fe71162ab965d4a3344bb867f88e967806c80af5 baseline version: xen 7afddd3b945b11a7f5162d1355283b6b9ae7aba3 Last test of basis78736 2016-01-21 20:56:44 Z 30 days Testing same since83003 2016-02-18 14:45:02 Z2 days2 attempts People who touched revisions under test: Alan.Robinson Andrew Cooper Anthony PERARD Dirk Behme George Dunlap Ian Campbell Jan Beulich Juergen Gross Kevin Tian jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass 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-qemuu-nested-amdfail test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-am
Re: [Xen-devel] pre Sandy bridge IOMMU support (gm45)
Le mar. 26 janv. 2016 à 05:52, Jan Beulich a écrit : > >>> On 25.01.16 at 22:49, wrote: > > The case is 1) disabling iommu for IGD, unilaterally since i915 + gm45 > > doesn't play well together. Iommu is still desired to isolate usb and > > network devices, so we don't want to disable iommu completely. The side > > effect of this would be to have IGD only for dom0, which would also > > completely make sense in this use case. > > > > The point is the iommu=no-igfx doesn't fix the issue, since remapping > seems > > to still happen for IGD. Does that make sense ? > > It certainly may make sense, just that in what you have written so > far I don't think I've been able to spot any evidence thereof. Since, > as you say, nothing interesting gets logged by Xen, you must be > drawing this conclusion from something (or else you wouldn't say > "doesn't fix the issue"). > > Jan > > Here is some interesting lines showing Xen failing without iommu=no-igfx: --- /home/john/Downloads/amtterm/x200_xen_debug-normal-no_ts.txt +++ /home/john/Downloads/amtterm/x200_xen_debug-iommu-no_igfx-no_ts.txt @@ -339,23 +339,10 @@ (XEN) [VT-D]iommu.c:1465: d0:PCI: map :00:1f.3 (XEN) [VT-D]iommu.c:1453: d0:PCIe: map :03:00.0 (XEN) [VT-D]iommu.c:729: iommu_enable_translation: iommu->reg = 82c000205000 -(XEN) [VT-D]iommu.c:729: iommu_enable_translation: iommu->reg = 82c000203000 +(XEN) [VT-D]iommu.c:719: BIOS did not enable IGD for VT properly. Disabling IGD VT-d engine. (XEN) [VT-D]iommu.c:729: iommu_enable_translation: iommu->reg = 82c000201000 (XEN) [VT-D]iommu.c:729: iommu_enable_translation: iommu->reg = 82c000207000 (XEN) Scrubbing Free RAM on 1 nodes using 2 CPUs -(XEN) [VT-D]iommu.c:873: iommu_fault_status: Fault Overflow -(XEN) [VT-D]iommu.c:875: iommu_fault_status: Primary Pending Fault -(XEN) [VT-D]DMAR:[DMA Write] Request device [:00:02.0] fault addr ff000, iommu reg = 82c000203000 -(XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set -(XEN) print_vtd_entries: iommu 8301363fa7d0 dev :00:02.0 gmfn ff -(XEN) root_entry = 8301363f4000 -(XEN) root_entry[0] = 80fa001 -(XEN) context = 8300080fa000 -(XEN) context[10] = 1_8ae0001 -(XEN) l3 = 830008ae -(XEN) l3_index = 3f -(XEN) l3[3f] = 0 -(XEN) l3[3f] not present (XEN) done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All I restate my comprehension. iommu=no-igfx needs to be passed to hypervisor for it to boot. iommu=dom0-passthrough would also be needed for dom0 tobe able to unset iommu usage for itself? For Dom0 to have access to device, I also understand that intel_iommu=igfx_off kernel option would need to be passed to i915 driver of dom0? Doing so still fails without error. Any hint? Doing so by providing dom0-pass ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-next test] 83159: regressions - trouble: blocked/broken/fail/pass
flight 83159 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/83159/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-qcow2 3 host-install(3) broken REGR. vs. 82911 test-amd64-i386-libvirt-xsm 14 guest-saverestore fail REGR. vs. 82911 test-amd64-i386-libvirt 14 guest-saverestore fail REGR. vs. 82911 test-amd64-amd64-xl-multivcpu 14 guest-saverestorefail REGR. vs. 82911 test-amd64-i386-xl-xsm6 xen-boot fail REGR. vs. 82911 test-amd64-amd64-libvirt-xsm 6 xen-boot fail REGR. vs. 82911 test-amd64-amd64-xl-pvh-amd 6 xen-boot fail REGR. vs. 82911 test-amd64-i386-qemut-rhel6hvm-amd 6 xen-bootfail REGR. vs. 82911 test-armhf-armhf-xl-xsm 11 guest-start fail REGR. vs. 82911 test-armhf-armhf-libvirt-xsm 11 guest-start fail REGR. vs. 82911 test-amd64-amd64-qemuu-nested-amd 6 xen-boot fail REGR. vs. 82911 test-amd64-amd64-xl-qemut-win7-amd64 12 guest-saverestore fail REGR. vs. 82911 test-amd64-i386-xl-qemuu-win7-amd64 6 xen-boot fail REGR. vs. 82911 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-saverestore fail REGR. vs. 82911 test-amd64-i386-pair 10 xen-boot/dst_host fail REGR. vs. 82911 test-amd64-i386-pair 9 xen-boot/src_host fail REGR. vs. 82911 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host fail REGR. vs. 82911 test-amd64-i386-libvirt-pair 9 xen-boot/src_host fail REGR. vs. 82911 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 82911 test-armhf-armhf-libvirt-raw 9 debian-di-install fail REGR. vs. 82911 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail REGR. vs. 82911 test-amd64-amd64-xl-rtds 14 guest-saverestore fail REGR. vs. 82911 test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10 fail blocked in 82911 build-i386-rumpuserxen6 xen-buildfail like 82911 test-amd64-amd64-xl 15 guest-localmigrate fail like 82911 build-amd64-rumpuserxen 6 xen-buildfail like 82911 test-amd64-amd64-xl-xsm 15 guest-localmigrate fail like 82911 test-amd64-amd64-libvirt 15 guest-saverestore.2 fail like 82911 test-amd64-i386-xl 15 guest-localmigrate fail like 82911 test-amd64-amd64-pair 22 guest-migrate/dst_host/src_host fail like 82911 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail like 82911 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeatfail like 82911 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeatfail like 82911 test-armhf-armhf-xl-rtds 11 guest-start fail like 82911 test-armhf-armhf-xl-vhd 9 debian-di-installfail like 82911 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass version targeted for testing: linuxb6186245890a0052d230a1e422961d0c000ae346 baselin
