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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0D1ABC433EF for ; Fri, 12 Nov 2021 18:35:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EC73A6103A for ; Fri, 12 Nov 2021 18:35:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235614AbhKLSi3 (ORCPT ); Fri, 12 Nov 2021 13:38:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41320 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235599AbhKLSiY (ORCPT ); Fri, 12 Nov 2021 13:38:24 -0500 Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2B650C0613F5 for ; Fri, 12 Nov 2021 10:35:33 -0800 (PST) Received: by mail-pf1-x42e.google.com with SMTP id m14so9212668pfc.9 for ; Fri, 12 Nov 2021 10:35:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=aRpdsQJUDByg0HBGIuAmTxG9SQVrfVKDPlTbuTeIEko=; b=nfkjBxzgjU7zq1OYl9fbzZhnEzb6x7Y0eXcPAWnNHPZ+LL/N53U5aUJB8TIhXZxOSu xqNh3ZY4x9VHG+rcJ5yZKXueX2GdKWK2nBLclHiiER+pkvIjvVTnrinJNfhv3T7rTxTU T1iUX3jdunqhW2mGhwpswsKH+X2s5z+/5hbhiJ0RKTABHnQvpX+9RdjILEwHg9aOKm/Z sVNf+dmHoGCLb4NQgsWw1VvCd17kJX/9nFLPX5Fp1jUBqbh1YiyBKD1LRqduuM8Ps0SX wsY0Yl/gBFCR4UoQZ22Hmp8whxniu261fjsWie7/Wf9lJgczj0VjU99YmxDsJKkUIm79 mrxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=aRpdsQJUDByg0HBGIuAmTxG9SQVrfVKDPlTbuTeIEko=; b=0f6pqZlii7kCbA5075pjUyQpcfKeY5DZEaCWVF7tExrwoI4je1IpC7UVf5LhuHpHe+ VUnH8PP7ZLrnLOSqihkaICCCQ/m2I/B1c6NggEaU3JH8QfUQQxFn1iNkyGjX/dBkS3dn 45W7JbwIgW7Ix+nnlTcNegK2adiQ+oNki12TVnBk3MjW8Tc36a9JYPfGqCY6pCgyW7Zu wfuSeTTUaZWYADFKQJz04sIkNLcOuUrhic3xPoxGSqZXXstHoe5ZO9rizrwqwUvIS91p 2k/p9fPL4v9jodIZo07M1AIErs0AaD/L+EKcWHXSHQNaFWfxpM5t7Ghx6e/XuB7XUd81 cg0Q== X-Gm-Message-State: AOAM531XLH4jHqZGFUDLDxP/3eyvT0oEw8t6n8CScYPUv1GlRk3KeqRn DB29A+obKEf2qK+erSoT98WQgw== X-Google-Smtp-Source: ABdhPJyv/NLYkBqIpIYH/axU4ys+po0FKfQNRAO7lypMlrU/thyWCU5gg7alRH13F7Msjx1FT5xhDg== X-Received: by 2002:aa7:8e12:0:b0:47b:dcda:658 with SMTP id c18-20020aa78e12000000b0047bdcda0658mr15611860pfr.46.1636742132503; Fri, 12 Nov 2021 10:35:32 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id w24sm5566787pgi.81.2021.11.12.10.35.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Nov 2021 10:35:31 -0800 (PST) Date: Fri, 12 Nov 2021 18:35:28 +0000 From: Sean Christopherson To: Xiaoyao Li Cc: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , erdemaktas@google.com, Connor Kuehl , x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, isaku.yamahata@intel.com, Kai Huang Subject: Re: [PATCH 07/11] KVM: x86: Disable SMM for TDX Message-ID: References: <20211112153733.2767561-1-xiaoyao.li@intel.com> <20211112153733.2767561-8-xiaoyao.li@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 12, 2021, Sean Christopherson wrote: > On Fri, Nov 12, 2021, Xiaoyao Li wrote: > This patch neglects to disallow SMI via IPI. Ditto for INIT+SIPI in the next > patch. And no small part of me thinks we shouldn't even bother handling the > delivery mode in the MSI routing. If we reject MSI configuration, then to be > consistent we should also technically reject guest attempts to configure LVT > entries. Sadly, KVM doesn't handle any of that stuff correctly as there are > assumptions left and right about how the guest will configure things like LVTT, > but from an architctural perspective it is legal to configure LVT0, LVT1, LVTT, > etc... to send SMI, NMI, INIT, etc... > > The kvm_eoi_intercept_disallowed() part is a little different, since KVM can > deliver the interrupt, it just can handle the backend correctly. Dropping an > event on the floor is a bit gross, but on the other hand I really don't want to > sign up for a game of whack-a-mole for all the paths that can get to > __apic_accept_irq(). ... > > static int kvm_vcpu_ioctl_smi(struct kvm_vcpu *vcpu) > > { > > + if (kvm_smm_unsupported(vcpu->kvm)) > > + return -EINVAL; > > + Oh, and despite saying we should "allow" the MSI routing, I do think we should reject this ioctl(). The difference in my mind is that for the ioctl(), it's KVM's "architecture" and we can define it as we see fit, whereas things like APIC delivery mode are x86 architecture and we should do our best to avoid making things up. We're obviously still making up behavior to some extent, but it's at least somewhat aligned with hardware since I believe the architcture just says "undefined behavior" for invalid modes/combinations, and AFAIK configuring invalid/reserved delivery modes will "succeed" in the sense that the CPU won't explode on the write and the APIC won't catch fire.