Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

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

Re: [Xen-devel] Rumprun based upstream QEMU stubdom status update

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

Re: [Xen-devel] Fwd: Xen-4.1.6.1 backport for XSA156

>>> 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

Re: [Xen-devel] [Qemu-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

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

Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

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,

[Xen-devel] [PATCH] MAINTAINERS: change the vt-d maintainer

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

Re: [Xen-devel] [V11 1/3] x86/xsaves: enable xsaves/xrstors/xsavec in xen

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) ) > > { > >

Re: [Xen-devel] Fwd: Xen-4.1.6.1 backport for XSA156

>>> 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

[Xen-devel] [linux-linus test] 64985: regressions - FAIL

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

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

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

[Xen-devel] [xen-unstable test] 64990: regressions - FAIL

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

[Xen-devel] [xen-4.6-testing test] 64988: regressions - FAIL

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

[Xen-devel] [linux-3.16 test] 64969: tolerable FAIL - PUSHED

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

[Xen-devel] [libvirt test] 64980: regressions - FAIL

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

[Xen-devel] [qemu-mainline test] 64965: regressions - FAIL

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

Re: [Xen-devel] [PATCH 00/13] Add VMX TSC scaling support

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)