From: Mario Smarduch <m.smarduch@samsung.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>,
KVM devel mailing list <kvm@vger.kernel.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Marc Zyngier <marc.zyngier@arm.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Laszlo Ersek <lersek@redhat.com>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC/RFT PATCH 0/3] arm64: KVM: work around incoherency with uncached guest mappings
Date: Fri, 06 Mar 2015 12:33:01 -0800 [thread overview]
Message-ID: <54FA0EFD.7050306@samsung.com> (raw)
In-Reply-To: <20150304113505.GS28951@e104818-lin.cambridge.arm.com>
On 03/04/2015 03:35 AM, Catalin Marinas wrote:
> (please try to avoid top-posting)
>
> On Mon, Mar 02, 2015 at 06:20:19PM -0800, Mario Smarduch wrote:
>> On 03/02/2015 08:31 AM, Christoffer Dall wrote:
>>> However, my concern with these patches are on two points:
>>>
>>> 1. It's not a fix-all. We still have the case where the guest expects
>>> the behavior of device memory (for strong ordering for example) on a RAM
>>> region, which we now break. Similiarly this doesn't support the
>>> non-coherent DMA to RAM region case.
>>>
>>> 2. While the code is probably as nice as this kind of stuff gets, it
>>> is non-trivial and extremely difficult to debug. The counter-point here
>>> is that we may end up handling other stuff at EL2 for performanc reasons
>>> in the future.
>>>
>>> Mainly because of point 1 above, I am leaning to thinking userspace
>>> should do the invalidation when it knows it needs to, either through KVM
>>> via a memslot flag or through some other syscall mechanism.
>
> I expressed my concerns as well, I'm definitely against merging this
> series.
>
>> I don't understand how can the CPU handle different cache attributes
>> used by QEMU and Guest won't you run into B2.9 checklist? Wouldn't
>> cache evictions or cleans wipe out guest updates to same cache
>> line(s)?
>
> "Clean+invalidate" is a safe operation even if the guest accesses the
> memory in a cacheable way. But if the guest can update the cache lines,
> Qemu should avoid cache maintenance from a performance perspective.
>
> The guest is either told that the DMA is coherent (via DT properties) or
> Qemu deals with (non-)coherency itself. The latter is fully in line with
> the B2.9 chapter in the ARM ARM, more precisely point 5:
>
> If the mismatched attributes for a memory location all assign the same
> shareability attribute to the location, any loss of uniprocessor
> semantics or coherency within a shareability domain can be avoided by
> use of software cache management.
>
> ... it continues with what kind of cache maintenance is required,
> together with:
>
> A clean and invalidate instruction can be used instead of a clean
> instruction, or instead of an invalidate instruction.
>
Hi Catalin,
sorry for the top posting. I'm struggling with QEMU cache
maintenance for devices that don't have registers cache line aligned
and may be multi-function, for lack of a better
one I thought of sp804 that supports two devices with registers
covered by one cache line. Wouldn't QEMU cache maintenance
of one device have potential to corrupt the second device?
These could be used by two guest threads in parallel.
I get bullet 2,3 still working on 1st one it will take a while.
Thanks,
- Mario
next prev parent reply other threads:[~2015-03-06 20:33 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-19 10:54 [RFC/RFT PATCH 0/3] arm64: KVM: work around incoherency with uncached guest mappings Ard Biesheuvel
2015-02-19 10:54 ` [RFC/RFT PATCH 1/3] arm64: KVM: handle some sysreg writes in EL2 Ard Biesheuvel
2015-03-03 17:59 ` Mario Smarduch
2015-02-19 10:54 ` [RFC/RFT PATCH 2/3] arm64: KVM: mangle MAIR register to prevent uncached guest mappings Ard Biesheuvel
2015-02-19 10:54 ` [RFC/RFT PATCH 3/3] arm64: KVM: keep trapping of VM sysreg writes enabled Ard Biesheuvel
2015-02-19 13:40 ` Marc Zyngier
2015-02-19 13:44 ` Ard Biesheuvel
2015-02-19 15:19 ` Marc Zyngier
2015-02-19 15:22 ` Ard Biesheuvel
2015-02-19 14:50 ` [RFC/RFT PATCH 0/3] arm64: KVM: work around incoherency with uncached guest mappings Alexander Graf
2015-02-19 14:56 ` Ard Biesheuvel
2015-02-19 15:27 ` Alexander Graf
2015-02-19 15:31 ` Ard Biesheuvel
2015-02-19 16:57 ` Andrew Jones
2015-02-19 17:19 ` Ard Biesheuvel
2015-02-19 17:55 ` Andrew Jones
2015-02-19 17:57 ` Paolo Bonzini
2015-02-20 14:29 ` Andrew Jones
2015-02-20 14:37 ` Ard Biesheuvel
2015-02-20 15:36 ` Andrew Jones
2015-02-24 14:55 ` Andrew Jones
2015-02-24 17:47 ` Ard Biesheuvel
2015-02-24 19:12 ` Andrew Jones
2015-03-02 16:31 ` Christoffer Dall
2015-03-02 16:47 ` Paolo Bonzini
2015-03-02 16:55 ` Laszlo Ersek
2015-03-02 17:05 ` Andrew Jones
2015-03-02 16:48 ` Andrew Jones
2015-03-03 2:20 ` Mario Smarduch
2015-03-04 11:35 ` Catalin Marinas
2015-03-04 11:50 ` Ard Biesheuvel
2015-03-04 12:29 ` Catalin Marinas
2015-03-04 12:43 ` Ard Biesheuvel
2015-03-04 14:12 ` Andrew Jones
2015-03-04 14:29 ` Catalin Marinas
2015-03-04 14:34 ` Peter Maydell
2015-03-04 17:03 ` Paolo Bonzini
2015-03-04 17:28 ` Catalin Marinas
2015-03-05 10:12 ` Paolo Bonzini
2015-03-05 11:04 ` Catalin Marinas
2015-03-05 11:52 ` Peter Maydell
2015-03-05 12:03 ` Catalin Marinas
2015-03-05 12:26 ` Paolo Bonzini
2015-03-05 14:58 ` Catalin Marinas
2015-03-05 17:43 ` Paolo Bonzini
2015-03-06 21:08 ` Mario Smarduch
2015-03-09 14:26 ` Andrew Jones
2015-03-09 15:33 ` Mario Smarduch
2015-03-05 19:13 ` Ard Biesheuvel
2015-03-06 20:33 ` Mario Smarduch [this message]
2015-02-19 18:44 ` Ard Biesheuvel
2015-03-03 17:34 ` Alexander Graf
2015-03-03 18:13 ` Laszlo Ersek
2015-03-03 20:58 ` Andrew Jones
2015-03-03 18:32 ` Catalin Marinas
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=54FA0EFD.7050306@samsung.com \
--to=m.smarduch@samsung.com \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@linaro.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=lersek@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=marc.zyngier@arm.com \
--cc=pbonzini@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox