From mboxrd@z Thu Jan 1 00:00:00 1970 From: "rkrcmar@redhat.com" Subject: Re: [PATCH v3 2/4] KVM: x86: Use vector-hashing to deliver lowest-priority interrupts Date: Fri, 22 Jan 2016 14:49:12 +0100 Message-ID: <20160122134911.GC14104@potion.brq.redhat.com> References: <1453254177-103002-1-git-send-email-feng.wu@intel.com> <1453254177-103002-3-git-send-email-feng.wu@intel.com> <56A06B60.5030501@gmail.com> <20160121172109.GB17514@potion.brq.redhat.com> <56A1A94C.7010703@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Wu, Feng" , "pbonzini@redhat.com" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" To: Yang Zhang Return-path: Received: from mx1.redhat.com ([209.132.183.28]:35798 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753906AbcAVNtP (ORCPT ); Fri, 22 Jan 2016 08:49:15 -0500 Content-Disposition: inline In-Reply-To: <56A1A94C.7010703@gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: 2016-01-22 12:00+0800, Yang Zhang: > On 2016/1/22 1:21, rkrcmar@redhat.com wrote: >>(I think there isn't a practical difference between *r=-1 and *r=0.) > > Currently, if *r == -1, the remote_irr may get set. But it seems wrong. I Yeah ... > need to have a double check to see whether it is a bug in current code. Looking forward to the patch! Thanks. >>'ret = true' is the better one. We know that the interrupt is not >>deliverable [1], so there's no point in trying to deliver with the slow >>path. We behave similarly when the interrupt targets a single disabled >>APIC. >> >>--- >>1: Well ... it's possible that slowpath would deliver it thanks to >> different handling of disabled APICs, but it's undefined behavior, > > why it is undefined behavior? Besides, why we will keep two different > handling logic for the fast path and slow path? It looks weird. It does look very weird ... the slow path would require refactoring, though, so we save effort without a considerable drawback. (I would love if it behaved identically, but I don't want to force it on someone and likely won't do it myself ...) I consider it undefined because SMD says that an OS musn't configure this behavior and doesn't say what should happen if the OS does => we could do anything. (Killing the guest would be great for debugging OS issues, but ours behavior is fairly conservative.)