flight 14682 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14682/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail REGR. vs. 14678
test-amd64-amd64-xl-qemut-winxpsp3 12 guest-localmigrate/x10 fail REGR. vs. 14678
test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail REGR. vs. 14678
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 14678
test-amd64-amd64-xl-sedf 5 xen-boot fail like 14678
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass
test-amd64-i386-win 16 leak-check/check fail never pass
test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass
test-amd64-i386-qemut-win-vcpus1 16 leak-check/check fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass
test-amd64-amd64-win 16 leak-check/check fail never pass
test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop fail never pass
test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail never pass
test-amd64-i386-qemut-win 16 leak-check/check fail never pass
test-amd64-amd64-xl-win 13 guest-stop fail never pass
test-amd64-amd64-qemut-win 16 leak-check/check fail never pass
test-amd64-amd64-xl-qemut-win 13 guest-stop fail never pass
version targeted for testing:
xen c91d9f6b6fba
baseline version:
xen 74d4a6cc5392
------------------------------------------------------------
People who touched revisions under test:
Daniel De Graaf <dgdegra@tycho.nsa.gov>
Dongxiao Xu <dongxiao.xu@intel.com>
Ian Campbell <ian.campbell@citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Roger Pau Monné <roger.pau@citrix.com>
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------
jobs:
build-amd64 pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-amd64-i386-xl pass
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-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-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-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-xl-sedf-pin fail
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-amd64-amd64-xl-sedf fail
test-amd64-i386-win-vcpus1 fail
test-amd64-i386-qemut-win-vcpus1 fail
test-amd64-i386-xl-qemut-win-vcpus1 fail
test-amd64-i386-xl-win-vcpus1 fail
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-amd64-win fail
test-amd64-i386-win fail
test-amd64-amd64-qemut-win fail
test-amd64-i386-qemut-win fail
test-amd64-amd64-xl-qemut-win fail
test-amd64-amd64-xl-win fail
test-amd64-i386-xend-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemuu-winxpsp3 fail
test-amd64-i386-xend-winxpsp3 fail
test-amd64-amd64-xl-winxpsp3 fail
------------------------------------------------------------
sg-report-flight on woking.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.
------------------------------------------------------------
changeset: 26280:c91d9f6b6fba
tag: tip
user: Daniel De Graaf <dgdegra@tycho.nsa.gov>
date: Thu Dec 13 11:44:02 2012 +0000
libxl: introduce XSM relabel on build
Allow a domain to be built under one security label and run using a
different label. This can be used to prevent the domain builder or
control domain from having the ability to access a guest domain's memory
via map_foreign_range except during the build process where this is
required.
Example domain configuration snippet:
seclabel='customer_1:vm_r:nomigrate_t'
init_seclabel='customer_1:vm_r:nomigrate_t_building'
Note: this does not provide complete protection from a malicious dom0;
mappings created during the build process may persist after the relabel,
and could be used to indirectly access the guest's memory. However, if
dom0 correctly unmaps the domain upon building, a the domU is protected
against dom0 becoming malicious in the future.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
changeset: 26279:ef9242f5846f
user: Ian Jackson <Ian.Jackson@eu.citrix.com>
date: Thu Dec 13 11:44:01 2012 +0000
libxl: qemu trad logdirty: Tolerate ENOENT on ret path
It can happen in error conditions that lds->ret_path doesn't exist,
and libxl__xs_read_checked signals this by setting got_ret=NULL. If
this happens, fail without crashing.
Reported-by: Alex Bligh <alex@alex.org.uk>,
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
changeset: 26278:69ec301b8ec2
user: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date: Thu Dec 13 11:44:01 2012 +0000
xen/arm: use strcmp in device_tree_type_matches
We want to match the exact string rather than the first subset.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
changeset: 26277:54340e92367f
user: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date: Thu Dec 13 11:44:00 2012 +0000
xen: get GIC addresses from DT
Get the address of the GIC distributor, cpu, virtual and virtual cpu
interfaces registers from device tree.
Note: I couldn't completely get rid of GIC_BASE_ADDRESS, GIC_DR_OFFSET
and friends because we are using them from mode_switch.S, that is
executed before device tree has been parsed. But at least mode_switch.S
is known to contain vexpress specific code anyway.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
changeset: 26276:db8800f09ac1
user: Jan Beulich <jbeulich@suse.com>
date: Thu Dec 13 11:22:54 2012 +0100
vscsiif: allow larger segments-per-request values
At least certain tape devices require fixed size blocks to be operated
upon, i.e. breaking up of I/O requests is not permitted. Consequently
we need an interface extension that (leaving aside implementation
limitations) doesn't impose a limit on the number of segments that can
be associated with an individual request.
This, in turn, excludes the blkif extension FreeBSD folks implemented,
as that still imposes an upper limit (the actual I/O request still
specifies the full number of segments - as an 8-bit quantity -, and
subsequent ring slots get used to carry the excess segment
descriptors).
The alternative therefore is to allow the frontend to pre-set segment
descriptors _before_ actually issuing the I/O request. I/O will then
be done by the backend for the accumulated set of segments.
To properly associate segment preset operations with the main request,
the rqid-s between them should match (originally I had hoped to use
this to avoid producing individual responses for the pre-set
operations, but that turned out to violate the underlying shared ring
implementation).
Negotiation of the maximum number of segments a particular backend
implementation supports happens through a new "segs-per-req" xenstore
node.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
changeset: 26275:74d4a6cc5392
user: Dongxiao Xu <dongxiao.xu@intel.com>
date: Wed Dec 12 10:47:18 2012 +0100
VMX: intr.c: remove i386 related code
i386 arch is no longer supported by Xen, remove the related code.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
========================================
commit 6a0cf3786f1964fdf5a17f88f26cb499f4e89c81
Author: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu Dec 6 12:35:58 2012 +0000
qemu-stubdom: prevent useless medium change
qemu-stubdom was stripping the prefix from the "params" xenstore
key in xenstore_parse_domain_config, which was then saved stripped in
a variable. In xenstore_process_event we compare the "param" from
xenstore (not stripped) with the stripped "param" saved in the
variable, which leads to a medium change (even if there isn't any),
since we are comparing something like aio:/path/to/file with
/path/to/file. This only happens one time, since
xenstore_parse_domain_config is the only place where we strip the
prefix. The result of this bug is the following:
xs_read_watch() -> /local/domain/0/backend/qdisk/19/5632/params hdc
close(7)
close blk: backend=/local/domain/0/backend/qdisk/19/5632
node=/local/domain/19/device/vbd/5632
(XEN) HVM18: HVM Loader
(XEN) HVM18: Detected Xen v4.3-unstable
(XEN) HVM18: Xenbus rings @0xfeffc000, event channel 4
(XEN) HVM18: System requested ROMBIOS
(XEN) HVM18: CPU speed is 2400 MHz
(XEN) irq.c:270: Dom18 PCI link 0 changed 0 -> 5
(XEN) HVM18: PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:270: Dom18 PCI link 1 changed 0 -> 10
(XEN) HVM18: PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:270: Dom18 PCI link 2 changed 0 -> 11
(XEN) HVM18: PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:270: Dom18 PCI link 3 changed 0 -> 5
(XEN) HVM18: PCI-ISA link 3 routed to IRQ5
(XEN) HVM18: pci dev 01:3 INTA->IRQ10
(XEN) HVM18: pci dev 03:0 INTA->IRQ5
(XEN) HVM18: pci dev 04:0 INTA->IRQ5
(XEN) HVM18: pci dev 02:0 bar 10 size lx: 02000000
(XEN) HVM18: pci dev 03:0 bar 14 size lx: 01000000
(XEN) HVM18: pci dev 02:0 bar 14 size lx: 00001000
(XEN) HVM18: pci dev 03:0 bar 10 size lx: 00000100
(XEN) HVM18: pci dev 04:0 bar 10 size lx: 00000100
(XEN) HVM18: pci dev 04:0 bar 14 size lx: 00000100
(XEN) HVM18: pci dev 01:1 bar 20 size lx: 00000010
(XEN) HVM18: Multiprocessor initialisation:
(XEN) HVM18: - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM18: - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM18: Testing HVM environment:
(XEN) HVM18: - REP INSB across page boundaries ... passed
(XEN) HVM18: - GS base MSRs and SWAPGS ... passed
(XEN) HVM18: Passed 2 of 2 tests
(XEN) HVM18: Writing SMBIOS tables ...
(XEN) HVM18: Loading ROMBIOS ...
(XEN) HVM18: 9660 bytes of ROMBIOS high-memory extensions:
(XEN) HVM18: Relocating to 0xfc001000-0xfc0035bc ... done
(XEN) HVM18: Creating MP tables ...
(XEN) HVM18: Loading Cirrus VGABIOS ...
(XEN) HVM18: Loading PCI Option ROM ...
(XEN) HVM18: - Manufacturer: http://ipxe.org
(XEN) HVM18: - Product name: iPXE
(XEN) HVM18: Option ROMs:
(XEN) HVM18: c0000-c8fff: VGA BIOS
(XEN) HVM18: c9000-d8fff: Etherboot ROM
(XEN) HVM18: Loading ACPI ...
(XEN) HVM18: vm86 TSS at fc00f680
(XEN) HVM18: BIOS map:
(XEN) HVM18: f0000-fffff: Main BIOS
(XEN) HVM18: E820 table:
(XEN) HVM18: [00]: 00000000:00000000 - 00000000:0009e000: RAM
(XEN) HVM18: [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED
(XEN) HVM18: HOLE: 00000000:000a0000 - 00000000:000e0000
(XEN) HVM18: [02]: 00000000:000e0000 - 00000000:00100000: RESERVED
(XEN) HVM18: [03]: 00000000:00100000 - 00000000:3f800000: RAM
(XEN) HVM18: HOLE: 00000000:3f800000 - 00000000:fc000000
(XEN) HVM18: [04]: 00000000:fc000000 - 00000001:00000000: RESERVED
(XEN) HVM18: Invoking ROMBIOS ...
(XEN) HVM18: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) stdvga.c:147:d18 entering stdvga and caching modes
(XEN) HVM18: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
(XEN) HVM18: Bochs BIOS - build: 06/23/99
(XEN) HVM18: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) HVM18: Options: apmbios pcibios eltorito PMM
(XEN) HVM18:
(XEN) HVM18: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) HVM18: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (10240 MBytes)
(XEN) HVM18: IDE time out
(XEN) HVM18: ata1 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-Rom
(XEN) HVM18: IDE time out
(XEN) HVM18:
(XEN) HVM18:
(XEN) HVM18:
(XEN) HVM18: Press F12 for boot menu.
(XEN) HVM18:
(XEN) HVM18: Booting from CD-Rom...
(XEN) HVM18: ata_is_ready returned 1
(XEN) HVM18: CDROM boot failure code : 0003
(XEN) HVM18: Boot from CD-Rom failed: could not read the boot disk
(XEN) HVM18:
(XEN) HVM18:
(XEN) HVM18: No bootable device.
(XEN) HVM18: Powering off in 30 seconds.
******************* BLKFRONT for /local/domain/19/device/vbd/5632 **********
backend at /local/domain/0/backend/qdisk/19/5632
Failed to read
/local/domain/0/backend/qdisk/19/5632/feature-flush-cache.
284420 sectors of 512 bytes
**************************
blk_open(/local/domain/19/device/vbd/5632) -> 7
As seen in this trace, the medium change happens just when the
guest is booting, which leads to the guest not being able to boot
because the BIOS is not able to access the device.
This is a regression from Xen 4.1, which is able to boot from "file:/"
based backends when using stubdomains.
[. By inspection, this patch does not change the flow for the
non-stubdom case. -iwj]
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
http://www.chiark.greenend.org.uk/~xensrcts/logs/14682/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail REGR. vs. 14678
test-amd64-amd64-xl-qemut-winxpsp3 12 guest-localmigrate/x10 fail REGR. vs. 14678
test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail REGR. vs. 14678
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 14678
test-amd64-amd64-xl-sedf 5 xen-boot fail like 14678
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass
test-amd64-i386-win 16 leak-check/check fail never pass
test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass
test-amd64-i386-qemut-win-vcpus1 16 leak-check/check fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass
test-amd64-amd64-win 16 leak-check/check fail never pass
test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop fail never pass
test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail never pass
test-amd64-i386-qemut-win 16 leak-check/check fail never pass
test-amd64-amd64-xl-win 13 guest-stop fail never pass
test-amd64-amd64-qemut-win 16 leak-check/check fail never pass
test-amd64-amd64-xl-qemut-win 13 guest-stop fail never pass
version targeted for testing:
xen c91d9f6b6fba
baseline version:
xen 74d4a6cc5392
------------------------------------------------------------
People who touched revisions under test:
Daniel De Graaf <dgdegra@tycho.nsa.gov>
Dongxiao Xu <dongxiao.xu@intel.com>
Ian Campbell <ian.campbell@citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Roger Pau Monné <roger.pau@citrix.com>
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------
jobs:
build-amd64 pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-amd64-i386-xl pass
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-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-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-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-xl-sedf-pin fail
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-amd64-amd64-xl-sedf fail
test-amd64-i386-win-vcpus1 fail
test-amd64-i386-qemut-win-vcpus1 fail
test-amd64-i386-xl-qemut-win-vcpus1 fail
test-amd64-i386-xl-win-vcpus1 fail
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-amd64-win fail
test-amd64-i386-win fail
test-amd64-amd64-qemut-win fail
test-amd64-i386-qemut-win fail
test-amd64-amd64-xl-qemut-win fail
test-amd64-amd64-xl-win fail
test-amd64-i386-xend-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemuu-winxpsp3 fail
test-amd64-i386-xend-winxpsp3 fail
test-amd64-amd64-xl-winxpsp3 fail
------------------------------------------------------------
sg-report-flight on woking.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.
------------------------------------------------------------
changeset: 26280:c91d9f6b6fba
tag: tip
user: Daniel De Graaf <dgdegra@tycho.nsa.gov>
date: Thu Dec 13 11:44:02 2012 +0000
libxl: introduce XSM relabel on build
Allow a domain to be built under one security label and run using a
different label. This can be used to prevent the domain builder or
control domain from having the ability to access a guest domain's memory
via map_foreign_range except during the build process where this is
required.
Example domain configuration snippet:
seclabel='customer_1:vm_r:nomigrate_t'
init_seclabel='customer_1:vm_r:nomigrate_t_building'
Note: this does not provide complete protection from a malicious dom0;
mappings created during the build process may persist after the relabel,
and could be used to indirectly access the guest's memory. However, if
dom0 correctly unmaps the domain upon building, a the domU is protected
against dom0 becoming malicious in the future.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
changeset: 26279:ef9242f5846f
user: Ian Jackson <Ian.Jackson@eu.citrix.com>
date: Thu Dec 13 11:44:01 2012 +0000
libxl: qemu trad logdirty: Tolerate ENOENT on ret path
It can happen in error conditions that lds->ret_path doesn't exist,
and libxl__xs_read_checked signals this by setting got_ret=NULL. If
this happens, fail without crashing.
Reported-by: Alex Bligh <alex@alex.org.uk>,
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
changeset: 26278:69ec301b8ec2
user: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date: Thu Dec 13 11:44:01 2012 +0000
xen/arm: use strcmp in device_tree_type_matches
We want to match the exact string rather than the first subset.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
changeset: 26277:54340e92367f
user: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date: Thu Dec 13 11:44:00 2012 +0000
xen: get GIC addresses from DT
Get the address of the GIC distributor, cpu, virtual and virtual cpu
interfaces registers from device tree.
Note: I couldn't completely get rid of GIC_BASE_ADDRESS, GIC_DR_OFFSET
and friends because we are using them from mode_switch.S, that is
executed before device tree has been parsed. But at least mode_switch.S
is known to contain vexpress specific code anyway.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
changeset: 26276:db8800f09ac1
user: Jan Beulich <jbeulich@suse.com>
date: Thu Dec 13 11:22:54 2012 +0100
vscsiif: allow larger segments-per-request values
At least certain tape devices require fixed size blocks to be operated
upon, i.e. breaking up of I/O requests is not permitted. Consequently
we need an interface extension that (leaving aside implementation
limitations) doesn't impose a limit on the number of segments that can
be associated with an individual request.
This, in turn, excludes the blkif extension FreeBSD folks implemented,
as that still imposes an upper limit (the actual I/O request still
specifies the full number of segments - as an 8-bit quantity -, and
subsequent ring slots get used to carry the excess segment
descriptors).
The alternative therefore is to allow the frontend to pre-set segment
descriptors _before_ actually issuing the I/O request. I/O will then
be done by the backend for the accumulated set of segments.
To properly associate segment preset operations with the main request,
the rqid-s between them should match (originally I had hoped to use
this to avoid producing individual responses for the pre-set
operations, but that turned out to violate the underlying shared ring
implementation).
Negotiation of the maximum number of segments a particular backend
implementation supports happens through a new "segs-per-req" xenstore
node.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
changeset: 26275:74d4a6cc5392
user: Dongxiao Xu <dongxiao.xu@intel.com>
date: Wed Dec 12 10:47:18 2012 +0100
VMX: intr.c: remove i386 related code
i386 arch is no longer supported by Xen, remove the related code.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
========================================
commit 6a0cf3786f1964fdf5a17f88f26cb499f4e89c81
Author: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu Dec 6 12:35:58 2012 +0000
qemu-stubdom: prevent useless medium change
qemu-stubdom was stripping the prefix from the "params" xenstore
key in xenstore_parse_domain_config, which was then saved stripped in
a variable. In xenstore_process_event we compare the "param" from
xenstore (not stripped) with the stripped "param" saved in the
variable, which leads to a medium change (even if there isn't any),
since we are comparing something like aio:/path/to/file with
/path/to/file. This only happens one time, since
xenstore_parse_domain_config is the only place where we strip the
prefix. The result of this bug is the following:
xs_read_watch() -> /local/domain/0/backend/qdisk/19/5632/params hdc
close(7)
close blk: backend=/local/domain/0/backend/qdisk/19/5632
node=/local/domain/19/device/vbd/5632
(XEN) HVM18: HVM Loader
(XEN) HVM18: Detected Xen v4.3-unstable
(XEN) HVM18: Xenbus rings @0xfeffc000, event channel 4
(XEN) HVM18: System requested ROMBIOS
(XEN) HVM18: CPU speed is 2400 MHz
(XEN) irq.c:270: Dom18 PCI link 0 changed 0 -> 5
(XEN) HVM18: PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:270: Dom18 PCI link 1 changed 0 -> 10
(XEN) HVM18: PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:270: Dom18 PCI link 2 changed 0 -> 11
(XEN) HVM18: PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:270: Dom18 PCI link 3 changed 0 -> 5
(XEN) HVM18: PCI-ISA link 3 routed to IRQ5
(XEN) HVM18: pci dev 01:3 INTA->IRQ10
(XEN) HVM18: pci dev 03:0 INTA->IRQ5
(XEN) HVM18: pci dev 04:0 INTA->IRQ5
(XEN) HVM18: pci dev 02:0 bar 10 size lx: 02000000
(XEN) HVM18: pci dev 03:0 bar 14 size lx: 01000000
(XEN) HVM18: pci dev 02:0 bar 14 size lx: 00001000
(XEN) HVM18: pci dev 03:0 bar 10 size lx: 00000100
(XEN) HVM18: pci dev 04:0 bar 10 size lx: 00000100
(XEN) HVM18: pci dev 04:0 bar 14 size lx: 00000100
(XEN) HVM18: pci dev 01:1 bar 20 size lx: 00000010
(XEN) HVM18: Multiprocessor initialisation:
(XEN) HVM18: - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM18: - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(XEN) HVM18: Testing HVM environment:
(XEN) HVM18: - REP INSB across page boundaries ... passed
(XEN) HVM18: - GS base MSRs and SWAPGS ... passed
(XEN) HVM18: Passed 2 of 2 tests
(XEN) HVM18: Writing SMBIOS tables ...
(XEN) HVM18: Loading ROMBIOS ...
(XEN) HVM18: 9660 bytes of ROMBIOS high-memory extensions:
(XEN) HVM18: Relocating to 0xfc001000-0xfc0035bc ... done
(XEN) HVM18: Creating MP tables ...
(XEN) HVM18: Loading Cirrus VGABIOS ...
(XEN) HVM18: Loading PCI Option ROM ...
(XEN) HVM18: - Manufacturer: http://ipxe.org
(XEN) HVM18: - Product name: iPXE
(XEN) HVM18: Option ROMs:
(XEN) HVM18: c0000-c8fff: VGA BIOS
(XEN) HVM18: c9000-d8fff: Etherboot ROM
(XEN) HVM18: Loading ACPI ...
(XEN) HVM18: vm86 TSS at fc00f680
(XEN) HVM18: BIOS map:
(XEN) HVM18: f0000-fffff: Main BIOS
(XEN) HVM18: E820 table:
(XEN) HVM18: [00]: 00000000:00000000 - 00000000:0009e000: RAM
(XEN) HVM18: [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED
(XEN) HVM18: HOLE: 00000000:000a0000 - 00000000:000e0000
(XEN) HVM18: [02]: 00000000:000e0000 - 00000000:00100000: RESERVED
(XEN) HVM18: [03]: 00000000:00100000 - 00000000:3f800000: RAM
(XEN) HVM18: HOLE: 00000000:3f800000 - 00000000:fc000000
(XEN) HVM18: [04]: 00000000:fc000000 - 00000001:00000000: RESERVED
(XEN) HVM18: Invoking ROMBIOS ...
(XEN) HVM18: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) stdvga.c:147:d18 entering stdvga and caching modes
(XEN) HVM18: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
(XEN) HVM18: Bochs BIOS - build: 06/23/99
(XEN) HVM18: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) HVM18: Options: apmbios pcibios eltorito PMM
(XEN) HVM18:
(XEN) HVM18: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) HVM18: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (10240 MBytes)
(XEN) HVM18: IDE time out
(XEN) HVM18: ata1 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-Rom
(XEN) HVM18: IDE time out
(XEN) HVM18:
(XEN) HVM18:
(XEN) HVM18:
(XEN) HVM18: Press F12 for boot menu.
(XEN) HVM18:
(XEN) HVM18: Booting from CD-Rom...
(XEN) HVM18: ata_is_ready returned 1
(XEN) HVM18: CDROM boot failure code : 0003
(XEN) HVM18: Boot from CD-Rom failed: could not read the boot disk
(XEN) HVM18:
(XEN) HVM18:
(XEN) HVM18: No bootable device.
(XEN) HVM18: Powering off in 30 seconds.
******************* BLKFRONT for /local/domain/19/device/vbd/5632 **********
backend at /local/domain/0/backend/qdisk/19/5632
Failed to read
/local/domain/0/backend/qdisk/19/5632/feature-flush-cache.
284420 sectors of 512 bytes
**************************
blk_open(/local/domain/19/device/vbd/5632) -> 7
As seen in this trace, the medium change happens just when the
guest is booting, which leads to the guest not being able to boot
because the BIOS is not able to access the device.
This is a regression from Xen 4.1, which is able to boot from "file:/"
based backends when using stubdomains.
[. By inspection, this patch does not change the flow for the
non-stubdom case. -iwj]
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>