On 2017-11-16 05:31, Konrad Rzeszutek Wilk wrote:
On Mon, Nov 13, 2017 at 06:05:59PM +0800, Quan Xu wrote:
From: Yang Zhang
Some latency-intensive workload have seen obviously performance
drop when running inside VM. The main reason is that the overhead
is amplified when running inside VM
On 2017-11-16 17:45, Daniel Lezcano wrote:
On 16/11/2017 10:12, Quan Xu wrote:
On 2017-11-16 06:03, Thomas Gleixner wrote:
On Wed, 15 Nov 2017, Peter Zijlstra wrote:
On Mon, Nov 13, 2017 at 06:06:02PM +0800, Quan Xu wrote:
From: Yang Zhang
Implement a generic idle poll which resembles
On 2017-11-17 19:36, Thomas Gleixner wrote:
On Fri, 17 Nov 2017, Quan Xu wrote:
On 2017-11-16 17:53, Thomas Gleixner wrote:
That's just plain wrong. We don't want to see any of this PARAVIRT crap in
anything outside the architecture/hypervisor interfacing code which really
need
On 2017-11-16 17:53, Thomas Gleixner wrote:
On Thu, 16 Nov 2017, Quan Xu wrote:
On 2017-11-16 06:03, Thomas Gleixner wrote:
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -210,6 +210,13 @@ int cpuidle_enter_state(struct cpuidle_device *dev,
struct cpuidle_driver *drv
On 2017-11-16 16:45, Peter Zijlstra wrote:
On Wed, Nov 15, 2017 at 11:03:08PM +0100, Thomas Gleixner wrote:
If I understand the problem correctly then he wants to avoid the heavy
lifting in tick_nohz_idle_enter() in the first place, but there is already
an interesting quirk there which makes i
On 2017-11-16 06:03, Thomas Gleixner wrote:
On Wed, 15 Nov 2017, Peter Zijlstra wrote:
On Mon, Nov 13, 2017 at 06:06:02PM +0800, Quan Xu wrote:
From: Yang Zhang
Implement a generic idle poll which resembles the functionality
found in arch/. Provide weak arch_cpu_idle_poll function which
On 2017/11/14 18:27, Juergen Gross wrote:
On 14/11/17 10:38, Quan Xu wrote:
On 2017/11/14 15:30, Juergen Gross wrote:
On 14/11/17 08:02, Quan Xu wrote:
On 2017/11/13 18:53, Juergen Gross wrote:
On 13/11/17 11:06, Quan Xu wrote:
From: Quan Xu
So far, pv_idle_ops.poll is the only ops for
On 2017/11/14 16:22, Wanpeng Li wrote:
2017-11-14 16:15 GMT+08:00 Quan Xu :
On 2017/11/14 15:12, Wanpeng Li wrote:
2017-11-14 15:02 GMT+08:00 Quan Xu :
On 2017/11/13 18:53, Juergen Gross wrote:
On 13/11/17 11:06, Quan Xu wrote:
From: Quan Xu
So far, pv_idle_ops.poll is the only ops
On 2017/11/14 15:30, Juergen Gross wrote:
On 14/11/17 08:02, Quan Xu wrote:
On 2017/11/13 18:53, Juergen Gross wrote:
On 13/11/17 11:06, Quan Xu wrote:
From: Quan Xu
So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called
in idle path which will poll for a while before we
On 2017/11/14 15:12, Wanpeng Li wrote:
2017-11-14 15:02 GMT+08:00 Quan Xu :
On 2017/11/13 18:53, Juergen Gross wrote:
On 13/11/17 11:06, Quan Xu wrote:
From: Quan Xu
So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called
in idle path which will poll for a while before we
On 2017/11/13 18:53, Juergen Gross wrote:
On 13/11/17 11:06, Quan Xu wrote:
From: Quan Xu
So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called
in idle path which will poll for a while before we enter the real idle
state.
In virtualization, idle path includes several heavy
From: Yang Zhang
using smart idle poll to reduce the useless poll when system is idle.
Signed-off-by: Quan Xu
Signed-off-by: Yang Zhang
Cc: Paolo Bonzini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
Cc: linux-ker...@vger.
From: Quan Xu
the last idle loop is from tick_nohz_idle_enter to tick_nohz_idle_exit.
Signed-off-by: Yang Zhang
Signed-off-by: Quan Xu
Cc: Frederic Weisbecker
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: linux-ker...@vger.kernel.org
---
include/linux/tick.h |2 ++
kernel/time/tick
Prague.)
- enhance patch desciption.
- enhance Documentation and sysctls.
- test with IRQ_TIMINGS related code, which seems not working so far.
V1 -> V2:
- integrate the smart halt poll into paravirt code
- use idle_stamp instead of check_poll
- since it hard to get whether vcpu is the only task in p
several VM-exit/VM-entry cycles, VM-entry
for interrupts and VM-exit immediately. Also this becomes more
expensive than bare metal. Add a generic idle poll before enter
real idle path. When a reschedule event is pending, we can bypass
the real idle path.
Signed-off-by: Quan Xu
Signed-off-by: Yang Zhang
From: Quan Xu
So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called
in idle path which will poll for a while before we enter the real idle
state.
In virtualization, idle path includes several heavy operations
includes timer access(LAPIC timer or TSC deadline timer) which will
From: Quan Xu
Although smart idle poll has nothing to do with paravirt, it can
not bring any benifit to native. So we only enable it when Linux
runs as a KVM guest( also it can extend to other hypervisor like
Xen, HyperV and VMware).
Introduce per-CPU variable poll_duration_ns to control the
Prague.)
- enhance patch desciption.
- enhance Documentation and sysctls.
- test with IRQ_TIMINGS related code, which seems not working so far.
V1 -> V2:
- integrate the smart halt poll into paravirt code
- use idle_stamp instead of check_poll
- since it hard to get whether vcpu is the only task in p
ile:/home/vtpm2/vmgr,hda,w"]
name="vtpmmgr"
iomem=["fed40,5"]
extra="tpm2"
try again, good luck
Quan
>
> On Wed, Sep 13, 2017 at 8:27 AM, Quan Xu wrote:
>
>>
>>
>> on 2017/9/13 18:42, Wei Liu wrote:
>>
>>&
on 2017/9/13 18:42, Wei Liu wrote:
Cc VTPM maintainers
On Sun, Sep 10, 2017 at 03:07:04PM -0400, Ronny Ko wrote:
Hi,
I'm a PhD student from Harvard University having a trouble in running
vTPM manager.
I cannot successfully launch vTPM manager in Xen, because when I
command "sudo xl create v
BTW, I tried to clean up the vtpm code and stored it in the Git repo:
https://github.com/virt2x/vtpm2vtpmmgr
I hope that others will continue to clean up code and verify it (I don't have
tpm1.2/ tpm2.0 machine to verified it)..
Quan
On April 27, 2017 10:28 AM, Quan Xu wrote:
>From 291938c64ccf3a6d580dad7d3ca3311a49a4572e Mon Sep 17 00:00:00 2001
From: Quan Xu
Date: Fri, 28 Apr 2017 02:14:29 +0800
Subject: [PATCH] vTPM: update email address and file path in MAINTAINERS file
Signed-off-by: Quan Xu
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+)
__sorry for the noise, please ignore this patch__
On April 13, 2017 11:45 AM, Quan Xu wrote:
>On April 13, 2017 3:35 AM, Chao Gao wrote:
>>On Thu, Apr 13, 2017 at 02:20:23AM +, Xuquan (Quan Xu) wrote:
>>>From 946e7589e5a875574c7567a91943d47c38218a6f Mon Sep 17
>>00:00:
On April 13, 2017 3:35 AM, Chao Gao wrote:
>On Thu, Apr 13, 2017 at 02:20:23AM +, Xuquan (Quan Xu) wrote:
>>From 946e7589e5a875574c7567a91943d47c38218a6f Mon Sep 17
>00:00:00 2001
>>From: Quan Xu
>>Date: Fri, 14 Apr 2017 02:11:30 +0800
>>Subject: [PATCH v1] vmx:
>From 946e7589e5a875574c7567a91943d47c38218a6f Mon Sep 17 00:00:00 2001
From: Quan Xu
Date: Fri, 14 Apr 2017 02:11:30 +0800
Subject: [PATCH v1] vmx: set 'SN' bit for the runstate transition from blocked
to runnable
set 'SN' bit of posted-interrupt descriptor when the runs
On April 07, 2017 11:24 AM, Chao Gao wrote:
>When injecting periodic timer interrupt in vmx_intr_assist(), multiple read
>operation is operated during one event delivery and incur to inconsistent
>views of vIOAPIC. For example, if a periodic timer interrupt is from PIT, when
>set the corresponding
On April 05, 2017 7:58 AM, Chao Gao wrote:
>2. let pt_update_irq() pass the periodic timer whose interrupt is to be
>injected to vmx_intr_assit() which in turn can pass it to pt_intr_post().
>After
>this, pt_intr_post() needn't search the periodic timer that matches the
>interrupt has been inj
On March 22, 2017 2:14 PM, Chao Gao wrote:
>On Wed, Mar 22, 2017 at 06:47:33AM -0600, Jan Beulich wrote:
>>> 3. We read RTE 3 times. 1st happens when we set vIRR. 2nd happens
>>> when
>>> pt_update_irq() returns. 3rd happens in pt_intr_post(). If guest
>>> changes the vector in RTE during the windo
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
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 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
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 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
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:
>>>+
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 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
>>>
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
>> directly delivered to guest (leaving softirq being set without
>> actually incurring a VM-Exit - breaking desired softirq behavior).
>
>This i
TAINERS
> +++ b/MAINTAINERS
> @@ -215,7 +215,6 @@ F: xen/include/asm-x86/tboot.h
>
> INTEL(R) VT FOR DIRECTED I/O (VT-D)
> M: Kevin Tian
> -M: Feng Wu
> S: Supported
> F: xen/drivers/passthrough/vtd/
Reviewed-b
>From 6b5f702927d832513d270a2bca4634b271f4df47 Mon Sep 17 00:00:00 2001
From: Quan Xu
Date: Tue, 28 Feb 2017 02:48:29 +0800
Subject: [PATCH v2] x86/apicv: enhance posted-interrupt processing
If guest is already in non-root mode, an posted interrupt will
be directly delivered to guest (leav
On February 23, 2017 4:38 PM, Chao Gao wrote:
>On Thu, Feb 23, 2017 at 11:55:15AM +, Xuquan (Quan Xu) wrote:
>>On February 23, 2017 7:01 PM, Jan Beulich wrote:
>>>>>> On 23.02.17 at 11:53, wrote:
>>>> On February 23, 2017 5:59 PM, Jan Beulich wrote
On February 23, 2017 8:27 PM, Jan Beulich wrote:
On 23.02.17 at 12:55, wrote:
>> On February 23, 2017 7:01 PM, Jan Beulich wrote:
>> On 23.02.17 at 11:53, wrote:
IOW,
which vcpu does the 'current' refer to?
which cpu does the ' smp_processor_id()' refer to?
>>>
>>>curren
On February 23, 2017 7:01 PM, Jan Beulich wrote:
On 23.02.17 at 11:53, wrote:
>> On February 23, 2017 5:59 PM, Jan Beulich wrote:
>> On 23.02.17 at 10:28, wrote:
On February 18, 2017 12:33 AM, Jan Beulich wrote:
On 17.02.17 at 09:49, wrote:
>>>diff --git a/xen/arch/x86
On February 23, 2017 5:59 PM, Jan Beulich wrote:
>>>> On 23.02.17 at 10:28, wrote:
>> On February 18, 2017 12:33 AM, Jan Beulich wrote:
>>>>>> On 17.02.17 at 09:49, wrote:
>>>> On Fri, Feb 17, 2017 at 09:37:45AM +, Xuquan (Quan Xu) wrote:
&g
On February 18, 2017 12:33 AM, Jan Beulich wrote:
>>>> On 17.02.17 at 09:49, wrote:
>> On Fri, Feb 17, 2017 at 09:37:45AM +0000, Xuquan (Quan Xu) wrote:
>>>From a589074281cc22a30ed75a5bccba60e83d2312a6 Mon Sep 17
>00:00:00 2001
>>>From: Quan Xu
>>>
>From e101539e18625cb70dfaee58ae7e73aa5df7b8a9 Mon Sep 17 00:00:00 2001
From: Quan Xu
Date: Fri, 24 Feb 2017 08:43:16 +0800
Subject: [PATCH] x86/apicv: move posted_intr_vector handler to
pi_notification_interrupt
event_check_interrupt is likely used in pair with original delivery logic.
On February 21, 2017 5:55 AM, Chao Gao wrote:
>On Tue, Feb 21, 2017 at 04:11:53AM +, Xuquan (Quan Xu) wrote:
>>On February 21, 2017 11:07 AM, Tian, Kevin wrote:
>>>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>>>> Sent: Tuesday, February 21, 2017 10:
On February 21, 2017 11:07 AM, Tian, Kevin wrote:
>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>> Sent: Tuesday, February 21, 2017 10:49 AM
>>
>> On February 20, 2017 4:24 PM, Chao Gao wrote:
>> >On Mon, Feb 20, 2017 at 11:25:29AM +, Xuquan (Quan Xu)
On February 20, 2017 4:24 PM, Chao Gao wrote:
>On Mon, Feb 20, 2017 at 11:25:29AM +, Xuquan (Quan Xu) wrote:
>>On February 18, 2017 12:33 AM, Jan Beulich wrote:
>>>>>> On 17.02.17 at 09:49, wrote:
>>>> On Fri, Feb 17, 2017 at 09:37:45AM +
On February 13, 2017 4:21 PM, Tian, Kevin wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, February 08, 2017 4:52 PM
>>
>> >>> On 08.02.17 at 09:27, wrote:
>> > Assumed vCPU is in guest_mode..
>> > When apicv is enabled, hypervisor calls vmx_deliver_posted_intr(),
>> > th
On February 18, 2017 12:33 AM, Jan Beulich wrote:
>>>> On 17.02.17 at 09:49, wrote:
>> On Fri, Feb 17, 2017 at 09:37:45AM +0000, Xuquan (Quan Xu) wrote:
>>>From a589074281cc22a30ed75a5bccba60e83d2312a6 Mon Sep 17
>00:00:00 2001
>>>From: Quan Xu
>>>
>From a589074281cc22a30ed75a5bccba60e83d2312a6 Mon Sep 17 00:00:00 2001
From: Quan Xu
Date: Sat, 18 Feb 2017 09:27:37 +0800
Subject: [PATCH] x86/apicv: enhance posted-interrupt processing
If guest is already in non-root mode, an posted interrupt will
be directly delivered to guest (leav
On February 13, 2017 4:24 PM, Tian, Kevin wrote:
>> From: Tian, Kevin
>> Sent: Monday, February 13, 2017 4:21 PM
>>
>> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> > Sent: Wednesday, February 08, 2017 4:52 PM
>> >
>> > >>> On 08.02.17 at 09:27, wrote:
>> > > Assumed vCPU is in guest_mode..
>>
On February 08, 2017 4:22 PM, Chao Gao wrote:
>On Wed, Feb 08, 2017 at 10:15:28AM +, Xuquan (Quan Xu) wrote:
>>On February 08, 2017 4:52 PM, Jan Beulich wrote:
>>>>>> On 08.02.17 at 09:27, wrote:
>>>> Assumed vCPU is in guest_mode..
>&
On February 08, 2017 4:52 PM, Jan Beulich wrote:
On 08.02.17 at 09:27, wrote:
>> Assumed vCPU is in guest_mode..
>> When apicv is enabled, hypervisor calls vmx_deliver_posted_intr(),
>> then
>> __vmx_deliver_posted_interrupt() to deliver interrupt, but no vmexit
>> (also no
>> vcpu_kick() )..
On February 08, 2017 2:51 PM, Tian, Kevin wrote:
>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>> Sent: Monday, January 23, 2017 6:57 PM
>>
>> On January 20, 2017 5:09 PM, Quan Xu wrote:
>> >btw, for PIR.. I find that there might be a bug in
>> >_
On February 07, 2017 7:33 AM, Chao Gao wrote:
>Commit c7bdecae42 ("x86/apicv: fix RTC periodic timer and apicv issue")
>has added a assertion that intack.vector is the highest priority vector. But
>according to the osstest, the assertion failed sometimes. More discussion
>can be found in the thread
On January 20, 2017 5:09 PM, Quan Xu wrote:
>btw, for PIR.. I find that there might be a bug in
>__vmx_deliver_posted_interrupt()...
>why test_and_set_bit(VCPU_KICK_SOFTIRQ, &softirq_pending(cpu)) ??
>
>static void __vmx_deliver_posted_interrupt(struct vcpu *v
On January 16, 2017 1:26 PM, Tian, Kevin wrote:
>I cannot come up a valid reason for such situation (intack.vector is 0x30 while
>pt_vector is 0x38 from Chao's data). pt_update_irq is invoked before checking
>highest pending IRRs so pt_vector should be honored anyway.
>One possible reason is that b
On January 18, 2017 5:38 PM, Jan Beulich wrote:
>>>> On 18.01.17 at 05:57, wrote:
>> Attached was my earlier comment:
>>
>> --
>>> >>> On 20.12.16 at 06:37, wrote:
>>> >> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
&g
On January 16, 2017 1:26 PM, Tian, Kevin wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Thursday, January 12, 2017 8:26 PM
>>
>> >>> On 12.01.17 at 13:15, wrote:
>> > On 12/01/17 12:07, Xuquan (Quan Xu) wrote:
>> >> On Janua
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
>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 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 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 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)
>
>-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 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
>>
>}
>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)
>{
>
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
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]
&
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 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 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 1:37 PM, Tian, Kevin wrote:
>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>> Sent: Friday, December 16, 2016 5:40 PM
>>
>> From 89fffdd6b563b2723e24d17231715bb8c9f24f90 Mon Sep 17 00:00:00
>2001
>> From: Quan Xu
>> Date: Fri
>From 89fffdd6b563b2723e24d17231715bb8c9f24f90 Mon Sep 17 00:00:00 2001
From: Quan Xu
Date: Fri, 16 Dec 2016 17:24:01 +0800
Subject: [PATCH v3] 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 (w
On November 24, 2016 9:38 PM,
>On Thu, Nov 24, 2016 at 02:49:41PM +0800, Lan Tianyu wrote:
>> On 2016年11月24日 12:09, Edgar E. Iglesias wrote:
>> Hi,
>> > > >
>> > > > I have a few questions.
>> > > >
>> > > > If I understand correctly, you'll be emulating an Intel IOMMU in
On November 10, 2016 11:25 PM, Daniel De Graaf wrote:
>On 11/10/2016 04:23 AM, Cédric Bosdonnat wrote:
>> Gcc6 build reports misleading indentation as warnings. Fix a few
>> warnings in stubdom.
>>
>> Signed-off-by: Cédric Bosdonnat
>
>Acked-by: Dan
Hi,
Based on CVE-2015-7814 and commit 1ef01396fdff, ' arm: handle races between
relinquish_memory and free_domheap_pages'..
relinquish_memory() [xen/arch/arm/domain.c, arm code],
when couldn't get a reference -- someone is freeing this page and has already
committed to doing so, so no more to do
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 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 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 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 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 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 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
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 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]
>
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 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 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 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 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 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 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:
>>
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
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
>> 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
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
1 - 100 of 345 matches
Mail list logo