Re: [Xen-devel] [PATCH] x86/vmx: Fix injection of #DB traps following XSA-165

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Friday, December 25, 2015 2:23 AM > > Most debug exceptions are traps rather than faults. Blindly re-injecting them > as hardware exception causes the instruction pointer in the exception frame > to point at the target instruct,

Re: [Xen-devel] question about migration

On 12/24/2015 08:36 PM, Andrew Cooper wrote: > On 24/12/15 02:29, Wen Congyang wrote: >> Hi Andrew Cooper: >> >> I rebase the COLO codes to the newest upstream xen, and test it. I found >> a problem in the test, and I can reproduce this problem via the migration. >> >> How to reproduce: >> 1. xl

Re: [Xen-devel] [PATCH v4 0/3] VT-d Device-TLB flush issue

> On 25.12.2015 at 9:54am, wrote: > > From: Xu, Quan > > Sent: Wednesday, December 23, 2015 4:26 PM > > > > 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

Re: [Xen-devel] question about migration

On 12/25/2015 09:45 AM, Wen Congyang wrote: > On 12/24/2015 08:36 PM, Andrew Cooper wrote: >> On 24/12/15 02:29, Wen Congyang wrote: >>> Hi Andrew Cooper: >>> >>> I rebase the COLO codes to the newest upstream xen, and test it. I found >>> a problem in the test, and I can reproduce this problem

Re: [Xen-devel] [PATCH v4 3/3] VT-d: Fix vt-d Device-TLB flush timeout issue.

> From: Xu, Quan > Sent: Wednesday, December 23, 2015 4:26 PM > > Now if IOTLB/Context/IETC flush is timeout, panic hypervisor. > The coming patch set will fix it. again, please adjust comment to reflect what this patch is doing, i.e. only about improvement on Device-TLB flush. > > If

Re: [Xen-devel] [PATCH v4 0/3] VT-d Device-TLB flush issue

> From: Xu, Quan > Sent: Wednesday, December 23, 2015 4:26 PM > > 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: > > 1. Check VT-d Device-TLB flush error. >

Re: [Xen-devel] question about migration

On 12/24/2015 08:36 PM, Andrew Cooper wrote: > On 24/12/15 02:29, Wen Congyang wrote: >> Hi Andrew Cooper: >> >> I rebase the COLO codes to the newest upstream xen, and test it. I found >> a problem in the test, and I can reproduce this problem via the migration. >> >> How to reproduce: >> 1. xl

Re: [Xen-devel] [PATCH v2 2/2] x86/VPMU: Don't allow any non-zero writes to MSR_IA32_PEBS_ENABLE

> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: Thursday, December 24, 2015 12:52 AM > > Calculation reserved bits for MSR_IA32_PEBS_ENABLE is model-dependent > and since we don't support PEBS anyway we shouldn't allow any writes to > it (but let's still permit guests wishing

Re: [Xen-devel] [PATCH v4 0/3] VT-d Device-TLB flush issue

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Wednesday, December 23, 2015 6:39 PM > > >>> Quan Xu 12/23/15 9:26 AM >>> > >This patches are based on Kevin Tian's previous discussion 'Revisit VT-d > >asynchronous > flush issue'. > >Fix current timeout concern and also

Re: [Xen-devel] [PATCH v4 1/3] VT-d: Check VT-d Device-TLB flush error.

> From: Xu, Quan > Sent: Wednesday, December 23, 2015 4:26 PM > > This patch checks all kinds of error and all the way up > the call trees of VT-d Device-TLB flush. > > Signed-off-by: Quan Xu > --- > xen/arch/x86/acpi/power.c | 8 +- >

Re: [Xen-devel] [PATCH v4 2/3] VT-d: Reduce spin timeout to 1ms, which can be boot-time changed.

> From: Xu, Quan > Sent: Wednesday, December 23, 2015 4:26 PM > > Signed-off-by: Quan Xu Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 0/3] VT-d Device-TLB flush issue

