Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3802544pxj; Mon, 24 May 2021 15:30:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxnCxfyq4cR9zNBdlnpK10TCaqTbY24mdxjLPBd+BINyNx4MJ9//TkDzsd05bzo1CgBuE/d X-Received: by 2002:a02:ca0d:: with SMTP id i13mr26075894jak.98.1621895427469; Mon, 24 May 2021 15:30:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621895427; cv=none; d=google.com; s=arc-20160816; b=wvST5FRGrcqfD73s/MMVheS3ZvdMOeN5UEALxSIgr0c99C0fF5gO2DLO4zw2sH0n+I XOSq+0NCuhztWIVWrPpPxy+w+nHZxev8B4UPSxHS1Ol46ahkXxo7v/I6N0fSXW5rutaY ftFZfsFV8Fr5Uqz+xWG21B9EJA1+GUb0kgohP9PEjeE+OxTevWjjFk1QaLhLbZKuF5fw 8Z3Id913EfsDckK1nf2UgFnj+gMHPNCQinBpeilMTdpsDWrasLW0hULlmgFRknIniT+u kzwFyNvHnUi5REiYfbJIEgsOSyvPbWyRRsnJMj5jYpp6t5n/HgMiX/RUp3KveKHNJI0q +Euw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=wjHpPJplladoMyN508+roXM5QX3joM77pztZx4dnUzs=; b=IsdohoqlB9TAwqZQDuKQtZRY8VD6Skq3CqhE6GGK0Vkd2eD9RFfMXagvvq76Kt8rt3 fcHHVq1VtXqFsg/E3wzFRoXqbxfSKZAFLGA55dQO5Xri3MZdpeKLbV2GZnv5l8a+oUQ3 tRofAzgnR8PfvzgflVf7G+7ivr2vVdjscZYq6FD865PhvJ7jP6nvja8DqeTc1ZMof7Ck /Wx14UPk6LiOnysnOh10A59X5kJSQV793Ks4pWtaDH3ZcepEVtRcbL1UvVbzpADMqSfy 0UFlQJ6eqMv2/yr4U78/Qftf65o0AWSQSrcawJw0xFipNvE5qIOMywpZKhn9NusypmA4 42Yw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Vh9c4pDM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w16si14506432ilj.132.2021.05.24.15.30.14; Mon, 24 May 2021 15:30:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Vh9c4pDM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229568AbhEXWaO (ORCPT + 99 others); Mon, 24 May 2021 18:30:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56476 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229539AbhEXWaO (ORCPT ); Mon, 24 May 2021 18:30:14 -0400 Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF4C0C061756 for ; Mon, 24 May 2021 15:28:44 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id h12so3191694plf.11 for ; Mon, 24 May 2021 15:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=wjHpPJplladoMyN508+roXM5QX3joM77pztZx4dnUzs=; b=Vh9c4pDMcMGHrDB/DXKm60YSRnio8FmkVEXBrs70mST+GX+GqtGg7DbzngmZeLYOlF TwnPui9rY6g+IixjZoEWmDWk93pl3ZSH7muk3fn0u/oYcmafAkQopuNDOCq2/2c3Pojj k0SCysDD0W33PzlYFD/w7g8YVnxrccbFHdewjygkBEo2FPzOGp3yzkBD0cmpufPBplk8 kgXTPHhfByDtKazuIeTBKos7tsz5uIUFkMtMygnyCmzDO5cfFeFhiL5g/D0U5wX5uu3A odJzYyursS1h8P1XGBBbX1ifx5CX2zpMxcfMRFZult61SqSolWMpn638LEPINTSPKaQL cj6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=wjHpPJplladoMyN508+roXM5QX3joM77pztZx4dnUzs=; b=fLixVE7DSY6jxeaKsRLqlvzjjyMHr5oDvoL0IWGWP3zixVULAkZx1aTuFcxzHhP/sA kkv5PyXNqc6gwLwWSI/nh1C8eopmjsPNd/lhYvQFYlo5zwx9xLEeenSEPHTUcHFvf5b/ iY5msZUEo/WapdBogkFevsqJzs7XLzX+lr64y18+Y0aBg+OTbRkiiryflbRAg9ahtiWZ K/OKw7q5WlI+F9Co8goGhmLyR09TdOTvA5l3p8kOklhqqw5f1C1c2o9hR/ImOm7eShb0 m7FEpn/4k2NJ72F8RsOv9yoXENQvcT/8M5M2a43FkJX4tnu2NJSCFxvzKdEG2Bdb0reN RmtQ== X-Gm-Message-State: AOAM531zJ0Vgi37ayOB8e9KvQFNFc2X9ovChzqtKFUJ7TQPWICkQ5ypI zzlzwS/hrsT/FPxTUPWGuAeM2A== X-Received: by 2002:a17:902:f545:b029:f5:4b82:9cc9 with SMTP id h5-20020a170902f545b02900f54b829cc9mr27428087plf.68.1621895324070; Mon, 24 May 2021 15:28:44 -0700 (PDT) Received: from google.com (240.111.247.35.bc.googleusercontent.com. [35.247.111.240]) by smtp.gmail.com with ESMTPSA id b23sm2385959pfi.34.2021.05.24.15.28.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 May 2021 15:28:43 -0700 (PDT) Date: Mon, 24 May 2021 22:28:40 +0000 From: Sean Christopherson To: Paolo Bonzini Cc: Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 42/43] KVM: VMX: Drop VMWRITEs to zero fields at vCPU RESET Message-ID: References: <20210424004645.3950558-1-seanjc@google.com> <20210424004645.3950558-43-seanjc@google.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 Mon, May 24, 2021, Paolo Bonzini wrote: > On 24/04/21 02:46, Sean Christopherson wrote: > > Don't waste time writing zeros via VMWRITE during vCPU RESET, the VMCS > > is zero allocated. > > Is this guaranteed to be valid, or could the VMCS in principle use some > weird encoding? (Like it does for the access rights, even though this does > not matter for this patch). Phooey. In principle, the CPU can do whatever it wants, e.g. the SDM states that software should never write to the data portion of the VMCS under any circumstance. In practice, I would be flabbergasted if Intel ever ships a CPU that doesn't play nice with zero initiazing the VMCS via software writes. I'd bet dollars to donuts that KVM isn't the only software that relies on that behavior. That said, I'm not against switching to VMWRITE for everything, but regardless of which route we choose, we should commit to one or the other. I.e. double down on memset() and bet that Intel won't break KVM, or replace the memset() in alloc_vmcs_cpu() with a sequence that writes all known (possible?) fields. The current approach of zeroing the memory in software but initializing _some_ fields is the worst option, e.g. I highly doubt vmcs01 and vmcs02 do VMWRITE(..., 0) on the same fields.