> 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 Device-TL
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 via
> 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 mailing list
Xen-devel@lists.xen.org
http://lists.xen.org
> 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
> 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 +-
> xen/arch/x86/crash.c
> 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 asynchronous
> > flush issue'.
> > >Fix cur
> 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 light
> > way
> 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.
>
> 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 allow limited ATS s
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 cr
> 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 t
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 cr
> 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, rat
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
test-amd64-i386-x
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
test-am
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
test-amd64-i386-
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 guests.
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 VM_EXIT_IN
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 from
> this Mukesh patch:
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
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
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
test-am
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
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
test-am
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
test-amd64-i386-freeb
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.
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 ve
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
Reg
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
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
build-a
30 matches
Mail list logo
