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 4EAA5C433EF for ; Tue, 16 Nov 2021 16:06:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 371CB613DB for ; Tue, 16 Nov 2021 16:06:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238867AbhKPQJU (ORCPT ); Tue, 16 Nov 2021 11:09:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34138 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238874AbhKPQIH (ORCPT ); Tue, 16 Nov 2021 11:08:07 -0500 Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37739C061746 for ; Tue, 16 Nov 2021 08:05:09 -0800 (PST) Received: by mail-pf1-x42f.google.com with SMTP id i12so1619753pfd.6 for ; Tue, 16 Nov 2021 08:05:09 -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=deqGK3yKMLsBufstVPiHWoHpV0QbG75PNlw5AN12k/U=; b=W6XWgmoOR0nc3wCDhUnBqEhxtHPEjLOcuwSSU01/0n8B4OfWJqNQxd4cX3T6UJbokv ZD6jfaU/4/rF1aOToTIyQBPlqasw/bLjwOfwP6l8f+T6zKYX+SJjhkcq+K48n2KzjLrn evjj4NWZmJ0SGNoouR1m+oUR8ADMImRqHMIvbsrZ6uMXfilheVvC3PsLYdN0MntyZE9l mE4s7hOxVa94PSZGuhuMZDjX8NmhdgalP9B6nJB8SWnqA+NSmo4xn15BUF23cotvKCrq OMweaQEPtBUGfsFAV57qs7IdC5I5UKon307eCVe3n1HXG8iPQCYwi7sL/+ywLt/1YkMB JgIg== 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=deqGK3yKMLsBufstVPiHWoHpV0QbG75PNlw5AN12k/U=; b=WTlqVufyMK1jIgqZMQ9ioaM0H1q28xq1wUp8n2XCmu2i1BSRVRrmYJURfZiQATfETo X2I3FCrPnfAxqJPjQhPcaCxGwu4SASN2PxLxvovHnqQjhBnxXi3J60Oa8FZ/tzxHKYvr fCi3141EMiYlEXRlo8l40wXBUq6uo3QTg94s78ifaPpEZ9wxYhR3qX3OjGfJRe3O9O3x 5Ze8MF1nMDW0k93LSVTxAbzWtHCw3fFyiYMA/ECghYmJgUrP5DZgtBSlf8GzmHhgl9gc Jy28p5RLaDevu0q6bAyj71Io9agJZenjDR7PUcSgVs1TucnayyotRuFK6+MZJpx8Emf6 NAog== X-Gm-Message-State: AOAM531M+6pZp+vBX1E8G5i+Aq2l07sIyrZRc3IGSt1XH1pj+pPx98jb FgaugE9bAQBE9HS0zpnldUpeQg== X-Google-Smtp-Source: ABdhPJyCe4SDrcnQD4hUJWiTClXh0x7fVaPYRsR6Spm56yWJv6UODIw7xs8/6PBtC4BCCx3F+pC3SA== X-Received: by 2002:a63:7e48:: with SMTP id o8mr5491970pgn.157.1637078708619; Tue, 16 Nov 2021 08:05:08 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id np1sm3037810pjb.22.2021.11.16.08.05.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Nov 2021 08:05:08 -0800 (PST) Date: Tue, 16 Nov 2021 16:05:04 +0000 From: Sean Christopherson To: Thomas Gleixner Cc: "Liu, Jing2" , Paolo Bonzini , LKML , "x86@kernel.org" , "kvm@vger.kernel.org" , "Nakajima, Jun" , Dave Hansen , Arjan van de Ven , Jing Liu , "Cooper, Andrew" , "Bae, Chang Seok" Subject: Re: Thoughts of AMX KVM support based on latest kernel Message-ID: References: <87k0h85m65.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k0h85m65.ffs@tglx> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 16, 2021, Thomas Gleixner wrote: > > One of potential drawbacks of the Option 2 might be additional > > checks in the host, although we can minimize the impact by having > > CONFIG_KVM_TBD. We believe that the case > > "XFD != 0 and XINUSE != 0" should be very infrequent. > > I really don't like the idea of having an extra check in switch_to(). > > Can we start simple and do something like the uncompiled below and see > how much overhead it creates? > > Thanks, > > tglx > --- ... > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 2686f2edb47c..9425fdbb4806 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -9576,6 +9576,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) > vcpu->arch.last_vmentry_cpu = vcpu->cpu; > vcpu->arch.last_guest_tsc = kvm_read_l1_tsc(vcpu, rdtsc()); > > + kvm_update_guest_xfd_state(); Is there a reason the XFD switch can't key off TIF_NEED_FPU_LOAD a la the other FPU stuff? I.e. piggyback this snippet in vcpu_enter_guest(): if (test_thread_flag(TIF_NEED_FPU_LOAD)) switch_fpu_return(); > + > vcpu->mode = OUTSIDE_GUEST_MODE; > smp_wmb(); > > >