flight 58255 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58255/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 8 leak-check/basis(8) fail REGR. vs. 56376
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-libvirt 11 guest-start fail like 56376
test-armhf-armhf-libvirt 11 guest-start fail like 56376
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass
test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass
test-amd64-i386-libvirt 12 migrate-support-check 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-armhf-armhf-xl-sedf-pin 12 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 12 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl-sedf 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass
version targeted for testing:
qemuu e15907a474fe03ca13fca067b7046b77122484cb
baseline version:
qemuu b2da824bc5ad35fb9f1e74a203d7be96a7b0345e
------------------------------------------------------------
People who touched revisions under test:
Ian Campbell <ian.campb...@citrix.com>
Jan Beulich <jbeul...@suse.com>
Stefano Stabellini <stefano.stabell...@eu.citrix.com>
------------------------------------------------------------
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-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl broken
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm pass
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-xl-pvh-amd fail
test-amd64-i386-qemuu-rhel6hvm-amd 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-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 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt fail
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt 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-xl-sedf-pin pass
test-armhf-armhf-xl-sedf-pin pass
test-amd64-amd64-xl-sedf pass
test-armhf-armhf-xl-sedf pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 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
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
commit e15907a474fe03ca13fca067b7046b77122484cb
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Jun 2 15:43:08 2015 +0000
xen/pt: unknown PCI config space fields should be read-only
... by default. Add a per-device "permissive" mode similar to pciback's
to allow restoring previous behavior (and hence break security again,
i.e. should be used only for trusted guests).
This is part of XSA-131.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Acked-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
Reviewed-by: Anthony PERARD <anthony.per...@citrix.com>)
commit 2caff9b5dfbfb7abdf420a52f177efc42675147d
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Jun 2 15:43:08 2015 +0000
xen/pt: add a few PCI config space field descriptions
Since the next patch will turn all not explicitly described fields
read-only by default, those fields that have guest writable bits need
to be given explicit descriptors.
This is a preparatory patch for XSA-131.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
commit 0b5d10627ab7f5b67cb784459fc004c0745c4746
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Jun 2 15:43:08 2015 +0000
xen/pt: mark reserved bits in PCI config space fields
The adjustments are solely to make the subsequent patches work right
(and hence make the patch set consistent), namely if permissive mode
(introduced by the last patch) gets used (as both reserved registers
and reserved fields must be similarly protected from guest access in
default mode, but the guest should be allowed access to them in
permissive mode).
This is a preparatory patch for XSA-131.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
commit 16c1631e63a22e80dfc0d288a2115dad4a848370
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Jun 2 15:43:08 2015 +0000
xen/pt: mark all PCIe capability bits read-only
xen_pt_emu_reg_pcie[]'s PCI_EXP_DEVCAP needs to cover all bits as read-
only to avoid unintended write-back (just a precaution, the field ought
to be read-only in hardware).
This is a preparatory patch for XSA-131.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
commit cb1e0cea8e5fdd1f8677c1733eec6175600ea69e
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Jun 2 15:43:08 2015 +0000
xen/pt: split out calculation of throughable mask in PCI config space
handling
This is just to avoid having to adjust that calculation later in
multiple places.
Note that including ->ro_mask in get_throughable_mask()'s calculation
is only an apparent (i.e. benign) behavioral change: For r/o fields it
doesn't matter > whether they get passed through - either the same flag
is also set in emu_mask (then there's no change at all) or the field is
r/o in hardware (and hence a write won't change it anyway).
This is a preparatory patch for XSA-131.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Acked-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
Reviewed-by: Anthony PERARD <anthony.per...@citrix.com>
commit 60abfa7e7750945c4d222e8089fe6d06479d3367
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Jun 2 15:43:08 2015 +0000
xen/pt: correctly handle PM status bit
xen_pt_pmcsr_reg_write() needs an adjustment to deal with the RW1C
nature of the not passed through bit 15 (PCI_PM_CTRL_PME_STATUS).
This is a preparatory patch for XSA-131.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
commit 369baec3d19ca051cc4abeaa9d9e6bf5ec5d9925
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Jun 2 15:43:07 2015 +0000
xen/pt: consolidate PM capability emu_mask
There's no point in xen_pt_pmcsr_reg_{read,write}() each ORing
PCI_PM_CTRL_STATE_MASK and PCI_PM_CTRL_NO_SOFT_RESET into a local
emu_mask variable - we can have the same effect by setting the field
descriptor's emu_mask member suitably right away. Note that
xen_pt_pmcsr_reg_write() is being retained in order to allow later
patches to be less intrusive.
This is a preparatory patch for XSA-131.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Acked-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
Acked-by: Ian Campbell <ian.campb...@citrix.com>
commit 0090c14f57c3ffe07df4dd8d57f5a9481591c9ee
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Jun 2 15:43:07 2015 +0000
xen/MSI: don't open-code pass-through of enable bit modifications
Without this the actual XSA-131 fix would cause the enable bit to not
get set anymore (due to the write back getting suppressed there based
on the OR of emu_mask, ro_mask, and res_mask).
Note that the fiddling with the enable bit shouldn't really be done by
qemu, but making this work right (via libxc and the hypervisor) will
require more extensive changes, which can be postponed until after the
security issue got addressed.
This is a preparatory patch for XSA-131.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Acked-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
commit 1f26a9bbce40a5f9651e1062a8ab9975e68d9f03
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Jun 2 15:43:07 2015 +0000
xen/MSI-X: limit error messages
Limit error messages resulting from bad guest behavior to avoid allowing
the guest to cause the control domain's disk to fill.
The first message in pci_msix_write() can simply be deleted, as this
is indeed bad guest behavior, but such out of bounds writes don't
really need to be logged.
The second one is more problematic, as there guest behavior may only
appear to be wrong: For one, the old logic didn't take the mask-all bit
into account. And then this shouldn't depend on host device state (i.e.
the host may have masked the entry without the guest having done so).
Plus these writes shouldn't be dropped even when an entry is unmasked.
Instead, if they can't be made take effect right away, they should take
effect on the next unmasking or enabling operation - the specification
explicitly describes such caching behavior. Until we can validly drop
the message (implementing such caching/latching behavior), issue the
message just once per MSI-X table entry.
Note that the log message in pci_msix_read() similar to the one being
removed here is not an issue: "addr" being of unsigned type, and the
maximum size of the MSI-X table being 32k, entry_nr simply can't be
negative and hence the conditonal guarding issuing of the message will
never be true.
This is XSA-130.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
commit 5ee7a3e24aaa032f88e91e01b44aadcdaa4c5609
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Jun 2 15:43:07 2015 +0000
xen: don't allow guest to control MSI mask register
It's being used by the hypervisor. For now simply mimic a device not
capable of masking, and fully emulate any accesses a guest may issue
nevertheless as simple reads/writes without side effects.
This is XSA-129.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
commit 98fc2a309a039b6e3c6ed6ac0f1c33548448d3da
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Jun 2 15:43:07 2015 +0000
xen: properly gate host writes of modified PCI CFG contents
The old logic didn't work as intended when an access spanned multiple
fields (for example a 32-bit access to the location of the MSI Message
Data field with the high 16 bits not being covered by any known field).
Remove it and derive which fields not to write to from the accessed
fields' emulation masks: When they're all ones, there's no point in
doing any host write.
This fixes a secondary issue at once: We obviously shouldn't make any
host write attempt when already the host read failed.
This is XSA-128.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
