All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Steve Rutherford <srutherford@google.com>, kvm@vger.kernel.org
Cc: ahonig@google.com
Subject: Re: [RFC PATCH 3/4] KVM: x86: Add EOI exit bitmap inference
Date: Wed, 13 May 2015 08:12:05 +0200	[thread overview]
Message-ID: <5552EB35.2070806@siemens.com> (raw)
In-Reply-To: <1431481652-27268-3-git-send-email-srutherford@google.com>

On 2015-05-13 03:47, Steve Rutherford wrote:
> In order to support a userspace IOAPIC interacting with an in kernel
> APIC, the EOI exit bitmaps need to be configurable.
> 
> If the IOAPIC is in userspace (i.e. the irqchip has been split), the
> EOI exit bitmaps will be set whenever the GSI Routes are configured.
> In particular, for the low 24 MSI routes, the EOI Exit bit
> corresponding to the destination vector will be set for the
> destination VCPU.
> 
> The intention is for the userspace IOAPIC to use MSI routes [0,23] to
> inject interrupts into the guest.
> 
> This is a slight abuse of the notion of an MSI Route, given that MSIs
> classically bypass the IOAPIC. It might be worthwhile to add an
> additional route type to improve clarity.
> 
> Compile tested for Intel x86.
> 
> Signed-off-by: Steve Rutherford <srutherford@google.com>
> ---
>  arch/x86/kvm/ioapic.c    | 11 +++++++++++
>  arch/x86/kvm/ioapic.h    |  1 +
>  arch/x86/kvm/lapic.c     |  2 ++
>  arch/x86/kvm/x86.c       | 13 +++++++++++--
>  include/linux/kvm_host.h |  4 ++++
>  virt/kvm/irqchip.c       | 32 ++++++++++++++++++++++++++++++++
>  6 files changed, 61 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kvm/ioapic.c b/arch/x86/kvm/ioapic.c
> index 856f791..3323c86 100644
> --- a/arch/x86/kvm/ioapic.c
> +++ b/arch/x86/kvm/ioapic.c
> @@ -672,3 +672,14 @@ int kvm_set_ioapic(struct kvm *kvm, struct kvm_ioapic_state *state)
>  	spin_unlock(&ioapic->lock);
>  	return 0;
>  }
> +
> +void kvm_vcpu_request_scan_userspace_ioapic(struct kvm *kvm)
> +{
> +	struct kvm_ioapic *ioapic = kvm->arch.vioapic;
> +
> +	if (ioapic)
> +		return;
> +	if (!lapic_in_kernel(kvm))
> +		return;
> +	kvm_make_scan_ioapic_request(kvm);
> +}
> diff --git a/arch/x86/kvm/ioapic.h b/arch/x86/kvm/ioapic.h
> index ca0b0b4..b7af71b 100644
> --- a/arch/x86/kvm/ioapic.h
> +++ b/arch/x86/kvm/ioapic.h
> @@ -123,4 +123,5 @@ int kvm_set_ioapic(struct kvm *kvm, struct kvm_ioapic_state *state);
>  void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap,
>  			u32 *tmr);
>  
> +void kvm_scan_ioapic_routes(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap);
>  #endif
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 42fada6f..7533b87 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -211,6 +211,8 @@ out:
>  
>  	if (!irqchip_split(kvm))
>  		kvm_vcpu_request_scan_ioapic(kvm);
> +	else
> +		kvm_vcpu_request_scan_userspace_ioapic(kvm);
>  }
>  
>  static inline void apic_set_spiv(struct kvm_lapic *apic, u32 val)
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index cc27c35..6127fe7 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -6335,8 +6335,17 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
>  				goto out;
>  			}
>  		}
> -		if (kvm_check_request(KVM_REQ_SCAN_IOAPIC, vcpu))
> -			vcpu_scan_ioapic(vcpu);
> +		if (kvm_check_request(KVM_REQ_SCAN_IOAPIC, vcpu)) {
> +			if (irqchip_split(vcpu->kvm)) {
> +				memset(vcpu->arch.eoi_exit_bitmaps, 0, 32);
> +				kvm_scan_ioapic_routes(
> +				    vcpu, vcpu->arch.eoi_exit_bitmaps);
> +				kvm_x86_ops->load_eoi_exitmap(
> +				    vcpu, vcpu->arch.eoi_exit_bitmaps);
> +
> +			} else
> +				vcpu_scan_ioapic(vcpu);
> +		}
>  		if (kvm_check_request(KVM_REQ_APIC_PAGE_RELOAD, vcpu))
>  			kvm_vcpu_reload_apic_access_page(vcpu);
>  	}
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index cef20ad..678215a 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -438,10 +438,14 @@ void vcpu_put(struct kvm_vcpu *vcpu);
>  
>  #ifdef __KVM_HAVE_IOAPIC
>  void kvm_vcpu_request_scan_ioapic(struct kvm *kvm);
> +void kvm_vcpu_request_scan_userspace_ioapic(struct kvm *kvm);
>  #else
>  static inline void kvm_vcpu_request_scan_ioapic(struct kvm *kvm)
>  {
>  }
> +static inline void kvm_vcpu_request_scan_userspace_ioapic(struct kvm *kvm)
> +{
> +}
>  #endif
>  
>  #ifdef CONFIG_HAVE_KVM_IRQFD
> diff --git a/virt/kvm/irqchip.c b/virt/kvm/irqchip.c
> index 8aaceed..8a253aa 100644
> --- a/virt/kvm/irqchip.c
> +++ b/virt/kvm/irqchip.c
> @@ -205,6 +205,8 @@ int kvm_set_irq_routing(struct kvm *kvm,
>  
>  	synchronize_srcu_expedited(&kvm->irq_srcu);
>  
> +	kvm_vcpu_request_scan_userspace_ioapic(kvm);
> +
>  	new = old;
>  	r = 0;
>  
> @@ -212,3 +214,33 @@ out:
>  	kfree(new);
>  	return r;
>  }
> +
> +void kvm_scan_ioapic_routes(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap)
> +{
> +	struct kvm *kvm = vcpu->kvm;
> +	struct kvm_kernel_irq_routing_entry *entry;
> +	struct kvm_irq_routing_table *table;
> +	u32 i, nr_rt_entries;
> +
> +	mutex_lock(&kvm->irq_lock);
> +	table = kvm->irq_routing;
> +	nr_rt_entries = min_t(u32, table->nr_rt_entries, IOAPIC_NUM_PINS);
> +	for (i = 0; i < nr_rt_entries; ++i) {
> +		hlist_for_each_entry(entry, &table->map[i], link) {
> +			u32 dest_id, dest_mode;
> +
> +			if (entry->type != KVM_IRQ_ROUTING_MSI)
> +				continue;
> +			dest_id = (entry->msi.address_lo >> 12) & 0xff;
> +			dest_mode = (entry->msi.address_lo >> 2) & 0x1;
> +			if (kvm_apic_match_dest(vcpu, NULL, 0, dest_id,
> +						dest_mode)) {
> +				u32 vector = entry->msi.data & 0xff;
> +
> +				__set_bit(vector,
> +					  (unsigned long *) eoi_exit_bitmap);
> +			}
> +		}
> +	}
> +	mutex_unlock(&kvm->irq_lock);
> +}
> 

