Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3592166pxj; Mon, 24 May 2021 10:05:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwQefQP8KQt19eZET/UR6er0Auipkm4by8XyH6K8LJ4ftYija8DZU/3dGHSK520lcrteAp5 X-Received: by 2002:a05:6402:35c4:: with SMTP id z4mr26344972edc.362.1621875908604; Mon, 24 May 2021 10:05:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621875908; cv=none; d=google.com; s=arc-20160816; b=lfAaKZT7b3depBYVMOsPG/g5dRM3Yg5tGSwh+uNI3TRj0L7TnOOnki05VFjefDiVJU 9pKuvP9O07/yShIT7B+OCT4DbZxvlGPrjZeW9nEc20aIn3/ohK2cvoHaAlFeMukf7poO JF08wBiGrbJBTQ9XRuE102rdMjMAf+a77QfAmn2Er+5o/ysD1VW+htmxKGDLtiCvass4 5jmisSapCjTIzPpEMXI7TZS99jLsnm0oP7yJnLuaFoq7rzwN5GtfSgu+kL9nWunorvC5 JpEwoWazYZYaEBGnK3DNfzoLUL6iIkOSQCbgZ0Or2QStNyYtvNrhU0gqHI915m53q6Nh 83ew== 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=c6Iy6FMGjuqTNcke/wtyVN9yLyUyNWeFx4AIjoXtdGM=; b=PqZuf+Hk75DtV1OQrEg8na7YskdGNEJEd8tGnW4/84KhCtxoA+VQSGUWzvXFT6zKe/ 757PNbSoje3NyNPOKzaFNukxWeDPaHPoWymCsJkkvfJ0gG9+daAZd1OAbgM/m3BRlms3 at/bXcYH1LUYumR3aLlLgsA0A7UNn0gggCoT9BwYMrwd2y3k7nPfbPIE3u60NYkc4ugy SXrYwddgVtL+IphhyIEchQSQ72b0m4K/5Ez8OQSTmIjhZthc60WpcLcH5YnvrvaPlqBj c3i2jQgv2nL6f8qjKj40UMxpScZ9hu2e/hWU2c60Z6pJdHHLn5Aw736GqrW+ms+DNxPh Y1sQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=mlaxQ74H; 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 y8si11650462edc.269.2021.05.24.10.04.45; Mon, 24 May 2021 10:05:08 -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=mlaxQ74H; 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 S233303AbhEXRFE (ORCPT + 99 others); Mon, 24 May 2021 13:05:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39342 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233280AbhEXRFC (ORCPT ); Mon, 24 May 2021 13:05:02 -0400 Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B72CC061756 for ; Mon, 24 May 2021 10:03:34 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id pi6-20020a17090b1e46b029015cec51d7cdso11481107pjb.5 for ; Mon, 24 May 2021 10:03:34 -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=c6Iy6FMGjuqTNcke/wtyVN9yLyUyNWeFx4AIjoXtdGM=; b=mlaxQ74HN0sNwu+oG2Ld4AqVBNmKroxXRBMuvQZnV4xskZzsABo1JEEDORZVOGfckh M7Zev5Rjx8fkNu6umrXA2eEOY5yHYlGp010dYWIFtFiB1KoHYM8TdzdOIGw8K908g49L MjpVY5yGCw278Opbod19Aqytfdl+XarmBvTC5KSU2uLvg3N9HNkg4ZnnqfpAIMS5y3TW fL76zBcEhZQi5P1xu7CrkGAVbbNvDc3gz4b2ea2DDuHx4KdCjCPo1zOOEfkRJgJ7lKyV BjODbkFhTvb8m9Ou6hskxROp+i61flyfMaK3ROKa+XfShw6UK4C3cWk/8A/sJIp6elyE JAjQ== 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=c6Iy6FMGjuqTNcke/wtyVN9yLyUyNWeFx4AIjoXtdGM=; b=Lyb1FWY5iPLaCpbnP9ZbOqDnaODhQI6xAxvgps/UUeml+1ktZWhRD7OsDBsCz210Gh P3jofyOLcG0WLk2fKKWF8xrlryaXhBBJ2Rj577q0TrFiJ3Lp8eq4ma/+47kSlo7mA/+P J2UrM70BsAW9e7bjPlPsRsuwjm+1LWDF+gkhUOIgCIAVOPieriDH4P29t1HGWaZC5NGw dfz8iI4shlRLGw80p5nRPAMetEkJN5hJOCYbENBMR1Vb1qzDFw2ipmJQjengVt+fTQxO WtItUq5ioW5h0qU2+ainE6Ctt+hrsm82YzggVXrWfyXblmbXfNmT63OwEMzYMui4cNZz xFSQ== X-Gm-Message-State: AOAM530/Yo4wAXZiJTpKim6B3jETCw/aZGzP/CqlvEaQFLVDKMpeKMYl xytBZSzduPvnpl9gvfQIXODE9w== X-Received: by 2002:a17:90a:29c4:: with SMTP id h62mr27052028pjd.177.1621875813567; Mon, 24 May 2021 10:03:33 -0700 (PDT) Received: from google.com (240.111.247.35.bc.googleusercontent.com. [35.247.111.240]) by smtp.gmail.com with ESMTPSA id s65sm10654632pjd.15.2021.05.24.10.03.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 May 2021 10:03:32 -0700 (PDT) Date: Mon, 24 May 2021 17:03:29 +0000 From: Sean Christopherson To: Paolo Bonzini Cc: Tom Lendacky , Vitaly Kuznetsov , Jim Mattson , Joerg Roedel , Wanpeng Li , Borislav Petkov , Ingo Molnar , Thomas Gleixner , Brijesh Singh , Ashish Kalra , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH] KVM: SVM: Assume a 64-bit hypercall for guests with protected state Message-ID: References: <87pmxg73h7.fsf@vitty.brq.redhat.com> <87tums8cn0.fsf@vitty.brq.redhat.com> <211d5285-e209-b9ef-3099-8da646051661@amd.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/05/21 15:58, Tom Lendacky wrote: > > > Would it hurt if we just move 'vcpu->arch.guest_state_protected' check > > > to is_64_bit_mode() itself? It seems to be too easy to miss this > > > peculiar detail about SEV in review if new is_64_bit_mode() users are to > > > be added. > > I thought about that, but wondered if is_64_bit_mode() was to be used in > > other places in the future, if it would be a concern. I think it would be > > safe since anyone adding it to a new section of code is likely to look at > > what that function is doing first. > > > > I'm ok with this. Paolo, I know you already queued this, but would you > > prefer moving the check into is_64_bit_mode()? > > Let's introduce a new wrapper is_64_bit_hypercall, and add a > WARN_ON_ONCE(vcpu->arch.guest_state_protected) to is_64_bit_mode. Can we introduce the WARN(s) in a separate patch, and deploy them much more widely than just is_64_bit_mode()? I would like to have them lying in wait at every path that should be unreachable, e.g. get/set segments, get_cpl(), etc... Side topic, kvm_get_cs_db_l_bits() should be moved to svm.c. Functionally, it's fine to have it as a vendor-agnostic helper, but practically speaking it should never be called directly.