flight 64980 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64980/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 5 libvirt-build fail REGR. vs. 63340
Tests which did not succe
flight 64965 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64965/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 64579
test-amd64-amd64-xl
flight 64969 linux-3.16 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64969/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate
fail in 64841 pass in 64969
test-armhf-
Hi Jan, Boris and Aravind,
(Sorry for sending such a long email and thanks for your patience)
Because this patchset also touches the existing SVM TSC ratio code, I
tested it on an AMD machine with an AMD A10-7700K CPU (3.4 GHz) that
supports SVM TSC ratio. There are two goals of the test:
(1) Ch
This run is configured for baseline tests only.
flight 38322 linux-3.16 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38322/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 3 capture-logs
flight 64985 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64985/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-amd 6 xen-boot fail REGR. vs. 59254
test-amd64-i386-xl-qe
flight 64988 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64988/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate
fail REGR. vs. 63379
flight 64990 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64990/
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. 64035
test-armhf-armhf-xl-
On Fri, Nov 20, 2015 at 05:21:11PM -0800, Ed Swierk wrote:
> The problem is that the index of the socket_cpumask array is derived via
> cpu_to_socket() from the APIC ID of the processor in a given socket, but
> the size of the array is computed based on nr_sockets, which is not
> necessarily equal
On 11/21/2015 12:40 AM, Alex Williamson wrote:
Thanks for confirmation. For QEMU/KVM, I totally agree your point; However,
if we take XenGT to consider, it will be a bit more complex: with Xen
hypervisor and Dom0 kernel running in different level, it's not a straight-
forward way for QEMU to do
On 11/21/2015 01:25 AM, Alex Williamson wrote:
On Fri, 2015-11-20 at 08:10 +, Tian, Kevin wrote:
Here is a more concrete example:
KVMGT doesn't require IOMMU. All DMA targets are already replaced with
HPA thru shadow GTT. So DMA requests from GPU all contain HPAs.
When IOMMU is enabled, o
On Fri, Nov 20, 2015 at 04:35:00AM -0700, Jan Beulich wrote:
> >>> On 20.11.15 at 02:18, wrote:
> > @@ -187,36 +363,56 @@ void xrstor(struct vcpu *v, uint64_t mask)
> > switch ( __builtin_expect(ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET], 8) )
> > {
> > default:
> > -asm volatile
add Feng as the new maintainer of VT-d stuff
Signed-off-by: Yang Zhang
---
MAINTAINERS |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 759de1b..eb48f77 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -193,8 +193,8 @@ F: xen/arch/x86/tboot.
On Mon, Nov 23, 2015 at 09:10:08AM +0800, Chao Peng wrote:
> On Fri, Nov 20, 2015 at 05:21:11PM -0800, Ed Swierk wrote:
> > The problem is that the index of the socket_cpumask array is derived via
> > cpu_to_socket() from the APIC ID of the processor in a given socket, but
> > the size of the array
>>> On 20.11.15 at 18:07, wrote:
> On 20.11.2015 17:54, Jan Beulich wrote:
> On 20.11.15 at 17:15, wrote:
>>> So this is a quick hack I just tried and that keeps the HVM alive:
>>>
>>> @@ -1294,7 +1288,6 @@ void vmx_inject_hw_exception(int trap, i
>>> switch ( trap )
>>> {
>>>
>>> On 23.11.15 at 08:37, wrote:
> Actually there's no problem with ICEBP - just like INTnn it isn't itself
> interceptable (and the injection of vector 0x01 from the x86
> emulator path can't fully distinguish between ICEBP and INT $1 in
> these old versions anyway). So what you have should be g
Wei and others,
It has been a long, long road to getting a rumprun-based stubdom
implemented. The earliest discussion of pursuing this approach appears to
be a post by IanJ on August 21, 2013, with the first serious indication of
development work again posted by IanJ, on April 8, 2014 - over 19 m
17 matches
Mail list logo
