flight 8274 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/8274/
Regressions :-(
Tests which did not succeed and are blocking:
test-i386-i386-pv 3 host-install(3) broken
test-amd64-i386-rhel6hvm-intel 3 host-install(3) broken
test-amd64-amd64-win 5 xen-boot fail REGR. vs. 8256
test-amd64-i386-pv 3 host-install(3) broken
test-amd64-i386-win-vcpus1 3 host-install(3) broken
test-amd64-i386-xl-win-vcpus1 3 host-install(3) broken
test-amd64-i386-win 3 host-install(3) broken
Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-i386-xl-multivcpu 5 xen-boot fail like 8256
test-amd64-amd64-xl 5 xen-boot fail like 8249
test-amd64-i386-pair 8 xen-boot/dst_host fail like 8240
test-amd64-i386-pair 7 xen-boot/src_host fail like 8240
test-amd64-i386-xl-credit2 5 xen-boot fail like 8249
test-amd64-i386-rhel6hvm-amd 5 xen-boot fail like 8236
test-amd64-i386-xl 5 xen-boot fail like 8244
test-i386-i386-win 16 leak-check/check fail never pass
test-amd64-amd64-pair 8 xen-boot/dst_host fail like 8256
test-amd64-amd64-pair 7 xen-boot/src_host fail like 8256
test-i386-i386-pair 7 xen-boot/src_host fail like 8256
test-i386-i386-pair 8 xen-boot/dst_host fail like 8256
test-amd64-amd64-xl-win 5 xen-boot fail like 8249
test-i386-i386-xl-win 13 guest-stop fail never pass
version targeted for testing:
xen e8d1c8f074ba
baseline version:
xen 42edf1481c57
------------------------------------------------------------
People who touched revisions under test:
Bei Guan <gbtju85@xxxxxxxxx>
Ian Campbell <ian.campbell@xxxxxxxxxx>
Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Jan Beulich <jbeulich@xxxxxxxxxx>
Keir Fraser <keir@xxxxxxx>
Liu, Jinsong <jinsong.liu@xxxxxxxxx>
Olaf Hering <olaf@xxxxxxxxx>
Roger Pau Monne <roger.pau@xxxxxxxxxxxxx>
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
------------------------------------------------------------
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 fail
test-amd64-i386-xl fail
test-i386-i386-xl pass
test-amd64-i386-rhel6hvm-amd fail
test-amd64-i386-xl-credit2 fail
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel broken
test-amd64-i386-xl-multivcpu fail
test-amd64-amd64-pair fail
test-amd64-i386-pair fail
test-i386-i386-pair fail
test-amd64-amd64-pv pass
test-amd64-i386-pv broken
test-i386-i386-pv broken
test-amd64-i386-win-vcpus1 broken
test-amd64-i386-xl-win-vcpus1 broken
test-amd64-amd64-win fail
test-amd64-i386-win broken
test-i386-i386-win fail
test-amd64-amd64-xl-win fail
test-i386-i386-xl-win 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: 23749:e8d1c8f074ba
tag: tip
user: Jan Beulich <jbeulich@xxxxxxxxxx>
date: Mon Jul 25 16:43:26 2011 +0100
x86-64/MMCFG: pass down firmware (ACPI) reservation status of used memory
space
Reserving the MMCFG address range(s) in E820 is specified to only be
optional for the firmware to do. The requirement is to have them
reserved in ACPI resources. Those, however, aren't directly visible to
Xen as they require the ACPI interpreter to be active. Thus, if a
range isn't reserved in E820, we should not completely disable use of
MMCFG on the respective bus range, but rather keep it disabled until
Dom0 can pass down information on the ACPI reservation status (though
a new physdevop hypercall).
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
changeset: 23748:e1717d180897
user: Jan Beulich <jbeulich@xxxxxxxxxx>
date: Mon Jul 25 16:42:53 2011 +0100
x86-64/MMCFG: finally make Fam10 enabling work
Forcibly enabling the MMCFG space on AMD Fam10 CPUs cannot be expected
to work since with the firmware not being aware of the address range
used it cannot possibly reserve the space in E820 or ACPI resources.
Hence we need to manually insert the range into the E820 table, and
enable the range only when the insertion actually works without
conflict.
Further, the actual enabling of the space is done from identify_cpu(),
which means that acpi_mmcfg_init() muts be called after that function
(and hance should not be called from acpi_boot_init()). Otherwise,
Dom0 would be able to use MMCFG, but Xen wouldn't.
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
changeset: 23747:b07b6fa76656
user: Jan Beulich <jbeulich@xxxxxxxxxx>
date: Mon Jul 25 16:42:19 2011 +0100
x86-64/MMCFG: correct base address computation for regions not starting at
bus 0
As per the specification, the base address reported by ACPI is the one
that would be used if the region started at bus 0. Hence the
start_bus_number offset needs to be added not only to the virtual
address, but also the physical one when establishing the mapping, and
it then needs to be subtracted when obtaining the virtual address for
doing accesses.
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
changeset: 23746:aa54b8175954
user: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
date: Mon Jul 25 16:41:33 2011 +0100
VT-d: always clean up dpci timers.
Message-ID: <20110718163848.GD18276@xxxxxxxxxxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
If a VM has all its PCI devices deassigned, need_iommu(d) becomes
false but it might still have DPCI EOI timers that were init_timer()d
but not yet kill_timer()d. That causes xen to crash later because the
linked list of inactive timers gets corrupted, e.g.:
(XEN) Xen call trace:
(XEN) [<ffff82c480126256>] set_timer+0x1c2/0x24f
(XEN) [<ffff82c48011fbf8>] schedule+0x129/0x5dd
(XEN) [<ffff82c480122c1e>] __do_softirq+0x7e/0x89
(XEN) [<ffff82c480122c9d>] do_softirq+0x26/0x28
(XEN) [<ffff82c480153c85>] idle_loop+0x5a/0x5c
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Assertion 'entry->next->prev == entry' failed at
/local/scratch/tdeegan/xen-unstable.hg/xen/include:172
(XEN) ****************************************
The following patch makes sure that the domain destruction path always
clears up the DPCI state even if !needs_iommu(d).
Signed-off-by: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
changeset: 23745:9dbbf1631193
user: Keir Fraser <keir@xxxxxxx>
date: Mon Jul 25 14:21:13 2011 +0100
hvmloader: Allow default response to be specified to xenstore_read().
Signed-off-by: Keir Fraser <keir@xxxxxxx>
changeset: 23744:3244ff483d61
user: Keir Fraser <keir@xxxxxxx>
date: Mon Jul 25 14:09:41 2011 +0100
hvmloader: Formatting cleanups.
Signed-off-by: Keir Fraser <keir@xxxxxxx>
changeset: 23743:360b31a5263c
user: Keir Fraser <keir@xxxxxxx>
date: Mon Jul 25 13:57:49 2011 +0100
hvmloader: Replace bios_relocate hook with bios_load hook
Used by OVMF BIOS handler.
Signed-off-by: Bei Guan <gbtju85@xxxxxxxxx>
Signed-off-by: Keir Fraser <keir@xxxxxxx>
changeset: 23742:50ddc200a60c
user: Jan Beulich <jbeulich@xxxxxxxxxx>
date: Mon Jul 25 13:48:08 2011 +0100
fix regression from c/s 23735:537918f518ee
This was checking presence of the wrong (old) ELF note. I don't really
understand how this failed consistently only for one of the xen-boot
tests...
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
changeset: 23741:d8725d9fb865
user: Keir Fraser <keir@xxxxxxx>
date: Sat Jul 23 09:57:04 2011 +0100
hvmloader: Declare get_hvm_info_table/get_shared_info as const funcs.
The compiler can perform CSE on their call sites.
Signed-off-by: Keir Fraser <keir@xxxxxxx>
changeset: 23740:5f7dc61e166b
user: Keir Fraser <keir@xxxxxxx>
date: Sat Jul 23 09:56:13 2011 +0100
hvmloader: Remove bogus and unused RESERVED_MEMSIZE decl.
Signed-off-by: Keir Fraser <keir@xxxxxxx>
changeset: 23739:815ef5cf0261
user: Keir Fraser <keir@xxxxxxx>
date: Sat Jul 23 09:43:47 2011 +0100
hvmloader: New functions mem_hole_alloc() and mem_hole_populate_ram().
These can be used by BIOS-specific handlers to set up memory regions
as required by their firmware payload.
Use mem_hole_alloc() to allocate properly reserved space for the
shared-info-page mapping. The old location conflicts with space
required for the OVMF BIOS (support for which is work in progress).
Signed-off-by: Keir Fraser <keir@xxxxxxx>
changeset: 23738:88847c424eec
user: Roger Pau Monne <roger.pau@xxxxxxxxxxxxx>
date: Sat Jul 23 08:58:37 2011 +0100
xend: remove PCI device listing from NetBSD, since it's Linux
specific code.
Signed-off-by: Roger Pau Monne <roger.pau@xxxxxxxxxxxxx>
changeset: 23737:3d18ff6589e3
user: Liu, Jinsong <jinsong.liu@xxxxxxxxx>
date: Sat Jul 23 08:56:58 2011 +0100
x86, mce: Dump mce log by ERST when mc panic
We have implemented basic ERST logic before. Now linux3.0 as dom0 has
included APEI logic. Hence it's time to add mce apei interface and
enable APEI ERST feature.
With it, it can save mce log by ERST method when mc panic.
Signed-off-by: Liu, Jinsong <jinsong.liu@xxxxxxxxx>
changeset: 23736:31683aa4bfb3
user: Liu, Jinsong <jinsong.liu@xxxxxxxxx>
date: Sat Jul 23 08:55:59 2011 +0100
acpi: Add support for old and new bios erst, enable mce_apei logic
When testing, we found different bios has different understanding
about APEI ERST table header, depending on whether it count ACPI
standard header or not.
This patch add support for both bios version, and enable mce_apei.
Signed-off-by: Liu, Jinsong <jinsong.liu@xxxxxxxxx>
changeset: 23735:537918f518ee
user: Jan Beulich <jbeulich@xxxxxxxxxx>
date: Sat Jul 23 08:49:15 2011 +0100
add privileged (dom0) kernel feature indication
With our switching away from supporting 32-bit Dom0 operation, users
complained that attempts (perhaps due to lack of knowledge of that
change) to boot the no longer privileged kernel in Dom0 resulted in
apparently silent failure. To make the mismatch explicit and visible,
add dom0 feature flag that the kernel can set to indicate operation as
dom0 is supported.
Due to the way elf_xen_parse_features() worked up to now (getting
fixed here), adding features indications to the old, string based ELF
note would make the respective kernel unusable on older hypervisors.
For that reason, a new ELF Note is being introduced that allows
specifying supported features as a bit array instead (with features
unknown to the hypervisor simply ignored, as now also done by
elf_xen_parse_features(), whereas here unknown kernel-required
features still keep the kernel [and hence VM] from booting).
Introduce and use elf_note_numeric_array() to be forward
compatible (or else an old hypervisor wouldn't be able to parse kernel
specified features occupying more than 64 bits - thanks, Ian!).
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
changeset: 23734:42edf1481c57
user: Ian Campbell <ian.campbell@xxxxxxxxxx>
date: Fri Jul 22 08:55:19 2011 +0100
build: remove $(DESTDIR) from buildmakevars2file paths
23721:0ccb94d533d6 added this by mistake.
Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
========================================
commit cd776ee9408ff127f934a707c1a339ee600bc127
Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date: Tue Jun 28 13:50:53 2011 +0100
qemu-char.c: fix incorrect CONFIG_STUBDOM handling
qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef]
Signed-off-by: Olaf Hering <olaf@xxxxxxxxx>
Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home