From: Suzuki.Poulose@arm.com (Suzuki K Poulose)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 12/17] kvm-arm: Add explicit hyp page table modifiers
Date: Fri, 8 Apr 2016 16:22:56 +0100 [thread overview]
Message-ID: <5707CCD0.2040606@arm.com> (raw)
In-Reply-To: <5707C997.3030304@arm.com>
On 08/04/16 16:09, Marc Zyngier wrote:
> On 08/04/16 14:15, Christoffer Dall wrote:
>> On Mon, Apr 04, 2016 at 05:26:12PM +0100, Suzuki K Poulose wrote:
>>> We have common routines to modify hyp and stage2 page tables
>>> based on the 'kvm' parameter. For a smoother transition to
>>> using separate routines for each, duplicate the routines
>>> and modify the copy to work on hyp.
>>>
>>> Marks the forked routines with _hyp_ and gets rid of the
>>> kvm parameter which is no longer needed and is NULL for hyp.
>>> Also, gets rid of calls to kvm_tlb_flush_by_vmid_ipa() calls
>>> from the hyp versions. Uses explicit host page table accessors
>>> instead of the kvm_* page table helpers.
>>>
>>> Suggested-by: Christoffer Dall <christoffer.dall@linaro.org>
>>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>> +static void unmap_hyp_ptes(pmd_t *pmd, phys_addr_t addr, phys_addr_t end)
>>> +{
>>> + pte_t *pte, *start_pte;
>>> +
>>> + start_pte = pte = pte_offset_kernel(pmd, addr);
>>> + do {
>>> + if (!pte_none(*pte)) {
>>> + pte_t old_pte = *pte;
>>> +
>>> + kvm_set_pte(pte, __pte(0));
>>> +
>>> + /* XXX: Do we need to invalidate the cache for device mappings ? */
>>
>> no, we will not be swapping out any pages mapped in Hyp mode so you can
>> get rid of both of the following two lines.
OK, will remove this hunk.
>>
>>> + if (!kvm_is_device_pfn(pte_pfn(old_pte)))
>>> + kvm_flush_dcache_pte(old_pte);
>>> +
>>> + put_page(virt_to_page(pte));
>>> + }
>>> + } while (pte++, addr += PAGE_SIZE, addr != end);
>>> +
>>> + if (hyp_pte_table_empty(start_pte))
>>> + clear_hyp_pmd_entry(pmd);
>>> +}
>>> +
>>> +static void unmap_hyp_pmds(pud_t *pud, phys_addr_t addr, phys_addr_t end)
>>> +{
>>> + phys_addr_t next;
>>> + pmd_t *pmd, *start_pmd;
>>> +
>>> + start_pmd = pmd = pmd_offset(pud, addr);
>>> + do {
>>> + next = pmd_addr_end(addr, end);
>>> + if (!pmd_none(*pmd)) {
>>> + if (pmd_thp_or_huge(*pmd)) {
>>
>> do we ever actually map anything with section mappings in the Hyp
>> mappings?
>
> No, this is purely a page mapping so far. On my system, the HYP text is
> just over 4 pages big (4k pages), so the incentive is pretty low, unless
> we can demonstrate some big gains due to the reduced TLB impact.
>>> +static void unmap_hyp_puds(pgd_t *pgd, phys_addr_t addr, phys_addr_t end)
>>> +{
>>> + phys_addr_t next;
>>> + pud_t *pud, *start_pud;
>>> +
>>> + start_pud = pud = pud_offset(pgd, addr);
>>> + do {
>>> + next = pud_addr_end(addr, end);
>>> + if (!pud_none(*pud)) {
>>> + if (pud_huge(*pud)) {
>>
>> do we ever actually map anything with huge pud
>> mappings for the Hyp space?
>
> Same thing. Looks like there is some potential simplification here.
Right, we don't map anything with section mapping. I can clean these up.
>>> +static void unmap_hyp_range(pgd_t *pgdp, phys_addr_t start, u64 size)
>>> +{
>>> + pgd_t *pgd;
>>> + phys_addr_t addr = start, end = start + size;
>>> + phys_addr_t next;
>>> +
>>> + pgd = pgdp + pgd_index(addr);
>>> + do {
>>> + next = pgd_addr_end(addr, end);
>>> + if (!pgd_none(*pgd))
>>> + unmap_hyp_puds(pgd, addr, next);
>>> + } while (pgd++, addr = next, addr != end);
>>
>> shouldn't we flush the EL2 (hyp) TLB here, strictly speaking?
>>
>> Or do we rely on all mappings ever created/torn down here to always have
>> the same VA/PA relationship? Since we didn't flush the EL2 TLB in the
>> existing code, that indeed does seem to be the case.
>
> Actually, we never unmap anything from HYP.
Except for the kvm tearing down where we clean up all the hyp table.
> Once a structure (kvm, vcpu)is mapped there, it stays forever, whatever happens
> to the VM (that's because we'd otherwise have to refcount the number of objects in a page,
> and I'm lazy...).
Thats one of my TODO list if there is sufficient interest in getting that done.
Thanks
Suzuki
next prev parent reply other threads:[~2016-04-08 15:22 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-04 16:26 [PATCH 00/17] kvm-arm: Add stage2 page table walker Suzuki K Poulose
2016-04-04 16:26 ` [PATCH 01/17] arm64: Reuse TCR field definitions for EL1 and EL2 Suzuki K Poulose
2016-04-08 12:43 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 02/17] arm64: Cleanup VTCR_EL2 and VTTBR field values Suzuki K Poulose
2016-04-08 12:43 ` Christoffer Dall
2016-04-08 12:45 ` Suzuki K Poulose
2016-04-04 16:26 ` [PATCH 03/17] kvm arm: Move fake PGD handling to arch specific files Suzuki K Poulose
2016-04-04 16:26 ` [PATCH 04/17] arm64: Introduce pmd_thp_or_huge Suzuki K Poulose
2016-04-08 12:43 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 05/17] kvm-arm: Replace kvm_pmd_huge with pmd_thp_or_huge Suzuki K Poulose
2016-04-08 12:43 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 06/17] kvm-arm: Remove kvm_pud_huge() Suzuki K Poulose
2016-04-08 12:44 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 07/17] kvm-arm: arm32: Introduce stage2 page table helpers Suzuki K Poulose
2016-04-08 12:43 ` Christoffer Dall
2016-04-08 14:39 ` Suzuki K Poulose
2016-04-04 16:26 ` [PATCH 08/17] kvm-arm: arm: Introduce hyp page table empty checks Suzuki K Poulose
2016-04-08 13:15 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 09/17] kvm-arm: arm64: Introduce stage2 page table helpers Suzuki K Poulose
2016-04-08 13:15 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 10/17] kvm-arm: arm64: Introduce hyp page table empty checks Suzuki K Poulose
2016-04-08 13:15 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 11/17] kvm-arm: Use explicit stage2 helper routines Suzuki K Poulose
2016-04-08 13:16 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 12/17] kvm-arm: Add explicit hyp page table modifiers Suzuki K Poulose
2016-04-08 13:15 ` Christoffer Dall
2016-04-08 15:09 ` Marc Zyngier
2016-04-08 15:16 ` Christoffer Dall
2016-04-08 15:22 ` Marc Zyngier
2016-04-08 15:22 ` Suzuki K Poulose [this message]
2016-04-08 15:25 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 13/17] kvm-arm: Add stage2 " Suzuki K Poulose
2016-04-08 13:42 ` Christoffer Dall
2016-04-08 15:37 ` Suzuki K Poulose
2016-04-08 17:03 ` Christoffer Dall
2016-04-08 17:07 ` Suzuki K Poulose
2016-04-08 17:25 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 14/17] kvm-arm: Cleanup kvm_* wrappers Suzuki K Poulose
2016-04-08 15:05 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 15/17] kvm: arm64: Get rid of fake page table levels Suzuki K Poulose
2016-04-08 15:05 ` Christoffer Dall
2016-04-11 14:33 ` Suzuki K Poulose
2016-04-12 12:14 ` Christoffer Dall
2016-04-12 13:03 ` Suzuki K Poulose
2016-04-12 13:11 ` Christoffer Dall
2016-04-13 17:49 ` Suzuki K Poulose
2016-04-14 12:18 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 16/17] kvm-arm: Cleanup stage2 pgd handling Suzuki K Poulose
2016-04-08 15:08 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 17/17] arm64: kvm: Add support for 16K pages Suzuki K Poulose
2016-04-08 15:13 ` Christoffer Dall
2016-04-08 15:15 ` [PATCH 00/17] kvm-arm: Add stage2 page table walker Christoffer Dall
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=5707CCD0.2040606@arm.com \
--to=suzuki.poulose@arm.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).