From: Marc Zyngier <maz@kernel.org>
To: Alexandru Elisei <alexandru.elisei@arm.com>,
linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH 0/2] KVM: arm64: user_mem_abort() improvements
Date: Fri, 4 Sep 2020 11:18:20 +0100 [thread overview]
Message-ID: <159921467170.1081927.3513898210020479477.b4-ty@kernel.org> (raw)
In-Reply-To: <20200901133357.52640-1-alexandru.elisei@arm.com>
On Tue, 1 Sep 2020 14:33:55 +0100, Alexandru Elisei wrote:
> The first patch is a fix for a bug that I found by code inspection.
>
> The second patch is an enhancement for the way user_mem_abort() handles
> hugetlbfs backed VM memory.
>
> Tested on a rockpro64 with 4K pages and hugetlbfs hugepagesz=1G (PUD sized
> block mappings). First test, guest RAM starts at 0x8100 0000
> (memslot->base_gfn not aligned to 1GB); second test, guest RAM starts at
> 0x8000 0000, but is only 512 MB. In both cases using PUD mappings is not
> possible because either the memslot base address is not aligned, or the
> mapping would extend beyond the memslot.
>
> [...]
Applied to next, thanks!
[1/2] KVM: arm64: Update page shift if stage 2 block mapping not supported
commit: 7b75cd5128421c673153efb1236705696a1a9812
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Alexandru Elisei <alexandru.elisei@arm.com>,
linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH 0/2] KVM: arm64: user_mem_abort() improvements
Date: Fri, 4 Sep 2020 11:18:20 +0100 [thread overview]
Message-ID: <159921467170.1081927.3513898210020479477.b4-ty@kernel.org> (raw)
In-Reply-To: <20200901133357.52640-1-alexandru.elisei@arm.com>
On Tue, 1 Sep 2020 14:33:55 +0100, Alexandru Elisei wrote:
> The first patch is a fix for a bug that I found by code inspection.
>
> The second patch is an enhancement for the way user_mem_abort() handles
> hugetlbfs backed VM memory.
>
> Tested on a rockpro64 with 4K pages and hugetlbfs hugepagesz=1G (PUD sized
> block mappings). First test, guest RAM starts at 0x8100 0000
> (memslot->base_gfn not aligned to 1GB); second test, guest RAM starts at
> 0x8000 0000, but is only 512 MB. In both cases using PUD mappings is not
> possible because either the memslot base address is not aligned, or the
> mapping would extend beyond the memslot.
>
> [...]
Applied to next, thanks!
[1/2] KVM: arm64: Update page shift if stage 2 block mapping not supported
commit: 7b75cd5128421c673153efb1236705696a1a9812
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-09-04 10:18 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-01 13:33 [PATCH 0/2] KVM: arm64: user_mem_abort() improvements Alexandru Elisei
2020-09-01 13:33 ` Alexandru Elisei
2020-09-01 13:33 ` [PATCH 1/2] KVM: arm64: Update page shift if stage 2 block mapping not supported Alexandru Elisei
2020-09-01 13:33 ` Alexandru Elisei
2020-09-02 0:57 ` Gavin Shan
2020-09-02 0:57 ` Gavin Shan
2020-09-01 13:33 ` [PATCH 2/2] KVM: arm64: Try PMD block mappings if PUD mappings are " Alexandru Elisei
2020-09-01 13:33 ` Alexandru Elisei
2020-09-02 1:23 ` Gavin Shan
2020-09-02 1:23 ` Gavin Shan
2020-09-02 9:01 ` Alexandru Elisei
2020-09-02 9:01 ` Alexandru Elisei
2020-09-03 0:06 ` Gavin Shan
2020-09-03 0:06 ` Gavin Shan
2020-09-04 9:58 ` Marc Zyngier
2020-09-04 9:58 ` Marc Zyngier
2020-09-08 12:23 ` Alexandru Elisei
2020-09-08 12:23 ` Alexandru Elisei
2020-09-08 12:41 ` Marc Zyngier
2020-09-08 12:41 ` Marc Zyngier
2020-09-04 10:18 ` Marc Zyngier [this message]
2020-09-04 10:18 ` [PATCH 0/2] KVM: arm64: user_mem_abort() improvements Marc Zyngier
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=159921467170.1081927.3513898210020479477.b4-ty@kernel.org \
--to=maz@kernel.org \
--cc=alexandru.elisei@arm.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.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.