From mboxrd@z Thu Jan  1 00:00:00 1970
From: Gleb Natapov <gleb@redhat.com>
Subject: Re: [RFC PATCH] KVM: optimize apic interrupt delivery
Date: Tue, 11 Sep 2012 12:35:02 +0300
Message-ID: <20120911093502.GF20907@redhat.com>
References: <20120910130915.GB20907@redhat.com>
 <20120910144438.GA19741@redhat.com>
 <20120910161754.GB25827@redhat.com>
 <20120910170522.GC25827@redhat.com>
 <504F0462.5050103@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "Michael S. Tsirkin" <mst@redhat.com>, kvm@vger.kernel.org,
	mtosatti@redhat.com
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:56506 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1756744Ab2IKJfD (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 11 Sep 2012 05:35:03 -0400
Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q8B9Z3aC000356
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <kvm@vger.kernel.org>; Tue, 11 Sep 2012 05:35:03 -0400
Content-Disposition: inline
In-Reply-To: <504F0462.5050103@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Tue, Sep 11, 2012 at 12:29:06PM +0300, Avi Kivity wrote:
> On 09/10/2012 08:05 PM, Gleb Natapov wrote:
> > On Mon, Sep 10, 2012 at 07:17:54PM +0300, Gleb Natapov wrote:
> >> > > +	return 0;
> >> > > +}
> >> > > +
> >> > > +static inline int kvm_apic_set_id(struct kvm_lapic *apic, u8 id)
> >> > > +{
> >> > > +	apic_set_reg(apic, APIC_ID, id << 24);
> >> > > +	return recalculate_apic_map(apic->vcpu->kvm);
> >> > > +}
> >> > > +
> >> > > +static inline int kvm_apic_set_ldr(struct kvm_lapic *apic, u32 id)
> >> > > +{
> >> > > +	apic_set_reg(apic, APIC_LDR, id);
> >> > > +	return recalculate_apic_map(apic->vcpu->kvm);
> >> > > +}
> >> > > +
> >> > 
> >> > return value of these functions seems never checked.
> >> > 
> >> Yes, the problem is that we can do nothing about the failure if failure
> >> happens during guest write.
> 
> We can.  Return -ENOMEM all the way up to userspace.
> 
There is no userspace to return error to if error happens on guest MMIO
write. Unless you mean return it as a return value of ioctl(VM_RUN) in
which case it is equivalent of killing the guest. And this is not fair
to a guest who did nothing wrong to suffer from our stupid optimizations :)
Actually I am not sure that returning to userspace in the middle of an
IO that is handled by a kernel is well defined in KVM ABI.

> >> 
> > Actually I have an idea how to handle the error. Never return one. If
> > map cannot be allocated go slow path always. phys_map should be checked
> > for NULL during delivery in this case obviously.
> 
> That's better of course (though we have to beware of such tricks, but in
> this case the slow path is regularly exercised so it should keep working).
> 
Oh with Windows guests it has work to do for sure.

--
			Gleb.