public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Shan, Haitao" <haitao.shan@intel.com>,
	"mtosatti@redhat.com" <mtosatti@redhat.com>,
	"Zhang, Xiantao" <xiantao.zhang@intel.com>,
	"Tian, Kevin" <kevin.tian@intel.com>
Subject: Re: [PATCH v11 3/3] x86, apicv: add virtual interrupt delivery support
Date: Mon, 21 Jan 2013 07:03:00 +0200	[thread overview]
Message-ID: <20130121050300.GA25818@redhat.com> (raw)
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E311507@SHSMSX101.ccr.corp.intel.com>

On Mon, Jan 21, 2013 at 12:49:01AM +0000, Zhang, Yang Z wrote:
> Gleb Natapov wrote on 2013-01-20:
> > On Thu, Jan 17, 2013 at 01:26:03AM +0000, Zhang, Yang Z wrote:
> >> Previous patch is stale. Resend the new patch.
> >> The only change is clear EOI and SELF-IPI reg in msr bitmap when vid is enabled.
> >> 
> >> ------------------------
> >> @@ -340,6 +325,8 @@ static inline int apic_find_highest_irr(struct kvm_lapic
> > *apic)
> >>  {
> >>  	int result;
> >> +	/* Note that irr_pending is just a hint. It will be always
> >> +	 * true with virtual interrupt delivery enabled. */
> > This is not correct format for multi-line comments.
> Sure, will correct it here and below.
> 
> >> +static void vmx_check_ioapic_entry(struct kvm_vcpu *vcpu,
> >> +				   struct kvm_lapic_irq *irq)
> >> +{
> >> +	struct kvm_lapic **dst;
> >> +	struct kvm_apic_map *map;
> >> +	unsigned long bitmap = 1;
> >> +	int i;
> >> +
> >> +	rcu_read_lock();
> >> +	map = rcu_dereference(vcpu->kvm->arch.apic_map);
> >> +
> >> +	if (unlikely(!map)) {
> >> +		set_eoi_exitmap_one(vcpu, irq->vector);
> >> +		goto out;
> >> +	}
> >> +
> >> +	if (irq->dest_mode == 0) { /* physical mode */
> >> +		if (irq->delivery_mode == APIC_DM_LOWEST ||
> >> +				irq->dest_id == 0xff) {
> >> +			set_eoi_exitmap_one(vcpu, irq->vector);
> >> +			goto out;
> >> +		}
> >> +		dst = &map->phys_map[irq->dest_id & 0xff];
> >> +	} else {
> >> +		u32 mda = irq->dest_id << (32 - map->ldr_bits);
> >> +
> >> +		dst = map->logical_map[apic_cluster_id(map, mda)];
> >> +
> >> +		bitmap = apic_logical_id(map, mda);
> >> +	}
> >> +
> >> +	for_each_set_bit(i, &bitmap, 16) {
> >> +		if (!dst[i])
> >> +			continue;
> >> +		if (dst[i]->vcpu == vcpu) {
> >> +			set_eoi_exitmap_one(vcpu, irq->vector);
> >> +			break;
> >> +		}
> >> +	}
> >> +
> >> +out:
> >> +	rcu_read_unlock();
> >> +}
> > The logic in this function belongs to lapic code. The only thing
> > that is specific to vmx in the function is setting of the bit in
> > vmx->eoi_exit_bitmap, but since eoi_exit_bitmap is calculated and
> > loaded during same vcpu entry we do not need vmx->eoi_exit_bitmap at
> > all. Declare it on a stack in vmx_update_eoi_exitmap() and pass it to
> > set_eoi_exitmap() and vmx_load_eoi_exitmap().
> IIRC, this logic is in lapic before v7. And you suggested to move the whole function into vmx code.
> So, it better to move back to lapic file?
> 
IIRC I suggested to call it only from vmx, not move it there. Before
that the calculation was done even with vid disabled and only result was
ignored. With current logic KVM_REQ_EOIBITMAP will be set only with vid
enabled so the calculation will not be done needlessly.


> >> @@ -115,6 +116,42 @@ static void update_handled_vectors(struct kvm_ioapic
> > *ioapic)
> >>  	smp_wmb();
> >>  }
> >> +void set_eoi_exitmap(struct kvm_vcpu *vcpu)
> >> +{
> > This function is exported from the file and need to have more unique
> > name. kvm_ioapic_calculate_eoi_exitmap() for instance.
> Ok.
> 
> >> @@ -156,6 +193,7 @@ static void ioapic_write_indirect(struct kvm_ioapic
> > *ioapic, u32 val)
> >>  		if (e->fields.trig_mode == IOAPIC_LEVEL_TRIG
> >>  		    && ioapic->irr & (1 << index))
> >>  			ioapic_service(ioapic, index);
> >> +		ioapic_update_eoi_exitmap(ioapic->kvm);
> > ioapic_write_indirect() is called under ioapic->lock,
> > ioapic_update_eoi_exitmap() takes the same lock. Have you tested the
> > code?
> ioapic_update_eoi_exitmap doesn't take any lock.
> 
Sorry. You are correct. Confused between different functions.

> I will do a full testing for every patch before sending out. It covers both windows and Linux guest.
> 
We are getting close so please test with userspace irq chip too.

--
			Gleb.

  reply	other threads:[~2013-01-21  5:03 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-16 10:21 [PATCH v11 0/3] x86, apicv: Add APIC virtualization support Yang Zhang
2013-01-16 10:21 ` [PATCH v11 1/3] x86, apicv: add APICv register " Yang Zhang
2013-01-16 10:21 ` [PATCH v11 2/3] x86, apicv: add virtual x2apic support Yang Zhang
2013-01-17 13:22   ` Gleb Natapov
2013-01-18  1:49     ` Zhang, Yang Z
2013-01-21 19:59   ` Marcelo Tosatti
2013-01-21 20:21     ` Gleb Natapov
2013-01-21 21:21       ` Marcelo Tosatti
2013-01-21 21:34         ` Gleb Natapov
2013-01-21 22:16           ` Marcelo Tosatti
2013-01-22  0:33             ` Marcelo Tosatti
2013-01-22  3:37               ` Zhang, Yang Z
2013-01-22  9:45               ` Gleb Natapov
2013-01-22  9:42             ` Gleb Natapov
2013-01-22 12:21     ` Zhang, Yang Z
2013-01-22 15:55       ` Gleb Natapov
2013-01-22 23:13         ` Marcelo Tosatti
2013-01-23  0:35           ` Zhang, Yang Z
2013-01-23 10:29           ` Gleb Natapov
2013-01-16 10:21 ` [PATCH v11 3/3] x86, apicv: add virtual interrupt delivery support Yang Zhang
2013-01-17  1:26   ` Zhang, Yang Z
2013-01-20 12:51     ` Gleb Natapov
2013-01-21  0:49       ` Zhang, Yang Z
2013-01-21  5:03         ` Gleb Natapov [this message]
2013-01-21  7:18           ` Zhang, Yang Z
2013-01-21 21:08           ` Marcelo Tosatti
2013-01-23  0:45           ` Zhang, Yang Z
2013-01-23 10:33             ` Gleb Natapov
2013-01-23 10:52               ` Zhang, Yang Z
2013-01-21 21:05   ` Marcelo Tosatti
2013-01-21 21:18     ` Gleb Natapov
2013-01-21 21:54       ` Marcelo Tosatti
2013-01-22  3:38         ` Zhang, Yang Z
2013-01-16 10:27 ` [PATCH v11 0/3] x86, apicv: Add APIC virtualization support Gleb Natapov

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=20130121050300.GA25818@redhat.com \
    --to=gleb@redhat.com \
    --cc=haitao.shan@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=xiantao.zhang@intel.com \
    --cc=yang.z.zhang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox