On December 20, 2016 4:32 PM, Jan Beulich wrote:
>>>> On 20.12.16 at 06:54, wrote:
>> On December 20, 2016 1:37 PM, Tian, Kevin wrote:
>>>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>>>> Sent: Friday, December 16, 2016 5:40 PM
>>>>
On December 20, 2016 4:54 PM, Tian, Kevin wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, December 20, 2016 4:35 PM
>>
>> >>> On 20.12.16 at 06:37, wrote:
>> >> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
On December 20, 2016 1:37 PM, Tian, Kevin wrote:
>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>> Sent: Friday, December 16, 2016 5:40 PM
>I suppose you've verified this new version, but still would like get your
>explicit confirmation - did you still see time accu
On December 21, 2016 10:30 AM, Tian, Kevin wrote:
>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>> Sent: Tuesday, December 20, 2016 9:12 PM
>>
>> On December 20, 2016 1:37 PM, Tian, Kevin wrote:
>> >> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
&
r interrupt.
So we set eoi_exit_bitmap for intack.vector when it's higher than
pending periodic time interrupts. This way we can guarantee there's
always a chance to post periodic time interrupts when periodic time
interrupts becomes the highest one.
Signed-off-by: Quan Xu
---
xe
>}
>struct task_struct *thread;
>static int __init ipi_init(void)
>{
>thread = kthread_run(ipi_generator, NULL, "IPI");
>if (IS_ERR(thread))
>return PTR_ERR(thread);
>return 0;
>}
>
>static void __exit ipi_exit(void)
>{
>
On December 22, 2016 4:12 PM, Jan Beulich wrote:
On 21.12.16 at 06:44, wrote:
>> --- a/xen/arch/x86/hvm/vmx/intr.c
>> +++ b/xen/arch/x86/hvm/vmx/intr.c
>> @@ -315,9 +315,13 @@ void vmx_intr_assist(void)
>> * Set eoi_exit_bitmap for periodic timer interrup to cause
>EOI-induced VM
>>
>-Original Message-
>From: Jan Beulich [mailto:jbeul...@suse.com]
>Sent: Tuesday, January 03, 2017 3:35 PM
>To: Xuquan (Quan Xu)
>Cc: Andrew Cooper; George Dunlap; yang.zhang...@gmail.com; Chao Gao;
>Jun Nakajima; Kevin Tian; Lan Tianyu; xen-devel@lists.xen.org
>S
On January 03, 2017 4:23 PM, Jan Beulich wrote:
>>>> On 03.01.17 at 09:15, wrote:
>
>>
>>>-Original Message-
>>>From: Jan Beulich [mailto:jbeul...@suse.com]
>>>Sent: Tuesday, January 03, 2017 3:35 PM
>>>To: Xuquan (Quan Xu)
>
>From 9c23e1ff3eb75d71d691778a2e83421f645902fb Mon Sep 17 00:00:00 2001
From: Quan Xu
Date: Wed, 4 Jan 2017 20:03:31 +0800
Subject: [PATCH v5] x86/apicv: fix RTC periodic timer and apicv issue
When Xen apicv is enabled, wall clock time is faster on Windows7-32
guest with high payload (with 2v
On January 05, 2017 10:38 AM, Tian, Kevin wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, January 04, 2017 8:57 PM
>>
>> >>> On 04.01.17 at 13:21, wrote:
>> > --- a/xen/arch/x86/hvm/vmx/intr.c
>> > +++ b/xen/arch/x86/hvm/vmx/intr.c
>> > @@ -334,7 +335,8 @@ void vmx_intr_
>From 7c0091cdce951f707bd8dff906aabdf5d645a85f Mon Sep 17 00:00:00 2001
From: Quan Xu
Date: Thu, 5 Jan 2017 10:38:39 +0800
Subject: [PATCH v6] x86/apicv: fix RTC periodic timer and apicv issue
When Xen apicv is enabled, wall clock time is faster on Windows7-32
guest with high payload (with 2v
On January 12, 2017 5:14 PM, Andrew Cooper wrote:
>On 12/01/2017 06:46, osstest service owner wrote:
>> flight 104131 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/104131/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking, including tests which
On September 26, 2016 2:39 PM, Jan Beulich < jbeul...@suse.com > wrote:
On 24.09.16 at 03:06, wrote:
>> On September 24, 2016 7:34 AM, Tian Kevin < kevin.t...@intel.com > wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Friday, September 23, 2016 11:34 PM
>>> On 2
On October 10, 2016 5:40 PM, Jan Beulich < jbeul...@suse.com > wrote:
>> >>> On 20.09.16 at 15:30, wrote:
>> > --- a/xen/arch/x86/hvm/vlapic.c
>> > +++ b/xen/arch/x86/hvm/vlapic.c
>> > @@ -433,6 +433,12 @@ void vlapic_EOI_set(struct vlapic *vlapic)
>> > void vlapic_handle_EOI(s
On October 11, 2016 3:49 PM, Tian, Kevin
>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>> Sent: Monday, October 10, 2016 6:49 PM
>>
>> On October 10, 2016 5:40 PM, Jan Beulich < jbeul...@suse.com > wrote:
>> >>>>>> >>> O
>> Signed-off-by: Emil Condrea
>
>Acked-by: Anthony PERARD
>
Reviewed-by: Quan Xu
Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
ed-off-by: Emil Condrea
>
>Acked-by: Anthony PERARD
>
Reviewed-by: Quan Xu
Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
igned-off-by: Emil Condrea
>
>Acked-by: Anthony PERARD
>
Reviewed-by: Quan Xu
Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
ed-off-by: Emil Condrea
>
>Acked-by: Anthony PERARD
>
Reviewed-by: Quan Xu
Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
ed-off-by: Emil Condrea
>
>Acked-by: Anthony PERARD
>
Reviewed-by: Quan Xu
Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On October 13, 2016 2:09 PM, Emil Condrea wrote:
>As you suggested, I've dropped the all patches for xen_frontend.
>
>Emil
>
>On Wed, Oct 12, 2016 at 2:00 PM, Paolo Bonzini wrote:
>>
>>
>> On 09/10/2016 21:50, Emil Condrea wrote:
>>> On Tue, Oct 4, 2016 at 11:06 AM, Paolo Bonzini
>wrote:
>>
On October 11, 2016 7:11 PM, Xuquan < xuqu...@huawei.com > wrote:
>On October 11, 2016 3:49 PM, Tian, Kevin
>>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>>> Sent: Monday, October 10, 2016 6:49 PM
>>>
>>> On October 10, 2016 5:4
On October 24, 2016 3:02 PM, Tian, Kevin wrote:
>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>> Sent: Monday, October 17, 2016 5:28 PM
>>
>> >>
>> >>Back to the main open before holiday - multiple EOIs may come to
>> >>clear
On October 25, 2016 4:36 PM, Quan Xu wrote:
>I am afraid we could find a clean solution based on current implementation (kvm
Sorry, a typo..
s/could/could not/
>is ok).. and apicv results in decreased application performance for some
>windows
>guest.
>
>So I su
On October 13, 2016 2:02 PM, Emil Condrea wrote:
>This patch series was splitted from QEMU:Xen stubdom vTPM for HVM virtual
>machine http://markmail.org/message/fkix7g3a5zdj7lvr
>
>It contains a reorganization of xen backend and frontend functions together
>with
>code style fixes.
>Common functio
On October 26, 2016 1:20 PM, Tian, Kevin wrote:
>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>> Sent: Tuesday, October 25, 2016 4:36 PM
>>
>> On October 24, 2016 3:02 PM, Tian, Kevin wrote:
>> >> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>&
On October 25, 2016 9:01 PM, Konrad Rzeszutek Wilk < konrad.w...@oracle.com >
wrote:
>>
>
>Could you describe what the KVM implementation solution did that made it clean?
>I am curious whether the concept could be put in Xen?
Konrad, I am still learning this part. I will update it later.
Quan
__
On October 26, 2016 5:35 PM, Tian, Kevin wrote:
>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>> Sent: Wednesday, October 26, 2016 4:39 PM
>>
>> On October 26, 2016 1:20 PM, Tian, Kevin wrote:
>> >> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>
Hi Andrew,
When I run some application with Xen, I encounter a Panic with log as the
bottom of this email.
I find this panic is as similar as your fix e4e9d2d4e76bd8fe22 'x86/p2m-ept:
don't unmap the EPT pagetable while it is still in use'.
_iiuc_, in __do_update_va_mapping(),
'va' is unmappe
On November 01, 2016 7:16 PM, Andrew Cooper < andrew.coop...@citrix.com > wrote:
>On 01/11/16 11:01, Xuquan (Quan Xu) wrote:
>> Hi Andrew,
>>
>> When I run some application with Xen, I encounter a Panic with log as the
>bottom of this email.
>> I find
On November 01, 2016 7:41 PM, Andrew Cooper wrote:
>On 01/11/16 11:23, Xuquan (Quan Xu) wrote:
>> On November 01, 2016 7:16 PM, Andrew Cooper <
>andrew.coop...@citrix.com > wrote:
>>> On 01/11/16 11:01, Xuquan (Quan Xu) wrote:
>>>> Hi Andrew,
>>&g
On November 01, 2016 8:00 PM, Andrew Cooper wrote:
>On 01/11/16 11:57, Xuquan (Quan Xu) wrote:
>> On November 01, 2016 7:41 PM, Andrew Cooper
> wrote:
>>> On 01/11/16 11:23, Xuquan (Quan Xu) wrote:
>>>> On November 01, 2016 7:16 PM, Andrew Cooper <
>>>
On November 01, 2016 9:21 PM, Andrew Cooper wrote:
>On 01/11/16 12:07, Xuquan (Quan Xu) wrote:
>> On November 01, 2016 8:00 PM, Andrew Cooper wrote:
>>> On 01/11/16 11:57, Xuquan (Quan Xu) wrote:
>>>> On November 01, 2016 7:41 PM, Andrew Cooper
>>> wrote
On November 03, 2016 9:18 PM, < jbeul...@suse.com > wrote:
On 03.11.16 at 13:14, wrote:
>> Jan,
>> A backport ' c/s 22135 ' was mentioned in above link. Does it refer
>> to
>https://build.opensuse.org/package/view_file?file=22135-heap-lock.patch&pack
>age=
>> xen&project=home%3Acharlesa%3Aop
On Feb 4, 2013, 6:25 AM, wrote:
> While the triple fault action on native hardware will result in a system
> reset, any modern operating system can and will make use of less violent
> reboot methods. As a result, the most likely cause of a triple fault is a
> fatal software bug.
>
> This patch all
On November 07, 2016 9:13 PM, Andrew Cooper wrote:
>On 07/11/16 12:56, Xuquan (Quan Xu) wrote:
>> 4) any ideas to reproduce triple fault?
>
>What do you mean by reproduce? Causing a triple fault is very easy from the
>guest kernel.
Yes, by reproduce.. indeed, we just implement
On March 01, 2017 2:24 PM, wrote:
>On Wed, Mar 01, 2017 at 12:38:39AM -0700, Jan Beulich wrote:
> On 01.03.17 at 04:23, wrote:
>>> On February 28, 2017 11:08 PM, Jan Beulich wrote:
>>> On 27.02.17 at 11:53, wrote:
> If guest is already in non-root mode, an posted interrupt will be
>>>
since the
>IPI is consumed by hardware rather than raise a softirq unconditionally.
>
>Signed-off-by: Quan Xu
>Signed-off-by: Chao Gao
>Acked-by: Kevin Tian
>---
>v4:
>- Replace patch v3 title "Enhance posted-interrupt processing" with the
&g
On March 06, 2017 6:50 AM, Chao Gao wrote:
>On Mon, Mar 06, 2017 at 03:53:44AM +, Xuquan (Quan Xu) wrote:
>>On March 03, 2017 10:36 AM, Chao Gao wrote:
>>>+/*
>>>+ * Just like vcpu_kick(), nothing is needed for the following two cases:
>>>+
On March 07, 2017 12:24 PM, Chao Gao wrote:
>On Tue, Mar 07, 2017 at 02:16:50AM -0700, Jan Beulich wrote:
> On 07.03.17 at 06:52, wrote:
>>> flight 106504 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/106504/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not s
Hello,
I try to pass-through a device with 8G large bar, such as nvidia M60(note1,
pci-e info as below). It takes about '__15 sconds__' to update 8G large bar in
QEMU::xen_pt_region_update()..
Specifically, it is xc_domain_memory_mapping() in xen_pt_region_update().
Digged into xc_domain_memory
On March 16, 2017 10:06 PM, Jan Beulich wrote:
On 16.03.17 at 14:55, wrote:
>> I try to pass-through a device with 8G large bar, such as nvidia
>> M60(note1, pci-e info as below). It takes about '__15 sconds__' to
>> update 8G large bar in QEMU::xen_pt_region_update()..
>> Specifically, it is
On March 16, 2017 11:32 PM, Jan Beulich wrote:
On 16.03.17 at 15:21, wrote:
>> On March 16, 2017 10:06 PM, Jan Beulich wrote:
>> On 16.03.17 at 14:55, wrote:
I try to pass-through a device with 8G large bar, such as nvidia
M60(note1, pci-e info as below). It takes about '__15 s
On March 20, 2017 3:35 PM, Jan Beulich wrote:
On 20.03.17 at 02:58, wrote:
>> On March 16, 2017 11:32 PM, Jan Beulich wrote:
>> On 16.03.17 at 15:21, wrote:
On March 16, 2017 10:06 PM, Jan Beulich wrote:
On 16.03.17 at 14:55, wrote:
>> I try to pass-through a device wi
301 - 345 of 345 matches
Mail list logo