> On 25.12.2015 at 9:51am, wrote: > > From: Jan Beulich [mailto:jbeul...@suse.com] > > Sent: Wednesday, December 23, 2015 6:39 PM > > > > >>> Quan Xu 12/23/15 9:26 AM >>> > > >This patches are based on Kevin Tian's previous discussion 'Revisit > > >VT-d

Re: [Xen-devel] [PATCH v4 2/3] VT-d: Reduce spin timeout to 1ms, which can be boot-time changed.

> On 25.12.2015 at 10:57am, wrote: > > From: Xu, Quan > > Sent: Wednesday, December 23, 2015 4:26 PM > > > > Signed-off-by: Quan Xu > > Acked-by: Kevin Tian Thanks Kevin! -Quan ___ Xen-devel

[Xen-devel] [qemu-upstream-4.6-testing test] 67093: regressions - FAIL

flight 67093 qemu-upstream-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/67093/ 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. 63071

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

flight 67098 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/67098/ 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. 65639

[Xen-devel] AMD #DB interception (was [PATCH] x86/vmx: Fix injection of #DB traps following XSA-165)

On 24/12/2015 18:23, Andrew Cooper wrote: Most debug exceptions are traps rather than faults. Blindly re-injecting them as hardware exception causes the instruction pointer in the exception frame to point at the target instruct, rather than after it. This in turn breaks debuggers in the

[Xen-devel] [ovmf test] 67097: regressions - FAIL

flight 67097 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/67097/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 65543

[Xen-devel] [PATCH] x86/vmx: Fix injection of #DB traps following XSA-165

Most debug exceptions are traps rather than faults. Blindly re-injecting them as hardware exception causes the instruction pointer in the exception frame to point at the target instruct, rather than after it. This in turn breaks debuggers in the guests. Introduce a helper which copies

[Xen-devel] [qemu-upstream-4.3-testing test] 67075: regressions - FAIL

flight 67075 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/67075/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3865 xen-build fail REGR. vs. 62112

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

flight 67091 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/67091/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3865 xen-build fail REGR. vs. 66433 build-amd64-xsm

[Xen-devel] [xen-4.3-testing test] 67081: regressions - FAIL

flight 67081 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/67081/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 5 xen-build fail REGR. vs. 65650 build-i386-prev

Re: [Xen-devel] how to enable kdb for xen

On 12/18/15 10:58 PM, Elena Ufimtseva wrote: > On Fri, Dec 18, 2015 at 11:24 PM, quizyjones wrote: >> Is there any progress? > > Hey > > I did look into this and I could not find the trace of what I have > done before. So I decided to ytu and port it to current version

[Xen-devel] [distros-debian-wheezy test] 38557: all pass

flight 38557 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38557/ Perfect :-) All tests in this flight passed baseline version: flight 38529 jobs: build-amd64 pass build-armhf

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

flight 67053 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/67053/ 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 9 debian-hvm-install fail REGR. vs. 66879

Re: [Xen-devel] question about migration

On 24/12/15 02:29, Wen Congyang wrote: Hi Andrew Cooper: I rebase the COLO codes to the newest upstream xen, and test it. I found a problem in the test, and I can reproduce this problem via the migration. How to reproduce: 1. xl cr -p hvm_nopv 2. xl migrate hvm_nopv 192.168.3.1 You are the

[Xen-devel] what's the type of nested xen? HVM or PV?

Happy Holiday, guys. God tell me that I should work this out before celebrate ; )I create a HVM first, then compile Xen on it. The dom0 of this Xen is a PV. So is this nested xen a HVM or a PV? It's hard to differentiate when concerning to enable events as only HVM supports events.

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

flight 67064 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/67064/ 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

[Xen-devel] [qemu-upstream-4.4-testing test] 67074: regressions - FAIL

flight 67074 qemu-upstream-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/67074/ 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

[Xen-devel] [linux-next test] 67073: regressions - FAIL

flight 67073 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/67073/ 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. 66896 build-amd64-pvops

[Xen-devel] [qemu-upstream-4.5-testing test] 67079: regressions - trouble: blocked/broken/fail/pass

flight 67079 qemu-upstream-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/67079/ 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. 62414