From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752527AbbIQXP2 (ORCPT ); Thu, 17 Sep 2015 19:15:28 -0400 Received: from mga01.intel.com ([192.55.52.88]:24446 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751901AbbIQXP0 convert rfc822-to-8bit (ORCPT ); Thu, 17 Sep 2015 19:15:26 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,549,1437462000"; d="scan'208";a="563885387" From: "Wu, Feng" To: Paolo Bonzini , "alex.williamson@redhat.com" , "joro@8bytes.org" , "mtosatti@redhat.com" CC: "eric.auger@linaro.org" , "kvm@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "linux-kernel@vger.kernel.org" , =?iso-8859-2?Q?Radim_Kr=3Fm=E1=3F?= , "Wu, Feng" Subject: RE: [PATCH v8 03/13] KVM: Define a new interface kvm_intr_is_single_vcpu() Thread-Topic: [PATCH v8 03/13] KVM: Define a new interface kvm_intr_is_single_vcpu() Thread-Index: AQHQ8VSmumRRGxecXEyTo/6OL/watJ5BWkLg Date: Thu, 17 Sep 2015 23:15:21 +0000 Message-ID: References: <1442393409-2623-1-git-send-email-feng.wu@intel.com> <1442393409-2623-4-git-send-email-feng.wu@intel.com> <55F934F5.7040605@redhat.com> <55FA8AED.6090700@redhat.com> <55FACD35.1030602@redhat.com> In-Reply-To: <55FACD35.1030602@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > -----Original Message----- > From: Paolo Bonzini [mailto:pbonzini@redhat.com] > Sent: Thursday, September 17, 2015 10:25 PM > To: Wu, Feng; alex.williamson@redhat.com; joro@8bytes.org; > mtosatti@redhat.com > Cc: eric.auger@linaro.org; kvm@vger.kernel.org; > iommu@lists.linux-foundation.org; linux-kernel@vger.kernel.org; Radim > Krèmáø > Subject: Re: [PATCH v8 03/13] KVM: Define a new interface > kvm_intr_is_single_vcpu() > > >> On 17/09/2015 05:17, Wu, Feng wrote: > >>>>>>> + if (irq->dest_mode == APIC_DEST_PHYSICAL) { > >>>>>>> + if (irq->dest_id == 0xFF) > >>>>>>> + goto out; > >>>>>>> + > >>>>>>> + if (irq->dest_id >= ARRAY_SIZE(map->phys_map)) { > >>>>> > >>>>> Warning here is wrong, the guest can trigger it. > >>> Could you please share more information about how the guest > >>> triggers these conditions (including the following two), Thanks > >>> a lot! > >> > >> irq->dest_id is a 16-bit value, so it can be > 255. > > > > Yes, irq->dest_id is defined as u32, but by looking the current KVM > > code, seems desst_id is used as an u8 variable, even in x2apic mode > > the dest_id will not beyond 255 (except for broadcast dest in in x2apic > > mode). Correct me if I am wrong. Thanks a lot! > > Actually you're right, the MSI destination is only 8 bits. I was > confused because of > > #define MSI_ADDR_DEST_ID_MASK 0x00ffff0 > > in arch/x86/include/asm/msidef.h. But there may be a bug, see below... > > >>> + if (cid >= ARRAY_SIZE(map->logical_map)) { > >>> + WARN_ON_ONCE(1); > >> > >> In x2apic mode irq->dest_id could have bits 12..15 set. > > > > cid is gotten from bit 16 ..31 of the ldr (in apic_logical_id()), and > > in x2apic mode, ldr is constructed in kvm_apic_set_x2apic_id() as > > below: > > > > u32 ldr = ((id >> 4) << 16) | (1 << (id & 0xf)); > > > > So in fact, cid is (id >> 4), I cannot think of why cid can beyond 15. > > I think kvm_apic_match_logical_addr for MSI and IOAPIC interrupts is > buggy in x2apic mode. > > It does: > > if (apic_x2apic_mode(apic)) > return ((logical_id >> 16) == (mda >> 16)) > && (logical_id & mda & 0xffff) != 0; > > But mda is only 8-bits for MSI and IOAPIC interrupts. > > Radim, should kvm_apic_mda also handle the !ipi && x2apic_mda && dest_id > != APIC_BROADCAST case? It never triggers with Linux because it uses > only the physical mode (that's not super-easy to see; > ioapic_set_affinity looks for the RTEs in irq_data->chip_data and that > is allocated with kzalloc). > > > Do I miss something here? Thanks! > > No, you were right. > > But still I think the WARNs are unnecessary; it is conceivable that some > future chipset adds support for more than 8-bits in the dest_id. No problem, I agree with it. Here I just want clarify some questions, thanks for the elaboration! Thanks, Feng > > Paolo > > > Thanks, > > Feng > > > >> > >> Paolo