From: Sean Christopherson <seanjc@google.com>
To: Yu Zhang <yu.c.zhang@linux.intel.com>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com, maz@kernel.org,
james.morse@arm.com, alexandru.elisei@arm.com,
suzuki.poulose@arm.com, oliver.upton@linux.dev,
catalin.marinas@arm.com, will@kernel.org, dwmw2@infradead.org,
paul@xen.org
Subject: Re: [PATCH v3] KVM: MMU: Make the definition of 'INVALID_GPA' common.
Date: Thu, 15 Dec 2022 18:12:05 +0000 [thread overview]
Message-ID: <Y5tjdeMk2jJCX8Co@google.com> (raw)
In-Reply-To: <20221215095736.1202008-1-yu.c.zhang@linux.intel.com>
Nit, terminating punction (the period) isn't usually included in the shortlog.
On Thu, Dec 15, 2022, Yu Zhang wrote:
> KVM already has a 'GPA_INVALID' defined as (~(gpa_t)0) in
> kvm_types.h, and it is used by ARM and X86 xen code. We do
> not need a specific definition of 'INVALID_GPA' for X86.
>
> Instead of using the common 'GPA_INVALID' for X86, replace
> the definition of 'GPA_INVALID' with 'INVALID_GPA', and
> change the users of 'GPA_INVALID', so that the diff can be
> smaller. Also because the name 'INVALID_GPA' tells the user
> we are using an invalid GPA, while the name 'GPA_INVALID'
> is emphasizing the GPA is an invalid one.
>
> Also, add definition of 'INVALID_GFN' because it is more
> proper than 'INVALID_GPA' for GFN variables.
This should be a separate commit. Yes, it's trivial and a nop, but there's no
reason to surprise readers/blamers that assumed the shortlog tells the whole
story. E.g. add and use INVALID_GFN where appropriate in patch 1, then switch
to INVALID_GPA in patch 2. Then you can also add a "Suggested-by: David ..." for
patch 1.
next prev parent reply other threads:[~2022-12-15 18:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-15 9:57 [PATCH v3] KVM: MMU: Make the definition of 'INVALID_GPA' common Yu Zhang
2022-12-15 18:12 ` Sean Christopherson [this message]
2022-12-16 3:03 ` Yu Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y5tjdeMk2jJCX8Co@google.com \
--to=seanjc@google.com \
--cc=alexandru.elisei@arm.com \
--cc=catalin.marinas@arm.com \
--cc=dwmw2@infradead.org \
--cc=james.morse@arm.com \
--cc=kvm@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=paul@xen.org \
--cc=pbonzini@redhat.com \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yu.c.zhang@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.