All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Donnefort <vdonnefort@google.com>
To: Kalesh Singh <kaleshsingh@google.com>
Cc: maz@kernel.org, oliver.upton@linux.dev, kvmarm@lists.linux.dev,
	qperret@google.com, smostafa@google.com,
	linux-arm-kernel@lists.infradead.org, kernel-team@android.com,
	will@kernel.org
Subject: Re: [PATCH v2] KVM: arm64: Remove size-order align in the nVHE hyp private VA range
Date: Mon, 14 Aug 2023 08:40:01 +0100	[thread overview]
Message-ID: <ZNnaUV7d4XhjflAr@google.com> (raw)
In-Reply-To: <CAC_TJvcwWRSs-YcP-_awLn2VU9m-AT8HzSq+aKHvSPkpRw5=OA@mail.gmail.com>

[...]

> > +int create_hyp_stack(phys_addr_t phys_addr, unsigned long *haddr)
> > +{
> > +       unsigned long base;
> > +       size_t size;
> > +       int ret;
> > +
> > +       mutex_lock(&kvm_hyp_pgd_mutex);
> > +       /*
> > +        * Efficient stack verification using the PAGE_SHIFT bit implies
> > +        * an alignment of our allocation on the order of the size.
> > +        */
> > +       size = PAGE_SIZE * 2;
> > +       base = ALIGN_DOWN(io_map_base - size, size);
> > +
> > +       ret = __hyp_alloc_private_va_range(base);
> > +
> > +       mutex_unlock(&kvm_hyp_pgd_mutex);
> > +
> > +       if (ret) {
> > +               kvm_err("Cannot allocate hyp stack guard page\n");
> > +               return ret;
> > +       }
> > +
> > +       /*
> > +        * Since the stack grows downwards, map the stack to the page
> > +        * at the higher address and leave the lower guard page
> > +        * unbacked.
> > +        *
> > +        * Any valid stack address now has the PAGE_SHIFT bit as 1
> > +        * and addresses corresponding to the guard page have the
> > +        * PAGE_SHIFT bit as 0 - this is used for overflow detection.
> > +        */
> > +       ret = __create_hyp_mappings(base + PAGE_SIZE, PAGE_SIZE, phys_addr,
> > +                                   PAGE_HYP);
> > +       if (ret)
> > +               kvm_err("Cannot map hyp stack\n");
> 
> Should we reset the io_map_base if the mapping failed here as well?

I didn't do it on purpose. Here, I'm releasing the lock and I didn't want to add
a non locked __create_hyp_mappings() just for that reset that is probably not
binging much.

> 
> Otherwise lgtm, Reviewed-by: Kalesh Singh <kaleshsingh@google.com>

Thanks for the review!

> 
> Thanks,
> Kalesh
> 
> > +
> > +       *haddr = base + size;
> > +
> > +       return ret;
> > +}
> > +
> >  /**
> >   * create_hyp_io_mappings - Map IO into both kernel and HYP
> >   * @phys_addr: The physical start address which gets mapped
> >
> > base-commit: 52a93d39b17dc7eb98b6aa3edb93943248e03b2f
> > --
> > 2.41.0.640.ga95def55d0-goog
> >

WARNING: multiple messages have this Message-ID (diff)
From: Vincent Donnefort <vdonnefort@google.com>
To: Kalesh Singh <kaleshsingh@google.com>
Cc: maz@kernel.org, oliver.upton@linux.dev, kvmarm@lists.linux.dev,
	qperret@google.com, smostafa@google.com,
	linux-arm-kernel@lists.infradead.org, kernel-team@android.com,
	will@kernel.org
Subject: Re: [PATCH v2] KVM: arm64: Remove size-order align in the nVHE hyp private VA range
Date: Mon, 14 Aug 2023 08:40:01 +0100	[thread overview]
Message-ID: <ZNnaUV7d4XhjflAr@google.com> (raw)
In-Reply-To: <CAC_TJvcwWRSs-YcP-_awLn2VU9m-AT8HzSq+aKHvSPkpRw5=OA@mail.gmail.com>

[...]

> > +int create_hyp_stack(phys_addr_t phys_addr, unsigned long *haddr)
> > +{
> > +       unsigned long base;
> > +       size_t size;
> > +       int ret;
> > +
> > +       mutex_lock(&kvm_hyp_pgd_mutex);
> > +       /*
> > +        * Efficient stack verification using the PAGE_SHIFT bit implies
> > +        * an alignment of our allocation on the order of the size.
> > +        */
> > +       size = PAGE_SIZE * 2;
> > +       base = ALIGN_DOWN(io_map_base - size, size);
> > +
> > +       ret = __hyp_alloc_private_va_range(base);
> > +
> > +       mutex_unlock(&kvm_hyp_pgd_mutex);
> > +
> > +       if (ret) {
> > +               kvm_err("Cannot allocate hyp stack guard page\n");
> > +               return ret;
> > +       }
> > +
> > +       /*
> > +        * Since the stack grows downwards, map the stack to the page
> > +        * at the higher address and leave the lower guard page
> > +        * unbacked.
> > +        *
> > +        * Any valid stack address now has the PAGE_SHIFT bit as 1
> > +        * and addresses corresponding to the guard page have the
> > +        * PAGE_SHIFT bit as 0 - this is used for overflow detection.
> > +        */
> > +       ret = __create_hyp_mappings(base + PAGE_SIZE, PAGE_SIZE, phys_addr,
> > +                                   PAGE_HYP);
> > +       if (ret)
> > +               kvm_err("Cannot map hyp stack\n");
> 
> Should we reset the io_map_base if the mapping failed here as well?

