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 X-Spam-Level: X-Spam-Status: No, score=-8.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D3D03C47096 for ; Thu, 3 Jun 2021 17:31:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BAD47613AD for ; Thu, 3 Jun 2021 17:31:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230383AbhFCRdX (ORCPT ); Thu, 3 Jun 2021 13:33:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:57112 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229982AbhFCRdW (ORCPT ); Thu, 3 Jun 2021 13:33:22 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 14028600EF; Thu, 3 Jun 2021 17:31:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1622741497; bh=CYn3EZTKJSh4MDX20btEjoQc2gajFSLKSEiCLpjOtyY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=UAfQrL/7OJGOkvO3MmOhUAvtCeD/mHVyyYbGmRCp6YswxdYsZq38j7rp2gh0G4bhW L98RJBLj9EVzi9azrc/Av2CuAvjOzYOtDhxzLz819aT/E3Wm/eBofItZHJb+he3jFe gMhfZD35ABXCWbxTpPJMR4U3aAkVMD3MMzM9724UXggGSCuSLk95MHApGY0Vrnq435 /Ql2LfZn30+bGoyfvo7j9QMIrgh83CLd7NlfSlJQORtxTenr6qxgIoe3eK8FcA/f0f WvyPBLVV1JHqbQ0MGwJOd3CStKpYjqJOFOiOhGphNIJ8I8AErF1fedToDDc5a7AOi3 wPMrxiTypLfQQ== Subject: Re: [PATCH] x86/cpufeatures: Force disable X86_FEATURE_ENQCMD and remove update_pasid() To: "Luck, Tony" , Thomas Gleixner , Borislav Petkov Cc: "Yu, Fenghua" , linux-kernel , x86 , "iommu@lists.linux-foundation.org" , Ingo Molnar , H Peter Anvin , Jean-Philippe Brucker , Christoph Hellwig , Peter Zijlstra , David Woodhouse , Lu Baolu , "Hansen, Dave" , Randy Dunlap , "Raj, Ashok" , "Pan, Jacob jun" , "Jiang, Dave" , "Mehta, Sohil" , "Shankar, Ravi V" References: <1600187413-163670-1-git-send-email-fenghua.yu@intel.com> <1600187413-163670-10-git-send-email-fenghua.yu@intel.com> <87mtsd6gr9.ffs@nanos.tec.linutronix.de> <87y2bv438p.ffs@nanos.tec.linutronix.de> <36866b38ec92425b879881a88acf547b@intel.com> From: Andy Lutomirski Message-ID: Date: Thu, 3 Jun 2021 10:31:36 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <36866b38ec92425b879881a88acf547b@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/2/21 1:37 PM, Luck, Tony wrote: >>> ... so on a PASID system, your trivial reproducer would theoretically >>> fire the same way and corrupt FPU state just as well. >> >> This is worse and you can't selftest it because the IPI can just hit in >> the middle of _any_ FPU state operation and corrupt state. > > That sounds like we should abandon the "IPI all the other threads > to force enable the PASID for them" approach. It would just be a > nightmare of papering over cracks when the IPI was delivered at > some inconvenient moment when the recipient was in the middle > of touching xsave state. > > I've told Fenghua to dig out the previous iteration of this patch where > the plan was to lazily fix the PASID_MSR in other threads in the #GP > handler. Blech. Also this won't work for other PASID-like features. I have a half-written patch to fix this up for real. Stay tuned. > Seems like a better direction than trying to fix the IPI method. The virtualization > folks will like this way more because IPI in guest causes a couple of VMEXIT > so is somewhat expensive. It happens at most once per PASID-using process.