This looks a bit frightening regarding the lookup costs. Do we really
have to run through the complete routing table to find the needed
information? There can be way more "real" MSI entries than IOAPIC pins.
There can even be multiple IOAPICs (thanks to your patches overcoming
the single in-kernel instance). And this is potentially serializing the
whole VM (kvm->irq_lock), not just those VCPUs that use the IOAPIC.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

  reply	other threads:[~2015-05-13  6:12 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-13  1:47 [RFC PATCH 1/4] KVM: x86: Split the APIC from the rest of IRQCHIP Steve Rutherford
2015-05-13  1:47 ` [RFC PATCH 2/4] KVM: x86: Add KVM exit for IOAPIC EOIs Steve Rutherford
2015-05-13  7:35   ` Paolo Bonzini
2015-05-13 22:18     ` Steve Rutherford
2015-05-24 16:46   ` Avi Kivity
2015-05-27  2:06     ` Steve Rutherford
2015-05-27  5:32       ` Avi Kivity
2015-05-28 21:58         ` Steve Rutherford
2015-05-13  1:47 ` [RFC PATCH 3/4] KVM: x86: Add EOI exit bitmap inference Steve Rutherford
2015-05-13  6:12   ` Jan Kiszka [this message]
2015-05-13  8:04     ` Paolo Bonzini
2015-05-13  8:10       ` Jan Kiszka
2015-05-13  9:24         ` Paolo Bonzini
2015-05-13 10:25           ` Jan Kiszka
2015-05-13 13:04             ` Paolo Bonzini
2015-05-13 13:19               ` Jan Kiszka
2015-05-13 22:21       ` Steve Rutherford
2015-05-15  2:38       ` Steve Rutherford
2015-05-13  7:51   ` Paolo Bonzini
2015-05-13 22:24     ` Steve Rutherford
2015-05-14  9:20       ` Paolo Bonzini
2015-05-14 15:23         ` Alex Williamson
2015-05-14 15:46           ` Paolo Bonzini
2015-05-14 16:04             ` Alex Williamson
2015-05-14 22:10               ` Steve Rutherford
2015-05-14 22:35                 ` Alex Williamson
2015-05-14 23:21                   ` Steve Rutherford
2015-05-13  1:47 ` [RFC PATCH 4/4] KVM: x86: Add support for local interrupt requests from userspace Steve Rutherford
2015-05-13  6:12   ` Jan Kiszka
2015-05-13 22:41     ` Steve Rutherford
2015-05-15 13:27       ` Jan Kiszka
2015-05-13  7:22   ` Paolo Bonzini
2015-05-13 23:13     ` Steve Rutherford
2015-05-13  7:57 ` [RFC PATCH 1/4] KVM: x86: Split the APIC from the rest of IRQCHIP Paolo Bonzini
2015-05-13 22:10   ` Steve Rutherford
2015-05-14  9:12     ` Wu, Feng
2015-05-14 19:29       ` Andrew Honig
2015-05-15  1:28         ` Wu, Feng
2015-05-15  5:03         ` Wanpeng Li
2015-05-15 18:10           ` Steve Rutherford
2015-05-18  2:11             ` Wanpeng Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5552EB35.2070806@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=ahonig@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=srutherford@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.