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 9F881C433FE for ; Thu, 16 Dec 2021 14:12:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237816AbhLPOM5 (ORCPT ); Thu, 16 Dec 2021 09:12:57 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:54752 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237813AbhLPOMz (ORCPT ); Thu, 16 Dec 2021 09:12:55 -0500 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1639663973; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2wY+CAEJAUwckZ4JP8ztzEAXZBMnZfuK1dsJI9iW3q8=; b=FYg/+/2whs/bC58ZLt166FzhUqUu+5bC/y4ISVw/xulKhKFSLjKETK6KTaqz/cNMNnJlzs fBEnRGgALWUF39NgPbJcgve9h5H4ay1QKNCm4kdXyJXlgTjDCTTdGBtZ8CSPb/Wkb5ZmNh CNspG69mszOwLmVFO5EZre74Y7OT6H8TeZ6vZqfknvhS956zhpOs4fAIH78PxFVGphP9vj 5K+YDLDJ6iVurRHsd0OppkQqHIHEuJ/hUOm7XgT2GrPDmPjWXtWGpMxolEJrKmtH/c+U03 /oFTck1u5bMvu2qvjcjg6KEgi/olf4BfiSyzzKJE592FVsevBrBcoauq9ugH9A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1639663973; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2wY+CAEJAUwckZ4JP8ztzEAXZBMnZfuK1dsJI9iW3q8=; b=RL6Sn1ZH2WSL8SKDU61iH/J8qZ95Lyj7rEAO8+kA6bPcenXQdFiLRmz9BZsZQAFso3XExt Ki4MgZxwcPauviDA== To: "Tian, Kevin" , Paolo Bonzini , "Wang, Wei W" , "quintela@redhat.com" Cc: LKML , "Dr. David Alan Gilbert" , Jing Liu , "Zhong, Yang" , "x86@kernel.org" , "kvm@vger.kernel.org" , "Christopherson,, Sean" , "Nakajima, Jun" , "Zeng, Guang" Subject: RE: [patch 5/6] x86/fpu: Provide fpu_update_guest_xcr0/xfd() In-Reply-To: References: <20211214022825.563892248@linutronix.de> <20211214024948.048572883@linutronix.de> <854480525e7f4f3baeba09ec6a864b80@intel.com> <87zgp3ry8i.ffs@tglx> <87r1afrrjx.ffs@tglx> <87k0g7qa3t.fsf@secure.mitica> <87k0g7rkwj.ffs@tglx> <878rwm7tu8.fsf@secure.mitica> <878rwmrxgb.ffs@tglx> <87fsqslwph.ffs@tglx> Date: Thu, 16 Dec 2021 15:12:53 +0100 Message-ID: <8735msljtm.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 16 2021 at 09:59, Kevin Tian wrote: >> From: Thomas Gleixner >> This can be done simply with the MSR entry/exit controls. No trap >> required neither for #NM for for XFD_ERR. >> >> VMENTER loads guest state. VMEXIT saves guest state and loads host state >> (0) > > This implies three MSR operations for every vm-exit. > > With trap we only need one RDMSR in host #NM handler, one > RDMSR/one WRMSR exit in guest #NM handler, which are both rare. > plus one RDMSR/one WRMSR per vm-exit only if saved xfd_err is > non-zero which is again rare. Fair enough. >> XFD: Always guest state >> >> So VMENTER does nothing and VMEXIT either saves guest state and the sync >> function uses the automatically saved value or you keep the sync >> function which does the rdmsrl() as is. >> > > Yes, this is the 3rd open that I asked in another reply. The only restriction > with this approach is that the sync cost is added also for legacy OS which > doesn't touch xfd at all. You still can make that conditional on the guest XCR0. If guest never enables the extended bit then neither the #NM trap nor the XFD sync are required. But yes, there are too many moving parts here :) Thanks, tglx