All of lore.kernel.org
 help / color / mirror / Atom feed
From: <peng.hao2@zte.com.cn>
To: marc.zyngier@arm.com
Cc: cdall@kernel.org, kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re:Re: [PATCH] KVM:arm/arm64: dcache need be coherent unconditionally
Date: Sat, 10 Mar 2018 22:34:48 +0800 (CST)	[thread overview]
Message-ID: <201803102234486300587@zte.com.cn> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 4496 bytes --]

>On Sat, 10 Mar 2018 03:23:18 +0000,
>peng hao wrote:
>> >> For emulation devices just like vga, keeping coherent dcache between
>> >> guest and host timely is needed.
>> >> Now the display of vnc-viewer will not update continuously and the
>> >> patch can fix up.
>> >> 
>> >> Signed-off-by: Peng Hao <peng.hao2@zte.com.cn>
>> >> ---
>> >>  virt/kvm/arm/mmu.c | 6 ++----
>> >>  1 file changed, 2 insertions(+), 4 deletions(-)
>> >> 
>> >> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
>> >> index ec62d1c..4a28395e 100644
>> >> --- a/virt/kvm/arm/mmu.c
>> >> +++ b/virt/kvm/arm/mmu.c
>> >> @@ -1416,8 +1416,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>> >>              kvm_set_pfn_dirty(pfn);
>> >>          }
>> >>  
>> >> -        if (fault_status != FSC_PERM)
>> >> -            clean_dcache_guest_page(pfn, PMD_SIZE);
>> >> +        clean_dcache_guest_page(pfn, PMD_SIZE);
>> >>  
>> >>          if (exec_fault) {
>> >>              new_pmd = kvm_s2pmd_mkexec(new_pmd);
>> >> @@ -1438,8 +1437,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>> >>              mark_page_dirty(kvm, gfn);
>> >>          }
>> >>  
>> >> -        if (fault_status != FSC_PERM)
>> >> -            clean_dcache_guest_page(pfn, PAGE_SIZE);
>> >> +        clean_dcache_guest_page(pfn, PAGE_SIZE);
>> >>  
>> >>          if (exec_fault) {
>> >>              new_pte = kvm_s2pte_mkexec(new_pte);
>> >> 
>> 
>> >I'm sorry, but I have to NAK this.
>> 
>> >You're papering over the fundamental issue that you're accessing a
>> >cacheable alias of a non cacheable memory. The architecture is very
>> >clear about why this doesn't work, and KVM implements the architecture.
>> 
>> 
>> 
>> I find that I just encounter the problem after the commit
>> '15303ba5d1cd9b28d03a980456c0978c0ea3b208 " .

>This should really be a9c0e12ebee5 ("KVM: arm/arm64: Only clean the
>dcache on translation fault").

>> The commit contains "icache invalidation optimizations, improving VM
>> startup time",it changes from unconditionally calling
>> coherent_cache_guest_page(including dcache handle) to conditionally
>> calling clean_dcache_guest_page.
>> 
>> I trace the display of vnc abnormally and find it generate data
>> abort in vga address region with FSC_PERM,and it will not call
>> clean_dcache_guest_page . So I think should recover to uncontionally
>> calling clean_dcache_guest_page.

>[I really hate ranting on a Saturday morning as the sun is finally out
>and I could be relaxing in the garden, but hey, I guess that's the
>fate of a kernel hacker who made the silly mistake of reading email on
>a Saturday morning instead of being out in the garden...]

>Even if you enabled dirty tracking on the VGA memory (and thus making
>it RO to generate a permission fault), you would end-up cleaning to
>the PoC *before* any write has been committed to the page. How useful
>is that? You're also pretty lucky that this does a clean+invalidate
>(rather than a clean which would be good enough), meaning that QEMU
>will in turn miss in the cache (PIPT caches) and read some *stale*
>data from memory.

>Repeat that often enough, and yes, you can get some sort of
>display. Is that the right thing to do? Hell no. You might just as
>well have a userspace process thrashing the cache at the PoC, running
>concurrently with your VM, it would have a similar effect. It may work
>on your particular platform, in some specific conditions, but it just
>doesn't work in general.

>What you are describing is a long standing issue. VGA emulation never
>worked on ARM, because it is fundamentally incompatible with the ARM
>memory architecture. Read the various discussions on the list over the
>past 4 years or so, read the various presentations I and others have
>given about this problem and how to address it[1].

>The *real* fix is a one-liner in the Linux VGA driver: map the VGA
>memory as cacheable, and stop lying to the guest. Or if you want to
>lie to the guest, perform cache maintenance from userspace in QEMU
>based on the dirty tracking bitmap that it uses for the VGA memory.

>Anything else is out of the scope of the architecture, and I'm not
>going to add more crap to satisfy requirements that cannot be
>implemented on real HW, let alone in a virtualized environment.

Thanks for your explanation in detail

>Thanks,

>    M.

>[1] http://events17.linuxfoundation.org/sites/events/files/slides/slides_10.pdf

>-- 
>Jazz is not dead, it just smell funny.

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

WARNING: multiple messages have this Message-ID (diff)
From: peng.hao2@zte.com.cn (peng.hao2 at zte.com.cn)
To: linux-arm-kernel@lists.infradead.org
Subject: Re:Re: [PATCH] KVM:arm/arm64: dcache need be coherent unconditionally
Date: Sat, 10 Mar 2018 22:34:48 +0800 (CST)	[thread overview]
Message-ID: <201803102234486300587@zte.com.cn> (raw)

>On Sat, 10 Mar 2018 03:23:18 +0000,
>peng hao wrote:
>> >> For emulation devices just like vga, keeping coherent dcache between
>> >> guest and host timely is needed.
>> >> Now the display of vnc-viewer will not update continuously and the
>> >> patch can fix up.
>> >> 
>> >> Signed-off-by: Peng Hao <peng.hao2@zte.com.cn>
>> >> ---
>> >>  virt/kvm/arm/mmu.c | 6 ++----
>> >>  1 file changed, 2 insertions(+), 4 deletions(-)
>> >> 
>> >> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
>> >> index ec62d1c..4a28395e 100644
>> >> --- a/virt/kvm/arm/mmu.c
>> >> +++ b/virt/kvm/arm/mmu.c
>> >> @@ -1416,8 +1416,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>> >>              kvm_set_pfn_dirty(pfn);
>> >>          }
>> >>  
>> >> -        if (fault_status != FSC_PERM)
>> >> -            clean_dcache_guest_page(pfn, PMD_SIZE);
>> >> +        clean_dcache_guest_page(pfn, PMD_SIZE);
>> >>  
>> >>          if (exec_fault) {
>> >>              new_pmd = kvm_s2pmd_mkexec(new_pmd);
>> >> @@ -1438,8 +1437,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>> >>              mark_page_dirty(kvm, gfn);
>> >>          }
>> >>  
>> >> -        if (fault_status != FSC_PERM)
>> >> -            clean_dcache_guest_page(pfn, PAGE_SIZE);
>> >> +        clean_dcache_guest_page(pfn, PAGE_SIZE);
>> >>  
>> >>          if (exec_fault) {
>> >>              new_pte = kvm_s2pte_mkexec(new_pte);
>> >> 
>> 
>> >I'm sorry, but I have to NAK this.
>> 
>> >You're papering over the fundamental issue that you're accessing a
>> >cacheable alias of a non cacheable memory. The architecture is very
>> >clear about why this doesn't work, and KVM implements the architecture.
>> 
>> 
>> 
>> I find that I just encounter the problem after the commit
>> '15303ba5d1cd9b28d03a980456c0978c0ea3b208 " .

>This should really be a9c0e12ebee5 ("KVM: arm/arm64: Only clean the
>dcache on translation fault").

>> The commit contains "icache invalidation optimizations, improving VM
>> startup time",it changes from unconditionally calling
>> coherent_cache_guest_page(including dcache handle) to conditionally
>> calling clean_dcache_guest_page.
>> 
>> I trace the display of vnc abnormally and find it generate data
>> abort in vga address region with FSC_PERM,and it will not call
>> clean_dcache_guest_page . So I think should recover to uncontionally
>> calling clean_dcache_guest_page.

>[I really hate ranting on a Saturday morning as the sun is finally out
>and I could be relaxing in the garden, but hey, I guess that's the
>fate of a kernel hacker who made the silly mistake of reading email on
>a Saturday morning instead of being out in the garden...]

>Even if you enabled dirty tracking on the VGA memory (and thus making
>it RO to generate a permission fault), you would end-up cleaning to
>the PoC *before* any write has been committed to the page. How useful
>is that? You're also pretty lucky that this does a clean+invalidate
>(rather than a clean which would be good enough), meaning that QEMU
>will in turn miss in the cache (PIPT caches) and read some *stale*
>data from memory.

>Repeat that often enough, and yes, you can get some sort of
>display. Is that the right thing to do? Hell no. You might just as
>well have a userspace process thrashing the cache at the PoC, running
>concurrently with your VM, it would have a similar effect. It may work
>on your particular platform, in some specific conditions, but it just
>doesn't work in general.

>What you are describing is a long standing issue. VGA emulation never
>worked on ARM, because it is fundamentally incompatible with the ARM
>memory architecture. Read the various discussions on the list over the
>past 4 years or so, read the various presentations I and others have
>given about this problem and how to address it[1].

>The *real* fix is a one-liner in the Linux VGA driver: map the VGA
>memory as cacheable, and stop lying to the guest. Or if you want to
>lie to the guest, perform cache maintenance from userspace in QEMU
>based on the dirty tracking bitmap that it uses for the VGA memory.

>Anything else is out of the scope of the architecture, and I'm not
>going to add more crap to satisfy requirements that cannot be
>implemented on real HW, let alone in a virtualized environment.

Thanks for your explanation in detail

>Thanks,

>    M.

>[1] http://events17.linuxfoundation.org/sites/events/files/slides/slides_10.pdf

>-- 
>Jazz is not dead, it just smell funny.

             reply	other threads:[~2018-03-10 14:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-10 14:34 peng.hao2 [this message]
2018-03-10 14:34 ` Re:Re: [PATCH] KVM:arm/arm64: dcache need be coherent unconditionally peng.hao2 at zte.com.cn

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=201803102234486300587@zte.com.cn \
    --to=peng.hao2@zte.com.cn \
    --cc=cdall@kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.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.