From: Sebastian Ene <sebastianene@google.com>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: akpm@linux-foundation.org, alexghiti@rivosinc.com,
ankita@nvidia.com, ardb@kernel.org, catalin.marinas@arm.com,
christophe.leroy@csgroup.eu, james.morse@arm.com,
vdonnefort@google.com, mark.rutland@arm.com, maz@kernel.org,
rananta@google.com, ryan.roberts@arm.com, shahuang@redhat.com,
suzuki.poulose@arm.com, will@kernel.org, yuzenghui@huawei.com,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel-team@android.com
Subject: Re: [PATCH v7 5/6] KVM: arm64: Initialize the ptdump parser with stage-2 attributes
Date: Fri, 19 Jul 2024 14:01:15 +0000 [thread overview]
Message-ID: <Zppxq_8OC56HRHfi@google.com> (raw)
In-Reply-To: <Zn8omLmCSIHun1uq@linux.dev>
On Fri, Jun 28, 2024 at 09:18:16PM +0000, Oliver Upton wrote:
> Hi Seb,
>
> On Fri, Jun 21, 2024 at 12:32:29PM +0000, Sebastian Ene wrote:
> > Define a set of attributes used by the ptdump parser to display the
> > properties of a guest memory region covered by a pagetable descriptor.
> > Build a description of the pagetable levels and initialize the parser
> > with this configuration.
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
>
> This patch should come *before* patch 4, no point in exposing the
> debugfs file if we aren't ready to handle it yet.
>
This is true but this patch doesn't make sense without 4 because here I
add a bunch of functions which will not be invoked (they are invoked
from the debugfs calls).
IMO we can squash them (4 and 5) but it will be a bit harder to follow.
Let me know what you think, thanks.
Seb
> > ---
> > arch/arm64/kvm/ptdump.c | 143 ++++++++++++++++++++++++++++++++++++++--
> > 1 file changed, 137 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
> > index 36dc7662729f..cc1d4fdddc6e 100644
> > --- a/arch/arm64/kvm/ptdump.c
> > +++ b/arch/arm64/kvm/ptdump.c
> > @@ -14,6 +14,61 @@
> > #include <kvm_ptdump.h>
> >
> >
> > +#define MARKERS_LEN (2)
> > +#define KVM_PGTABLE_MAX_LEVELS (KVM_PGTABLE_LAST_LEVEL + 1)
> > +
> > +struct kvm_ptdump_guest_state {
> > + struct kvm *kvm;
> > + struct pg_state parser_state;
> > + struct addr_marker ipa_marker[MARKERS_LEN];
> > + struct pg_level level[KVM_PGTABLE_MAX_LEVELS];
> > + struct ptdump_range range[MARKERS_LEN];
> > +};
> > +
> > +static const struct prot_bits stage2_pte_bits[] = {
> > + {
> > + .mask = PTE_VALID,
> > + .val = PTE_VALID,
> > + .set = " ",
> > + .clear = "F",
> > + }, {
> > + .mask = KVM_PTE_LEAF_ATTR_HI_S2_XN | PTE_VALID,
> > + .val = KVM_PTE_LEAF_ATTR_HI_S2_XN | PTE_VALID,
> > + .set = "XN",
> > + .clear = " ",
> > + }, {
> > + .mask = KVM_PTE_LEAF_ATTR_LO_S2_S2AP_R | PTE_VALID,
> > + .val = KVM_PTE_LEAF_ATTR_LO_S2_S2AP_R | PTE_VALID,
> > + .set = "R",
> > + .clear = " ",
> > + }, {
> > + .mask = KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W | PTE_VALID,
> > + .val = KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W | PTE_VALID,
> > + .set = "W",
> > + .clear = " ",
> > + }, {
> > + .mask = KVM_PTE_LEAF_ATTR_LO_S2_AF | PTE_VALID,
> > + .val = KVM_PTE_LEAF_ATTR_LO_S2_AF | PTE_VALID,
> > + .set = "AF",
> > + .clear = " ",
>
> <snip>
>
> > + }, {
> > + .mask = PTE_NG,
> > + .val = PTE_NG,
> > + .set = "FnXS",
> > + .clear = " ",
> > + }, {
> > + .mask = PTE_CONT | PTE_VALID,
> > + .val = PTE_CONT | PTE_VALID,
> > + .set = "CON",
> > + .clear = " ",
> > + }, {
>
> </snip>
>
> Neither of these bits are used at stage-2, why have descriptors for
> them?
>
> > +static int kvm_ptdump_build_levels(struct pg_level *level, u32 start_lvl)
> > +{
> > + static const char * const level_names[] = {"PGD", "PUD", "PMD", "PTE"};
> > + u32 i = 0;
> > + u64 mask = 0;
> > +
> > + if (start_lvl > 2) {
> > + pr_err("invalid start_lvl %u\n", start_lvl);
> > + return -EINVAL;
> > + }
>
> if (WARN_ON_ONCE(start_lvl >= KVM_PGTABLE_LAST_LEVEL))
> return -EINVAL;
>
> > + for (i = 0; i < ARRAY_SIZE(stage2_pte_bits); i++)
> > + mask |= stage2_pte_bits[i].mask;
> > +
> > + for (i = start_lvl; i < KVM_PGTABLE_MAX_LEVELS; i++) {
> > + strscpy(level[i].name, level_names[i], sizeof(level[i].name));
> > +
> > + level[i].num = ARRAY_SIZE(stage2_pte_bits);
> > + level[i].bits = stage2_pte_bits;
> > + level[i].mask = mask;
> > + }
> > +
> > + if (start_lvl > 0)
> > + strscpy(level[start_lvl].name, level_names[0], sizeof(level_names[0]));
>
> This should pass the size of @dst, not the source. This becomes slightly
> more self-documenting if you use a literal for "PGD" here too.
>
> strscpy(level[start_lvl].name, "PGD", sizeof(level[start_lvl].name));
>
> > + return 0;
> > +}
> > +
> > +static struct kvm_ptdump_guest_state
> > +*kvm_ptdump_parser_init(struct kvm *kvm)
> > +{
> > + struct kvm_ptdump_guest_state *st;
> > + struct kvm_s2_mmu *mmu = &kvm->arch.mmu;
> > + struct kvm_pgtable *pgtable = mmu->pgt;
> > + int ret;
> > +
> > + st = kzalloc(sizeof(struct kvm_ptdump_guest_state), GFP_KERNEL_ACCOUNT);
> > + if (!st)
> > + return NULL;
> > +
> > + ret = kvm_ptdump_build_levels(&st->level[0], pgtable->start_level);
> > + if (ret)
> > + goto free_with_state;
>
> I don't see any value in the use of goto here, as there isn't any sort
> of cascading initialization / cleanup. This also presents an opportunity
> to get an error back out to the caller.
>
> if (ret) {
> kfree(st);
> return ERR_PTR(ret);
> }
>
> > @@ -57,22 +176,34 @@ static int kvm_ptdump_guest_show(struct seq_file *m, void *unused)
> > static int kvm_ptdump_guest_open(struct inode *m, struct file *file)
> > {
> > struct kvm *kvm = m->i_private;
> > + struct kvm_ptdump_guest_state *st;
> > int ret;
> >
> > if (!kvm_get_kvm_safe(kvm))
> > return -ENOENT;
> >
> > - ret = single_open(file, kvm_ptdump_guest_show, m->i_private);
> > - if (ret < 0)
> > - kvm_put_kvm(kvm);
> > + st = kvm_ptdump_parser_init(kvm);
> > + if (!st) {
> > + ret = -ENOMEM;
> > + goto free_with_kvm_ref;
> > + }
>
> (with the earlier suggestion)
>
> st = kvm_ptdump_parser_init(kvm);
> if (IS_ERR(st)) {
> ret = PTR_ERR(st);
> goto free_with_kvm_ref;
> }
>
> Otherwise genuine KVM bugs (-EINVAL) are getting lumped into ENOMEM.
>
> --
> Thanks,
> Oliver
next prev parent reply other threads:[~2024-07-19 14:01 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-21 12:32 [PATCH v7 0/6] arm64: ptdump: View the second stage page-tables Sebastian Ene
2024-06-21 12:32 ` [PATCH v7 1/6] KVM: arm64: Move pagetable definitions to common header Sebastian Ene
2024-06-21 12:32 ` [PATCH v7 2/6] arm64: ptdump: Expose the attribute parsing functionality Sebastian Ene
2024-07-05 11:07 ` Will Deacon
2024-07-19 11:44 ` Sebastian Ene
2024-06-21 12:32 ` [PATCH v7 3/6] arm64: ptdump: Use the mask from the state structure Sebastian Ene
2024-07-05 11:12 ` Will Deacon
2024-07-19 13:27 ` Sebastian Ene
2024-06-21 12:32 ` [PATCH v7 4/6] KVM: arm64: Register ptdump with debugfs on guest creation Sebastian Ene
2024-06-21 12:32 ` [PATCH v7 5/6] KVM: arm64: Initialize the ptdump parser with stage-2 attributes Sebastian Ene
2024-06-28 21:18 ` Oliver Upton
2024-07-01 14:17 ` Sebastian Ene
2024-07-08 19:47 ` Oliver Upton
2024-07-19 14:01 ` Sebastian Ene [this message]
2024-07-01 8:42 ` Vincent Donnefort
2024-07-01 14:18 ` Sebastian Ene
2024-07-16 9:59 ` Vincent Donnefort
2024-07-19 14:09 ` Sebastian Ene
2024-07-19 14:36 ` Vincent Donnefort
2024-07-19 16:27 ` Sebastian Ene
2024-06-21 12:32 ` [PATCH v7 6/6] KVM: arm64: Expose guest stage-2 pagetable config to debugfs Sebastian Ene
2024-06-28 20:49 ` Oliver Upton
2024-07-01 14:10 ` Sebastian Ene
2024-06-28 21:25 ` [PATCH v7 0/6] arm64: ptdump: View the second stage page-tables Oliver Upton
2024-07-01 14:22 ` Sebastian Ene
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=Zppxq_8OC56HRHfi@google.com \
--to=sebastianene@google.com \
--cc=akpm@linux-foundation.org \
--cc=alexghiti@rivosinc.com \
--cc=ankita@nvidia.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=james.morse@arm.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=rananta@google.com \
--cc=ryan.roberts@arm.com \
--cc=shahuang@redhat.com \
--cc=suzuki.poulose@arm.com \
--cc=vdonnefort@google.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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.