flight 66515 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66515/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 5 kernel-build fail REGR. vs. 66414
build-amd64-pvops
flight 66538 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66538/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 62112
build-i
flight 66542 qemu-upstream-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66542/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 62044
build-a
flight 66526 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66526/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-winxpsp3 6 xen-boot fail REGR. vs. 59254
test-amd64-i386-freeb
flight 66540 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66540/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 66433
build-amd64
>On 12.12.2015 at 9:22pm, wrote:
> This patches are based on Kevin Tian's previous discussion 'Revisit VT-d
> asynchronous flush issue'.
> Fix current timeout concern and also allow limited ATS support in a light way:
> 2. Fix vt-d flush timeout issue.
>
> If IOTLB/Context/IETC flush is tim
flight 38541 distros-debian-stretch real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38541/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-amd64-stretch-netboot-pvgrub 9 debian-di-install fail like
38505
test-amd64-
flight 66533 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66533/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-libvirt-vhd 9 debian-di-installfail like 65306
Tests which did not
flight 66534 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66534/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 3 host-install(3) broken REGR. vs. 62414
test-am
flight 66535 qemu-upstream-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66535/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 5 xen-install fail REGR. vs. 63071
test-am
The various VM_WARN_ON/VM_BUG_ON macros depend on those defined by
. Most users already include those, but not all; for
example:
CC arch/arm64/xen/../../arm/xen/grant-table.o
In file included from arch/arm64/include/../../arm/include/asm/xen/page.h:5:0,
from arch/arm64/inc
All,
Now I'll start off by saying that "no" is a perfectly acceptable answer
to this suggestion. Basically I remember at the Xen Developer Summit a
few people mentioned it being nice if people provided a git tree where
their branches were available for testing. I was just thinking it might
be easi
flight 66536 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66536/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 65650
build-amd64-prev
flight 66539 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66539/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 62702
test-am
flight 66537 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66537/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65639
test-amd64-i386-x
This run is configured for baseline tests only.
flight 38543 qemu-upstream-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38543/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-pygrub 18 guest-start/deb
flight 66553 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66553/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 66426
test-amd64-amd64-
flight 66578 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66578/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 5 kernel-build fail REGR. vs. 60684
build-amd6
flight 66559 linux-3.16 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66559/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 10 guest-start fail REGR. vs. 64969
Tests which are failin
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, December 18, 2015 6:15 PM
>
> >>> On 17.12.15 at 21:22, wrote:
> > This is provided explicitly in SVM and implicitly in VMX (when neither of
> > the three EPT_EFFECTIVE_* bits is set).
> >
> > Signed-off-by: Boris Ostrovsky
>
> Revi
> From: David Vrabel [mailto:david.vra...@citrix.com]
> Sent: Friday, December 18, 2015 9:51 PM
>
> If a guest allocates a page and the tlbflush_timestamp on the page
> indicates that a TLB flush of the previous owner is required, only the
> linear and combined mappings are invalidated. The guest
> From: David Vrabel [mailto:david.vra...@citrix.com]
> Sent: Friday, December 18, 2015 9:51 PM
>
> Holding the p2m lock while calling ept_sync_domain() is very expensive
> since it does a on_selected_cpus() call. IPIs on many socket machines
> can be very slows and on_selected_cpus() is serializ
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, December 18, 2015 3:50 PM
>
> ... since we don't need its virtual address anywhere (it's a
> placeholder page only after all). For this to work (and possibly be
> done elsewhere too) share_xen_page_with_guest() needs to mark pages
> ha
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: Saturday, December 19, 2015 3:40 AM
>
> This is provided explicitly in SVM and implicitly in VMX (when neither of
> the three EPT_EFFECTIVE_* bits is set).
>
> Signed-off-by: Boris Ostrovsky
> Reviewed-by: Jan Beulich
> Cc: kev
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Saturday, December 19, 2015 12:52 AM
>
> For one, loading the MSR with a possibly non-canonical address was
> possible since the verification is conditional, while the MSR load
> wasn't. And then for PV guests we need to further limit the rang
> From: Shuai Ruan [mailto:shuai.r...@linux.intel.com]
> Sent: Tuesday, December 15, 2015 10:05 AM
>
> From: Yu Zhang
>
> This patch uses HVMOP_IO_RANGE_XXX values rather than the raw ioreq
> type to select the ioreq server, therefore the identical relationship
> between ioreq type and rangeset
> From: Shuai Ruan [mailto:shuai.r...@linux.intel.com]
> Sent: Tuesday, December 15, 2015 10:05 AM
>
> From: Yu Zhang
>
> Currently in ioreq server, guest write-protected ram pages are
> tracked in the same rangeset with device mmio resources. Yet
> unlike device mmio, which can be in big chunks
27 matches
Mail list logo
