Re: [Xen-devel] [PATCH RFC v3 0/6] x86/idle: add halt poll support

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 <yang.zhang...@gmail.com> Some latency-intensive workload have seen obviously performance drop when running inside VM. The main reason is that the overhead is amp

Re: [Xen-devel] [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

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 <yang.zhang...@gmail.com> Implement a g

Re: [Xen-devel] [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

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 needs

Re: [Xen-devel] [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

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

Re: [Xen-devel] [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

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

Re: [Xen-devel] [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

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 <yang.zhang...@gmail.com> Implement a generic idle poll which resembles the functionality found in arch/. Provid

Re: [Xen-devel] [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

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 <quan@gmail.com> So far, pv_idle_op

Re: [Xen-devel] [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

On 2017/11/14 16:22, Wanpeng Li wrote: 2017-11-14 16:15 GMT+08:00 Quan Xu <quan@gmail.com>: On 2017/11/14 15:12, Wanpeng Li wrote: 2017-11-14 15:02 GMT+08:00 Quan Xu <quan@gmail.com>: On 2017/11/13 18:53, Juergen Gross wrote: On 13/11/17 11:06, Quan Xu wrote: From: Q

Re: [Xen-devel] [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt 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 <quan@gmail.com> So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called in idle path which wil

Re: [Xen-devel] [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

On 2017/11/14 15:12, Wanpeng Li wrote: 2017-11-14 15:02 GMT+08:00 Quan Xu <quan@gmail.com>: On 2017/11/13 18:53, Juergen Gross wrote: On 13/11/17 11:06, Quan Xu wrote: From: Quan Xu <quan@gmail.com> So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called

Re: [Xen-devel] [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

On 2017/11/13 18:53, Juergen Gross wrote: On 13/11/17 11:06, Quan Xu wrote: From: Quan Xu <quan@gmail.com> 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, idl

[Xen-devel] [PATCH RFC v3 6/6] KVM guest: introduce smart idle poll algorithm

From: Yang Zhang <yang.zhang...@gmail.com> using smart idle poll to reduce the useless poll when system is idle. Signed-off-by: Quan Xu <quan@gmail.com> Signed-off-by: Yang Zhang <yang.zhang...@gmail.com> Cc: Paolo Bonzini <pbonz...@redhat.com> Cc: Thomas Gleixner

[Xen-devel] [PATCH RFC v3 5/6] tick: get duration of the last idle loop

From: Quan Xu <quan@gmail.com> the last idle loop is from tick_nohz_idle_enter to tick_nohz_idle_exit. Signed-off-by: Yang Zhang <yang.zhang...@gmail.com> Signed-off-by: Quan Xu <quan@gmail.com> Cc: Frederic Weisbecker <fweis...@gmail.com> Cc: Thomas Gleixner

[Xen-devel] [PATCH RFC v3 0/6] x86/idle: add halt poll support

vcpu is the only task in pcpu, so we don't consider it in this series.(May improve it in future) --- Quan Xu (4): x86/paravirt: Add pv_idle_ops to paravirt ops KVM guest: register kvm_idle_poll for pv_idle_ops Documentation: Add three sysctls for smart idle poll tick: get duration of the last idl

[Xen-devel] [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

In KVM guest, this costs 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: Q

[Xen-devel] [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

From: Quan Xu <quan@gmail.com> 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 de

[Xen-devel] [PATCH RFC v3 2/6] KVM guest: register kvm_idle_poll for pv_idle_ops

From: Quan Xu <quan@gmail.com> 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 va

[Xen-devel] [PATCH RFC v3 0/6] x86/idle: add halt poll support

vcpu is the only task in pcpu, so we don't consider it in this series.(May improve it in future) --- Quan Xu (4): x86/paravirt: Add pv_idle_ops to paravirt ops KVM guest: register kvm_idle_poll for pv_idle_ops Documentation: Add three sysctls for smart idle poll tick: get duration of the last idl

Re: [Xen-devel] vTPM Manager VM launch failure: operation not permitted

sk=["file:/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 <quan@gmail.com> wrote: > >> >> >> on 2017/9/13 18:42,

Re: [Xen-devel] vTPM Manager VM launch failure: operation not permitted

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

Re: [Xen-devel] vTPM: update email address and file path in MAINTAINERS file

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

[Xen-devel] vTPM: update email address and file path in MAINTAINERS file

>From 291938c64ccf3a6d580dad7d3ca3311a49a4572e Mon Sep 17 00:00:00 2001 From: Quan Xu <xuqu...@huawei.com> 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 <xuqu...@huawei.com> --- MAINTAIN

Re: [Xen-devel] [PATCH v1] vmx: set 'SN' bit for the runstate transition from blocked to runnable

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

Re: [Xen-devel] [PATCH v1] vmx: set 'SN' bit for the runstate transition from blocked to runnable

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 <xuqu...@huawei.com> >>Date: Fri, 14 Apr 2017 02:11:30 +0800 >

[Xen-devel] [PATCH v1] vmx: set 'SN' bit for the runstate transition from blocked to runnable

>From 946e7589e5a875574c7567a91943d47c38218a6f Mon Sep 17 00:00:00 2001 From: Quan Xu <xuqu...@huawei.com> 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 descri

Re: [Xen-devel] [RFC PATCH] hvm/vpt: fix inconsistent views of vIOAPIC in vmx_intr_assist()

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

Re: [Xen-devel] [xen-unstable test] 106504: regressions - FAIL

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

Re: [Xen-devel] [xen-unstable test] 106504: regressions - FAIL

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

Re: [Xen-devel] question: xen/qemu - mmio mapping issues for device pass-through

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,

Re: [Xen-devel] question: xen/qemu - mmio mapping issues for device pass-through

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,

Re: [Xen-devel] question: xen/qemu - mmio mapping issues for device pass-through

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()..

[Xen-devel] question: xen/qemu - mmio mapping issues for device pass-through

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

Re: [Xen-devel] [xen-unstable test] 106504: regressions - FAIL

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

Re: [Xen-devel] [PATCH v4] x86/apicv: Fix wrong IPI suppression during posted interrupt delivery

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

Re: [Xen-devel] [PATCH v4] x86/apicv: Fix wrong IPI suppression during posted interrupt delivery

PI is consumed by hardware rather than raise a softirq unconditionally. > >Signed-off-by: Quan Xu <xuqu...@huawei.com> >Signed-off-by: Chao Gao <chao@intel.com> >Acked-by: Kevin Tian <kevin.t...@intel.com> >--- >v4: >- Replace patch v3 title "Enhance p

Re: [Xen-devel] [PATCH v2] x86/apicv: enhance posted-interrupt processing

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

Re: [Xen-devel] [PATCH v2] x86/apicv: enhance posted-interrupt processing

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

Re: [Xen-devel] [PATCH] MAINTAINERS: Update VT-d maintainers

844 100644 > --- a/MAINTAINERS > +++ 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 <kevin.tian@x> > -M: Feng Wu <feng.wu@x> > S: Supported > F: x

[Xen-devel] [PATCH v2] x86/apicv: enhance posted-interrupt processing

>From 6b5f702927d832513d270a2bca4634b271f4df47 Mon Sep 17 00:00:00 2001 From: Quan Xu <xuqu...@huawei.com> 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

Re: [Xen-devel] [PATCH] x86/apicv: enhance posted-interrupt processing

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, <xuqu...@huawei.com> wrote: >>>> On February 23, 2017 5:5

Re: [Xen-devel] [PATCH] x86/apicv: enhance posted-interrupt processing

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 '

Re: [Xen-devel] [PATCH] x86/apicv: enhance posted-interrupt processing

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,

Re: [Xen-devel] [PATCH] x86/apicv: enhance posted-interrupt processing

On February 23, 2017 5:59 PM, Jan Beulich wrote: >>>> On 23.02.17 at 10:28, <xuqu...@huawei.com> wrote: >> On February 18, 2017 12:33 AM, Jan Beulich wrote: >>>>>> On 17.02.17 at 09:49, <chao@intel.com> wrote: >>>> On Fri, Feb 17,

Re: [Xen-devel] [PATCH] x86/apicv: enhance posted-interrupt processing

On February 18, 2017 12:33 AM, Jan Beulich wrote: >>>> On 17.02.17 at 09:49, <chao@intel.com> wrote: >> On Fri, Feb 17, 2017 at 09:37:45AM +, Xuquan (Quan Xu) wrote: >>>From a589074281cc22a30ed75a5bccba60e83d2312a6 Mon Sep 17 >00:00:00 2001 >>&

[Xen-devel] [PATCH] x86/apicv: move posted_intr_vector handler to pi_notification_interrupt

>From e101539e18625cb70dfaee58ae7e73aa5df7b8a9 Mon Sep 17 00:00:00 2001 From: Quan Xu <xuqu...@huawei.com> 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

Re: [Xen-devel] [PATCH] x86/apicv: enhance posted-interrupt processing

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:

Re: [Xen-devel] [PATCH] x86/apicv: enhance posted-interrupt processing

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)

Re: [Xen-devel] [PATCH] x86/apicv: enhance posted-interrupt processing

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, <chao@intel.com> wrote: >>>> On Fri, Feb 17, 201

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

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

Re: [Xen-devel] [PATCH] x86/apicv: enhance posted-interrupt processing

On February 18, 2017 12:33 AM, Jan Beulich wrote: >>>> On 17.02.17 at 09:49, <chao@intel.com> wrote: >> On Fri, Feb 17, 2017 at 09:37:45AM +, Xuquan (Quan Xu) wrote: >>>From a589074281cc22a30ed75a5bccba60e83d2312a6 Mon Sep 17 >00:00:00 2001 >>&

[Xen-devel] [PATCH] x86/apicv: enhance posted-interrupt processing

>From a589074281cc22a30ed75a5bccba60e83d2312a6 Mon Sep 17 00:00:00 2001 From: Quan Xu <xuqu...@huawei.com> 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

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

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

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

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, <xuqu...@huawei.com> wrote: >>>> Assumed vCPU is in guest_

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

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

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

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

Re: [Xen-devel] [PATCH] X86/vmx: Dump PIR and vIRR before ASSERT()

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

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

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, _pending(cpu)) ?? > >static void __vmx_deliver_posted_interrupt(struct vcpu *v) { ... >if (

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

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

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

On January 18, 2017 5:38 PM, Jan Beulich wrote: >>>> On 18.01.17 at 05:57, <kevin.t...@intel.com> wrote: >> Attached was my earlier comment: >> >> -- >>> >>> On 20.12.16 at 06:37, <kevin.t...@intel.com> wrote: >>> >> From:

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

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, <andrew.coop...@citrix.com> wrote: >> > On 12/01/17 12:07, Xuquan (Quan Xu)

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

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

[Xen-devel] [PATCH v6] x86/apicv: fix RTC periodic timer and apicv issue

>From 7c0091cdce951f707bd8dff906aabdf5d645a85f Mon Sep 17 00:00:00 2001 From: Quan Xu <xuqu...@huawei.com> 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

Re: [Xen-devel] [PATCH v5] x86/apicv: fix RTC periodic timer and apicv issue

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

[Xen-devel] [PATCH v5] x86/apicv: fix RTC periodic timer and apicv issue

>From 9c23e1ff3eb75d71d691778a2e83421f645902fb Mon Sep 17 00:00:00 2001 From: Quan Xu <xuqu...@huawei.com> 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

Re: [Xen-devel] [PATCH v4] x86/apicv: fix RTC periodic timer and apicv issue

On January 03, 2017 4:23 PM, Jan Beulich wrote: >>>> On 03.01.17 at 09:15, <xuqu...@huawei.com> wrote: > >> >>>-Original Message- >>>From: Jan Beulich [mailto:jbeul...@suse.com] >>>Sent: Tuesday, January 03, 2017 3:35 PM >&

Re: [Xen-devel] [PATCH v4] x86/apicv: fix RTC periodic timer and apicv issue

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

Re: [Xen-devel] [PATCH v4] x86/apicv: fix RTC periodic timer and apicv issue

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

Re: [Xen-devel] [PATCH v4] x86/apicv: fix RTC periodic timer and apicv issue

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

[Xen-devel] [PATCH v4] x86/apicv: fix RTC periodic timer and apicv issue

t. 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 <xuqu...@huawei.com> --- x

Re: [Xen-devel] [PATCH v3] x86/apicv: fix RTC periodic timer and apicv issue

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

Re: [Xen-devel] [PATCH v3] x86/apicv: fix RTC periodic timer and apicv issue

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 accuracy

Re: [Xen-devel] [PATCH v3] x86/apicv: fix RTC periodic timer and apicv issue

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, <kevin.t...@intel.com> wrote: >> >> From: Xuquan (Quan Xu) [mailto:xuqu..

Re: [Xen-devel] [PATCH v3] x86/apicv: fix RTC periodic timer and apicv issue

On December 20, 2016 4:32 PM, Jan Beulich wrote: >>>> On 20.12.16 at 06:54, <xuqu...@huawei.com> wrote: >> On December 20, 2016 1:37 PM, Tian, Kevin wrote: >>>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com] >>>> Sent:

Re: [Xen-devel] [PATCH v3] x86/apicv: fix RTC periodic timer and apicv issue

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 <xuqu...@huawei.com

[Xen-devel] [PATCH v3] x86/apicv: fix RTC periodic timer and apicv issue

>From 89fffdd6b563b2723e24d17231715bb8c9f24f90 Mon Sep 17 00:00:00 2001 From: Quan Xu <xuqu...@huawei.com> 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

Re: [Xen-devel] Xen virtual IOMMU high level design doc

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

Re: [Xen-devel] [PATCH] Fix misleading indentation warnings

gt; >Acked-by: Daniel De Graaf <dgde...@tycho.nsa.gov> Acked-by: Quan Xu <xuqu...@huawei.com> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

[Xen-devel] question: is it a CVE in relinquish_memory()[xen/arch/x86/domain.c]

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

Re: [Xen-devel] [PATCH RFC] hvm: Allow triple fault to imply crash rather than reboot

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

Re: [Xen-devel] [PATCH RFC] hvm: Allow triple fault to imply crash rather than reboot

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

Re: [Xen-devel] qeustion: a panic in __do_update_va_mapping()

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

Re: [Xen-devel] qeustion: a panic in __do_update_va_mapping()

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

Re: [Xen-devel] qeustion: a panic in __do_update_va_mapping()

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 ><andrew.coop...@citrix.com > wrote: >>> On 01/11/16 11:23, Xuquan (Quan Xu) wrote: >>>> On November 01, 2016 7

Re: [Xen-devel] qeustion: a panic in __do_update_va_mapping()

On November 01, 2016 7:41 PM, Andrew Cooper <andrew.coop...@citrix.com > 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: >>

Re: [Xen-devel] qeustion: a panic in __do_update_va_mapping()

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

[Xen-devel] qeustion: a panic in __do_update_va_mapping()

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

Re: [Xen-devel] [PATCH v2] x86/apicv: fix RTC periodic timer and apicv issue

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

Re: [Xen-devel] [PATCH v2] x86/apicv: fix RTC periodic timer and apicv issue

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

Re: [Xen-devel] [PATCH v2] x86/apicv: fix RTC periodic timer and apicv issue

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

Re: [Xen-devel] [PATCH v2 00/13] Refactor common part of xen backend and frontend

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

Re: [Xen-devel] [PATCH v2] x86/apicv: fix RTC periodic timer and apicv issue

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

Re: [Xen-devel] [PATCH v2] x86/apicv: fix RTC periodic timer and apicv issue

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

Re: [Xen-devel] [PATCH v2] x86/apicv: fix RTC periodic timer and apicv issue

On October 11, 2016 7:11 PM, Xuquan < xuqu...@huawei.com > wrote: >On October 11, 2016 3:49 PM, Tian, Kevin <kevin.t...@intel.com> >>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com] >>> Sent: Monday, October 10, 2016 6:49 PM >>> >>> On Octobe

Re: [Xen-devel] [PATCH 15/15] xen: Rename xen_be_frontend_changed

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,

Re: [Xen-devel] [PATCH 14/15] xen: Rename xen_be_del_xendev

igned-off-by: Emil Condrea <emilcond...@gmail.com> > >Acked-by: Anthony PERARD <anthony.per...@citrix.com> > Reviewed-by: Quan Xu <xuqu...@huawei.com> Quan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 13/15] xen: Rename xen_be_find_xendev

igned-off-by: Emil Condrea <emilcond...@gmail.com> > >Acked-by: Anthony PERARD <anthony.per...@citrix.com> > Reviewed-by: Quan Xu <xuqu...@huawei.com> Quan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 12/15] xen: Rename xen_be_evtchn_event

igned-off-by: Emil Condrea <emilcond...@gmail.com> > >Acked-by: Anthony PERARD <anthony.per...@citrix.com> > Reviewed-by: Quan Xu <xuqu...@huawei.com> Quan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 11/15] xen: Rename xen_be_send_notify

igned-off-by: Emil Condrea <emilcond...@gmail.com> > >Acked-by: Anthony PERARD <anthony.per...@citrix.com> > Reviewed-by: Quan Xu <xuqu...@huawei.com> Quan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 10/15] xen: Rename xen_be_unbind_evtchn

>> Signed-off-by: Emil Condrea <emilcond...@gmail.com> > >Acked-by: Anthony PERARD <anthony.per...@citrix.com> > Reviewed-by: Quan Xu <xuqu...@huawei.com> Quan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] x86/apicv: fix RTC periodic timer and apicv issue

On October 11, 2016 3:49 PM, Tian, Kevin <kevin.t...@intel.com> >> 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: >> >>>>&

  1   2   3   4   >