From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] arm64: KVM: honor cacheability attributes on S2 page fault
Date: Wed, 11 Sep 2013 12:38:55 -0700 [thread overview]
Message-ID: <20130911193855.GN9860@cbox> (raw)
In-Reply-To: <523063AC.8040803@arm.com>
On Wed, Sep 11, 2013 at 01:35:56PM +0100, Marc Zyngier wrote:
> On 11/09/13 13:21, Anup Patel wrote:
> > On Tue, Sep 10, 2013 at 3:21 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> >> Anup Patel recently brought up the fact that when we run a guest
> >> with cache disabled, we don't flush the cache to the Point of
> >> Coherency, hence possibly missing bits of data that have been
> >> written in the cache, but have not reached memory.
> >>
> >> There are several approaches to this issue:
> >> - Using the DC bit when caches are off: this breaks guests assuming
> >> caches off while doing DMA operations. Bootloaders, for example.
> >> - Fetch the memory attributes on translation fault, and flush the
> >> cache while handling the fault. This relies on using the PAR_EL1
> >> register to obtain the Stage-1 memory attributes.
> >>
> >> While this second solution is clearly not ideal (it duplicates what
> >> the HW already does to generate HPFAR_EL2), it is more correct than
> >> not doing anything.
> >>
> >> Cc: Anup Patel <anup@brainfault.org>
> >> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> >> ---
> >>
> >> arch/arm/include/asm/kvm_mmu.h | 4 ++--
> >> arch/arm/kvm/mmu.c | 2 +-
> >> arch/arm64/include/asm/kvm_host.h | 1 +
> >> arch/arm64/include/asm/kvm_mmu.h | 9 +++++++--
> >> arch/arm64/kernel/asm-offsets.c | 1 +
> >> arch/arm64/kvm/hyp.S | 28 ++++++++++++----------------
> >> 6 files changed, 24 insertions(+), 21 deletions(-)
> >>
> >> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
> >> index 472ac70..faffdf0 100644
> >> --- a/arch/arm/include/asm/kvm_mmu.h
> >> +++ b/arch/arm/include/asm/kvm_mmu.h
> >> @@ -105,7 +105,7 @@ static inline void kvm_set_s2pte_writable(pte_t *pte)
> >>
> >> struct kvm;
> >>
> >> -static inline void coherent_icache_guest_page(struct kvm *kvm, gfn_t gfn)
> >> +static inline void coherent_icache_guest_page(struct kvm_vcpu *vcpu, gfn_t gfn)
> >> {
> >> /*
> >> * If we are going to insert an instruction page and the icache is
> >> @@ -120,7 +120,7 @@ static inline void coherent_icache_guest_page(struct kvm *kvm, gfn_t gfn)
> >> * need any kind of flushing (DDI 0406C.b - Page B3-1392).
> >> */
> >> if (icache_is_pipt()) {
> >> - unsigned long hva = gfn_to_hva(kvm, gfn);
> >> + unsigned long hva = gfn_to_hva(vcpu->kvm, gfn);
> >> __cpuc_coherent_user_range(hva, hva + PAGE_SIZE);
> >> } else if (!icache_is_vivt_asid_tagged()) {
> >> /* any kind of VIPT cache */
> >> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> >> index 0988d9e..ffb3cc4 100644
> >> --- a/arch/arm/kvm/mmu.c
> >> +++ b/arch/arm/kvm/mmu.c
> >> @@ -547,7 +547,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >> return -EFAULT;
> >>
> >> new_pte = pfn_pte(pfn, PAGE_S2);
> >> - coherent_icache_guest_page(vcpu->kvm, gfn);
> >> + coherent_icache_guest_page(vcpu, gfn);
> >>
> >> spin_lock(&vcpu->kvm->mmu_lock);
> >> if (mmu_notifier_retry(vcpu->kvm, mmu_seq))
> >> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> >> index 331a852..2530f92 100644
> >> --- a/arch/arm64/include/asm/kvm_host.h
> >> +++ b/arch/arm64/include/asm/kvm_host.h
> >> @@ -79,6 +79,7 @@ struct kvm_mmu_memory_cache {
> >> struct kvm_vcpu_fault_info {
> >> u32 esr_el2; /* Hyp Syndrom Register */
> >> u64 far_el2; /* Hyp Fault Address Register */
> >> + u64 par_el2; /* Result of FAR_EL2 translation */
> >
> > Please rename this to par_el1 because we are saving result of Stage1
> > translation only.
>
> That'd be very confusing, as we deal with PAR_EL1 separately, as part of
> the guest context.
>
> If anything, I may rename it to "what_I_d_love_HPFAR_to_return" instead.
>
while extremely clear, it may be a bit verbose ;)
I honestly think that 'making up' a register name is a bit confusing as
well. I can live with it, but perhaps fault_ipa, or s1_fault_attr or
something like that would work. Eh.
-Christoffer
next prev parent reply other threads:[~2013-09-11 19:38 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-10 9:51 [RFC PATCH] arm64: KVM: honor cacheability attributes on S2 page fault Marc Zyngier
2013-09-11 12:21 ` Anup Patel
2013-09-11 12:35 ` Marc Zyngier
2013-09-11 19:38 ` Christoffer Dall [this message]
2013-10-10 4:51 ` Anup Patel
2013-10-10 8:39 ` Marc Zyngier
2013-10-10 11:24 ` Catalin Marinas
2013-10-10 16:09 ` Anup Patel
2013-10-11 12:38 ` Catalin Marinas
2013-10-11 14:27 ` Anup Patel
2013-10-11 14:37 ` Catalin Marinas
2013-10-11 14:50 ` Anup Patel
2013-10-11 14:59 ` Marc Zyngier
2013-10-11 15:32 ` Anup Patel
2013-10-11 15:44 ` Catalin Marinas
2013-10-12 18:24 ` Anup Patel
2013-10-15 14:38 ` Catalin Marinas
2013-10-17 4:19 ` Anup Patel
2013-10-17 11:16 ` Catalin Marinas
2013-10-19 14:45 ` Christoffer Dall
2013-10-20 9:06 ` Catalin Marinas
2013-09-11 18:06 ` Peter Maydell
2013-09-11 19:25 ` 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=20130911193855.GN9860@cbox \
--to=christoffer.dall@linaro.org \
--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).