From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AD511ECAAD1 for ; Wed, 31 Aug 2022 16:57:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232356AbiHaQ5W (ORCPT ); Wed, 31 Aug 2022 12:57:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60498 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232084AbiHaQ4y (ORCPT ); Wed, 31 Aug 2022 12:56:54 -0400 Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 61B1BDB07E for ; Wed, 31 Aug 2022 09:56:52 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id f4so13981941pgc.12 for ; Wed, 31 Aug 2022 09:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=HdAipv40/QqUuhoEN6Hq6J9CX7+XanSXNZDP7WXuA2w=; b=E+dpjJqqZDnYhWyJB7NPrHbcJXnwY/FVAxgTif0XLDolthQbNU2kb5duOzTXFJRyNt 2hw1fG/0dF2n9h3l7igOMBUOwD2I41lLkJ5A3S4SqigYhZ2F8AUr6PC7+mm5zna0OiKM 7uSVQlx3qx8FVlP7XSuym/DhcVMW27h6f3oRVcIyKbXjcccx6adclZmABrC7J+dh5qYF 9svm06eXHLHJKMUb1s1RGoYVAzDRYFtPIwVWRXoIMKYBYtBbgkwoUtrsKu4p7H+856ti 3Xtm+2zdCedDRsDBZpFhZLp5JndSPq3kmB7RN63yD4rkTyjuj/KhtREr8vQwwZl4Cd0S SiyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=HdAipv40/QqUuhoEN6Hq6J9CX7+XanSXNZDP7WXuA2w=; b=WCh3sPUK8gxst4EX4zW+eMPAxa/Mvly1K4L1kyeDqvWRjWL6kJN2pvHOEOqbBgiSmh Y2gnjQFxr7HtudrWc6VHzvV/lrtCbLtdvOAbdJ6DoFd58XnZffz17A/DBbPcHUafzCD2 soISDTbcSg69eKbfy8iqC+e09x1CkOaQA38S3T0EYcTtmsC8OoZCTX/DqzfGAV8RKlwk j7iTClY2yCNCMWc+FIZZf0zJYA6V82f73YHUWhopy68URFUccMxUjw6CAWGG0QMX29tG LbCFAvLfWMcrNkM9S8acnjdEnK6vkPGg5LzXbCghRY5dWYrpxNqwAt8GhxZMi1veKLxM ZGvQ== X-Gm-Message-State: ACgBeo2bg++3J9TV1k3jPKcFdRdTJQ/NJSUT7VeMHl+FRVZdr34WcOFA gIRZzdPis8jQQO0V+G76tareww== X-Google-Smtp-Source: AA6agR6cQdWCJj8nIL8lC0/B1orERU83CcRBe8mpU1Xnak54m5SKBPoax0iLrY8he6N8y6biTQJi5g== X-Received: by 2002:a63:fb56:0:b0:429:983f:b91e with SMTP id w22-20020a63fb56000000b00429983fb91emr22939560pgj.399.1661965011770; Wed, 31 Aug 2022 09:56:51 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id p15-20020a170902780f00b0017555cef23asm199694pll.232.2022.08.31.09.56.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Aug 2022 09:56:51 -0700 (PDT) Date: Wed, 31 Aug 2022 16:56:47 +0000 From: Sean Christopherson To: Maxim Levitsky Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Suravee Suthikulpanit , Li RongQing Subject: Re: [PATCH 16/19] KVM: x86: Explicitly track all possibilities for APIC map's logical modes Message-ID: References: <20220831003506.4117148-1-seanjc@google.com> <20220831003506.4117148-17-seanjc@google.com> <8d3569a8b2d1563eb3ff665118ffc5c8d7e1e2f2.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8d3569a8b2d1563eb3ff665118ffc5c8d7e1e2f2.camel@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 31, 2022, Maxim Levitsky wrote: > > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c > > index 8209caffe3ab..3b6ef36b3963 100644 > > --- a/arch/x86/kvm/lapic.c > > +++ b/arch/x86/kvm/lapic.c > > @@ -168,7 +168,12 @@ static bool kvm_use_posted_timer_interrupt(struct kvm_vcpu *vcpu) > > > > static inline bool kvm_apic_map_get_logical_dest(struct kvm_apic_map *map, > > u32 dest_id, struct kvm_lapic ***cluster, u16 *mask) { > > - switch (map->mode) { > > + switch (map->logical_mode) { > > + case KVM_APIC_MODE_SW_DISABLED: > > + /* Arbitrarily use the flat map so that @cluster isn't NULL. */ > > + *cluster = map->xapic_flat_map; > > + *mask = 0; > > + return true; > Could you explain why this is needed? I probably missed something. If all vCPUs leave their APIC software disabled, or leave LDR=0, then the overall mode will be KVM_APIC_MODE_SW_DISABLED. In this case, the effective "mask" is '0' because there are no targets. And this returns %true because there are no targets, i.e. there's no need to go down the slow path after kvm_apic_map_get_dest_lapic(). > > @@ -993,7 +1011,7 @@ static bool kvm_apic_is_broadcast_dest(struct kvm *kvm, struct kvm_lapic **src, > > { > > if (kvm->arch.x2apic_broadcast_quirk_disabled) { > > if ((irq->dest_id == APIC_BROADCAST && > > - map->mode != KVM_APIC_MODE_X2APIC)) > > + map->logical_mode != KVM_APIC_MODE_X2APIC)) > > return true; > > if (irq->dest_id == X2APIC_BROADCAST) > > return true; > > To be honest I would put that patch first, and then do all the other patches, > this way you would avoid all of the hacks they do and removed here. I did it this way so that I could test this patch for correctness. Without the bug fixes in place it's not really possible to verify this patch is 100% correct. I completely agree that it would be a lot easier to read/understand/review if this came first, but I'd rather not sacrifice the ability to easily test this patch.