linux-kernel - Re: [PATCH] KVM: x86: Use fast path for Xen timer delivery

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <dff1ad07-8649-4916-bbc1-ab5cc403bb89@xen.org>
Date:   Fri, 22 Sep 2023 10:22:56 +0100
From:   Paul Durrant <xadimgnik@...il.com>
To:     David Woodhouse <dwmw2@...radead.org>, kvm <kvm@...r.kernel.org>
Cc:     Sean Christopherson <seanjc@...gle.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
        "Griffoul, Fred" <fgriffo@...zon.com>
Subject: Re: [PATCH] KVM: x86: Use fast path for Xen timer delivery

On 22/09/2023 10:20, David Woodhouse wrote:
> From: David Woodhouse <dwmw@...zon.co.uk>
> 
> Most of the time there's no need to kick the vCPU and deliver the timer
> event through kvm_xen_inject_timer_irqs(). Use kvm_xen_set_evtchn_fast()
> directly from the timer callback, and only fall back to the slow path
> when it's necessary to do so.
> 
> This gives a significant improvement in timer latency testing (using
> nanosleep() for various periods and then measuring the actual time
> elapsed).
> 
> Signed-off-by: David Woodhouse <dwmw@...zon.co.uk>
> ---
>   arch/x86/kvm/xen.c | 17 ++++++++++++++---
>   1 file changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
> index 40edf4d1974c..66c4cf93a55c 100644
> --- a/arch/x86/kvm/xen.c
> +++ b/arch/x86/kvm/xen.c
> @@ -134,12 +134,23 @@ static enum hrtimer_restart xen_timer_callback(struct hrtimer *timer)
>   {
>   	struct kvm_vcpu *vcpu = container_of(timer, struct kvm_vcpu,
>   					     arch.xen.timer);
> +	struct kvm_xen_evtchn e;
> +	int rc;
> +
>   	if (atomic_read(&vcpu->arch.xen.timer_pending))
>   		return HRTIMER_NORESTART;
>   
> -	atomic_inc(&vcpu->arch.xen.timer_pending);
> -	kvm_make_request(KVM_REQ_UNBLOCK, vcpu);
> -	kvm_vcpu_kick(vcpu);
> +	e.vcpu_id = vcpu->vcpu_id;
> +	e.vcpu_idx = vcpu->vcpu_idx;
> +	e.port = vcpu->arch.xen.timer_virq;

Don't you need to check the port for validity? The VMM may not have set 
it (and hence be delivering timer VIRQ events itself).

   Paul

> +	e.priority = KVM_IRQ_ROUTING_XEN_EVTCHN_PRIO_2LEVEL;
> +
> +	rc = kvm_xen_set_evtchn_fast(&e, vcpu->kvm);
> +	if (rc == -EWOULDBLOCK) {
> +		atomic_inc(&vcpu->arch.xen.timer_pending);
> +		kvm_make_request(KVM_REQ_UNBLOCK, vcpu);
> +		kvm_vcpu_kick(vcpu);
> +	}
>   
>   	return HRTIMER_NORESTART;
>   }