I didn't do it on purpose. Here, I'm releasing the lock and I didn't want to add
a non locked __create_hyp_mappings() just for that reset that is probably not
binging much.

> 
> Otherwise lgtm, Reviewed-by: Kalesh Singh <kaleshsingh@google.com>

Thanks for the review!

> 
> Thanks,
> Kalesh
> 
> > +
> > +       *haddr = base + size;
> > +
> > +       return ret;
> > +}
> > +
> >  /**
> >   * create_hyp_io_mappings - Map IO into both kernel and HYP
> >   * @phys_addr: The physical start address which gets mapped
> >
> > base-commit: 52a93d39b17dc7eb98b6aa3edb93943248e03b2f
> > --
> > 2.41.0.640.ga95def55d0-goog
> >

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-08-14  7:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20230828121652eucas1p11cc5921bd55c7e90f83d1938a358237f@eucas1p1.samsung.com>
2023-08-11 11:20 ` [PATCH v2] KVM: arm64: Remove size-order align in the nVHE hyp private VA range Vincent Donnefort
2023-08-11 11:20   ` Vincent Donnefort
2023-08-11 21:55   ` Kalesh Singh
2023-08-11 21:55     ` Kalesh Singh
2023-08-14  7:40     ` Vincent Donnefort [this message]
2023-08-14  7:40       ` Vincent Donnefort
2023-08-26 11:00     ` Marc Zyngier
2023-08-26 11:00       ` Marc Zyngier
2023-08-26 13:02   ` Marc Zyngier
2023-08-26 13:02     ` Marc Zyngier
2023-08-28 12:16   ` Marek Szyprowski
2023-08-28 12:16     ` Marek Szyprowski
2023-08-28 13:19     ` Marc Zyngier
2023-08-28 13:19       ` Marc Zyngier
2023-08-28 13:43       ` Marek Szyprowski
2023-08-28 13:43         ` Marek Szyprowski

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=ZNnaUV7d4XhjflAr@google.com \
    --to=vdonnefort@google.com \
    --cc=kaleshsingh@google.com \
    --cc=kernel-team@android.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=qperret@google.com \
    --cc=smostafa@google.com \
    --cc=will@kernel.org \
    /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.