|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.6-testing test] 95328: regressions - FAIL
flight 95328 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/95328/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 95235 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 95235 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail blocked in 95235 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 95235 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 95235 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 95235 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 95235 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-xsm 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestore fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass test-amd64-amd64-libvirt 12 migrate-support-check fail never pass test-amd64-i386-libvirt 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt 14 guest-saverestore fail never pass test-armhf-armhf-libvirt 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-check 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-check fail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass test-armhf-armhf-xl 12 migrate-support-check fail never pass test-armhf-armhf-xl 13 saverestore-support-check fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-check fail never pass test-armhf-armhf-xl-xsm 12 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestore fail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestore fail never pass test-armhf-armhf-xl-vhd 11 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-check fail never pass version targeted for testing: xen 2805844bf20e1cae824d0ccc864e46dfa8f134da baseline version: xen f354fb4670132c98112222b433ba34fb8edd46f7 Last test of basis 95235 2016-06-03 10:55:03 Z 3 days Testing same since 95328 2016-06-06 13:42:21 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> 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-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-qemut-debianhvm-amd64-xsm pass 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-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-armhf-armhf-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail 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-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass 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-rumpuserxen-amd64 fail 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-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-i386-rumpuserxen-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvh-intel fail test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt fail test-amd64-i386-libvirt pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 fail test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-amd64-i386-xl-qemut-winxpsp3-vcpus1 pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-amd64-xl-qemut-winxpsp3 pass test-amd64-i386-xl-qemut-winxpsp3 pass test-amd64-amd64-xl-qemuu-winxpsp3 pass test-amd64-i386-xl-qemuu-winxpsp3 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 Not pushing. ------------------------------------------------------------ commit 2805844bf20e1cae824d0ccc864e46dfa8f134da Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Tue May 3 17:24:32 2016 +0100 libxl: Do not trust frontend for channel in getinfo libxl_device_channel_getinfo needs to examine devices without trusting frontend-controlled data. So: * Use /libxl to find the backend path. * Parse the backend path to find the backend domid, rather than reading it from the frontend. * Tolerate FRONTEND/tty vanishing. Note that there is a strange off-by-one error in the computation of both fe_path and libxl_path in libxl_device_channel_getinfo: the incoming channel->devid, which is copied to channelinfo->devid, has +1 applied to calculate the frontend path (and, after this patch, the libxl path). I.e., the devid passed to libxl_device_channel_getinfo must be one less than the actual devid for the device being asked about. This is actually a bug which mirrors a bug in libxl__append_channel_list, which fills in the devids of the channel devices it finds with sequentially increasing numbers starting at 0. In the usual case channels have real devids starting at 1 (because there is the console, which is devid 0, but not a channel). So these bugs usually cancel out. We do not address this problem at this time. This bug does not have any security implications. This patch is part of XSA-175. Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit c70568e4c8c695a7d3e275692a7699bf28904253 Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Tue May 3 17:01:56 2016 +0100 libxl: Do not trust frontend for channel in list libxl_device_channel_list should not trust frontend-provided data. So it needs to iterate using the /libxl paths, and read the backend path out of /libxl. However, it also filters out pure "consoles", which are channels without a "name". But the name was stored only in the frontend directory, which the frontend can delete. So store the name in the backend too. (Ideally we would store it in /libxl, where the backend can't write to it either, but libxl__device_console_add not currently have access to the xenstore transaction used by libxl__device_generic_add. Protection against the backend will come later, in XSA-178.) Because the libxl paths are defined to be in terms of the frontend device types, not the backend device types, it is no longer correct for libxl__append_channel_list to take a type argument. Abolish this (with no functional effect). This is part of XSA-175. Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit d5ef82f7f399e1369c0564da998c9dae0225842c Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Tue May 3 16:31:07 2016 +0100 libxl: Do not trust frontend for nic in getinfo libxl_device_nic_getinfo needs to examine devices without trusting frontend-controlled data. So: * Use /libxl to find the backend path. * Parse the backend path to find the backend domid, rather than reading it from the frontend. This is part of XSA-175. Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit c17610e92011d4688d435e5b536be09a7b5139c5 Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Tue May 3 15:52:53 2016 +0100 libxl: Do not trust frontend for nic in libxl_devid_to_device_nic Find the backend by reading the pointer in /libxl rather than in the guest's frontend area. This is part of XSA-175. Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 98a6b47d8b42d6a76a245afe2a3cbc56686a4451 Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Tue May 3 16:00:20 2016 +0100 libxl: Do not trust frontend for vtpm in getinfo libxl_device_vtpm_getinfo needs to examine devices without trusting frontend-controlled data. So: * Use /libxl to find the backend path. * Parse the backend path to find the backend domid, rather than reading it from the frontend. This is part of XSA-175. Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 1098572bad7ce2fa4e8828b13ba3301c3b3ee32b Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Tue May 3 15:58:32 2016 +0100 libxl: Do not trust frontend for vtpm list libxl_device_vtpm_list needs to enumerate and identify devices without trusting frontend-controlled data. So * Use the /libxl path to enumerate vtpms. * Use the /libxl path to find the corresponding backends. * Parse the backend path to find the backend domid. This is part of XSA-175. Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 7dcbbe4946f15b431b6831eebcb63772fdf34ce5 Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Fri Apr 29 19:21:51 2016 +0100 libxl: Do not trust frontend for disk in getinfo * Rename the frontend variable to `fe_path' to check we caught them all * Read the backend path from /libxl, rather than from the frontend * Parse the backend domid from the backend path, rather than reading it from the frontend (and add the appropriate error path and initialisation) This is part of XSA-175. Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit a670079b3a83181b8d6ad86f7f0a1f4c328126fb Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Wed Apr 27 16:08:49 2016 +0100 libxl: Do not trust frontend for disk eject event Use the /libxl path for interpreting disk eject watch events: do not read the backend path out of the frontend. Instead, use the version in /libxl. That avoids us relying on the guest-modifiable $frontend/backend pointer. To implement this we store the path /libxl/$guest/device/vbd/$devid/backend in the evgen structure. This is part of XSA-175. Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 66635e7416ec27713915fec69e8731bb02f5edea Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Wed May 4 15:30:32 2016 +0100 libxl: Do not trust frontend in libxl__device_nextid When selecting the devid for a new device, we should look in /libxl/device for existing devices, not in the frontend area. This is part of XSA-175. Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 08599c8e2199e521e957e3f6e9f05f163e079c0b Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Tue May 3 18:39:36 2016 +0100 libxl: Do not trust frontend in libxl__devices_destroy We need to enumerate the devices we have provided to a domain, without trusting the guest-writeable (or, at least, guest-deletable) frontend paths. Instead, enumerate via, and read the backend path from, /libxl. The console /libxl path is regular, so the special case for console 0 is not relevant any more: /libxl/GUEST/device/console/0 will be found, and then libxl__device_destroy will DTRT to the right frontend path. This is part of XSA-175. Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 94a8dfa9329b1beaf1c752361f13fa467b0d7150 Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Wed Apr 27 16:34:19 2016 +0100 libxl: Provide libxl__backendpath_parse_domid Multiple places in libxl need to figure out the backend domid of a device. This can be discovered easily by looking at the backend path, which always starts /local/domain/$backend_domid/. There are no call sites yet. This is part of XSA-175. Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 71bdf79edee134c6e6a5d5f4d5c878af13a3e71d Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Wed Apr 27 15:50:01 2016 +0100 libxl: Record backend/frontend paths in /libxl/$DOMID This gives us a record of all the backends we have set up for a domain, which is separate from the frontends in /local/domain/$DOMID/device. In particular: 1. A guest has write permission for the frontend path: /local/domain/$DOMID/device/$KIND/$DEVID which means that the guest can completely delete the frontend. (They can't recreate it because they don't have write permission on the containing directory.) 2. A guest has write permission for the backend path recorded in the frontend, ie, it can write to /local/domain/$DOMID/device/$KIND/$DEVID/backend which means that the guest can break the association between frontend and backend. So we can't rely on iterating over the frontends to find all the backends, or examining a frontend to discover how a device is configured. So, have libxl__device_generic_add record the frontend and backend paths in /libxl/$DOMID/device, and have libxl__device_destroy remove them again. Create the containing directory /libxl/GUEST/device in libxl__domain_make. The already existing xs_rm in devices_destroy_cb will take care of removing it. This is part of XSA-175. Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |