Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp1913542ybg; Thu, 30 Jul 2020 06:06:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyfz+N5glt3Y/pWZ+O4g/nx+h8acmGs7/mp8/0jO4CZMe9d6hvaQ1sNH+8fb1z2FXvApowW X-Received: by 2002:a17:906:7787:: with SMTP id s7mr2624477ejm.533.1596114398659; Thu, 30 Jul 2020 06:06:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596114398; cv=none; d=google.com; s=arc-20160816; b=XtcH5ZFdJlyIBqSc1kXQcqyCR1hQ9KqrT5rX9OidvbcQOnn5hsRqZF6IQB8DIXfw0U R1znAB8uXa22pNB004N6c9aUo/kSs+OgAgW8wPn7JdKsI70dJDDO60+DB9vOfMHyPZUQ T9iaW19FOB3Qa5M5/ohjNnoWcI2b/BFKxwqAj/XGDG1HsNqFwc6/BhS7LQM2z75RnSWb oKBtIQ2/Lt4QSdP32ff3LqP4ZoyuQPZrHhBAzmrEGlBIP5t7FiTXL75Wg5p7T1vrOWLh TUs8/BybmF1TlpeAllXkBaGIAEduXbybIZXNh9QrCcoZpeftVTXyNBJJJ+MDrW55ZUlE MnhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=e71Zp5PFul2jWz5/l6tcS4e/UybeWlX/LML8IrN9vKk=; b=GJWhD8rPJaVUaKWm+1MZabDqOJlBaHb6iTjy2F5nMZvqs4ySRgSlYziJa+sqHo7YwL az7t6zXOzA8x41bWBfaiMz+sQeuN7bIoakgW6dh9U25D3tyFowJQOpWDFbSF7DsRUgPd HSlQAKax+aHf2LL+LemCvJdMQYn8Mh9ELzv8NaH2d38BfQSyO8i2etXqLI4mH6dKWGSZ Zbi5Z1X/4x9I58nKMLTTGrwh1vvKs2PhTmRtpa13k1ziBy1eAtcuTijcq1ij24qvzUv2 S7ftoshv8/qgAwcMcPclbuvMrXZ2o2OACHWTOD8FWkNj8zUUt52zpP2CP5ryuWIouL62 CNkg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f20si3053334ejx.474.2020.07.30.06.06.16; Thu, 30 Jul 2020 06:06:38 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728328AbgG3NFe (ORCPT + 99 others); Thu, 30 Jul 2020 09:05:34 -0400 Received: from 8bytes.org ([81.169.241.247]:34040 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726535AbgG3NFe (ORCPT ); Thu, 30 Jul 2020 09:05:34 -0400 Received: by theia.8bytes.org (Postfix, from userid 1000) id F3B893C8; Thu, 30 Jul 2020 15:05:32 +0200 (CEST) Date: Thu, 30 Jul 2020 15:05:31 +0200 From: Joerg Roedel To: Sean Christopherson Cc: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Joerg Roedel Subject: Re: [PATCH 3/4] KVM: SVM: Add GHCB Accessor functions Message-ID: <20200730130531.GC3257@8bytes.org> References: <20200729132234.2346-1-joro@8bytes.org> <20200729132234.2346-4-joro@8bytes.org> <20200729154328.GC27751@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200729154328.GC27751@linux.intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 29, 2020 at 08:43:28AM -0700, Sean Christopherson wrote: > Rather than manually calculate the byte/bit indices just use __set_bit() > and test_bit(). That will also solve the variable declaration issue. > > E.g. > > #define GHB_BITMAP_IDX(field) \ > (offsetof(struct vmcb_save_area, (field)) / sizeof(u64)) > > #define GHCB_SET_VALID(ghcb, field) \ > __set_bit(GHCB_BITMAP_IDX(field), (unsigned long *)&ghcb->save.valid_bitmap) > > Or alternatively drop GHCB_SET_VALID() and just open code the two users. Thanks for your suggestions, I updated the patch and will do some testing before re-posting. Regards, Joerg > > > + } > > + > > +#define DEFINE_GHCB_SETTER(field) \ > > + static inline void \ > > + ghcb_set_##field(struct ghcb *ghcb, u64 value) \ > > + { \ > > + GHCB_SET_VALID(ghcb, field) \ > > + (ghcb)->save.field = value; \ > > > The ghcb doesn't need to be wrapped in (), it's a parameter to a function. > Same comment for the below usage. > > > + } > > + > > +#define DEFINE_GHCB_ACCESSORS(field) \ > > + static inline bool ghcb_is_valid_##field(const struct ghcb *ghcb) \ > > I'd prefer to follow the naming of the arch reg accessors, i.e. > > static inline bool ghcb_##field##_is_valid(...) > > to pair with > > kvm_##lname##_read > kvm_##lname##_write > > And because ghcb_is_valid_rip() reads a bit weird, e.g. IMO is more likely > to be read as "does the RIP in the GHCB hold a valid (canonical) value", > versus ghcb_rip_is_valid() reading as "is RIP valid in the GHCB". > > > + { \ > > + DEFINE_GHCB_INDICES(field) \ > > + return !!((ghcb)->save.valid_bitmap[byte_idx] \ > > + & BIT(bit_idx)); \ > > + } \ > > + \ > > + static inline void \ > > + ghcb_set_##field(struct ghcb *ghcb, u64 value) \ > > + { \ > > + GHCB_SET_VALID(ghcb, field) \ > > + (ghcb)->save.field = value; \ > > > + } > > + > > +DEFINE_GHCB_ACCESSORS(cpl) > > +DEFINE_GHCB_ACCESSORS(rip) > > +DEFINE_GHCB_ACCESSORS(rsp) > > +DEFINE_GHCB_ACCESSORS(rax) > > +DEFINE_GHCB_ACCESSORS(rcx) > > +DEFINE_GHCB_ACCESSORS(rdx) > > +DEFINE_GHCB_ACCESSORS(rbx) > > +DEFINE_GHCB_ACCESSORS(rbp) > > +DEFINE_GHCB_ACCESSORS(rsi) > > +DEFINE_GHCB_ACCESSORS(rdi) > > +DEFINE_GHCB_ACCESSORS(r8) > > +DEFINE_GHCB_ACCESSORS(r9) > > +DEFINE_GHCB_ACCESSORS(r10) > > +DEFINE_GHCB_ACCESSORS(r11) > > +DEFINE_GHCB_ACCESSORS(r12) > > +DEFINE_GHCB_ACCESSORS(r13) > > +DEFINE_GHCB_ACCESSORS(r14) > > +DEFINE_GHCB_ACCESSORS(r15) > > +DEFINE_GHCB_ACCESSORS(sw_exit_code) > > +DEFINE_GHCB_ACCESSORS(sw_exit_info_1) > > +DEFINE_GHCB_ACCESSORS(sw_exit_info_2) > > +DEFINE_GHCB_ACCESSORS(sw_scratch) > > +DEFINE_GHCB_ACCESSORS(xcr0) > > + > > #endif > > -- > > 2.17.1 > >