Re: [PATCH 3/3] arm, arm64: KVM: handle potential incoherency of readonly memslots

From: Mario Smarduch <m.smarduch@samsung.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	kvmarm@lists.cs.columbia.edu, christoffer.dall@linaro.org,
	marc.zyngier@arm.com, drjones@redhat.com, wei@redhat.com,
	kvm@vger.kernel.org
Subject: Re: [PATCH 3/3] arm, arm64: KVM: handle potential incoherency of readonly memslots
Date: Wed, 19 Nov 2014 15:32:31 -0800	[thread overview]
Message-ID: <546D288F.1040107@samsung.com> (raw)
In-Reply-To: <546A1905.6080607@redhat.com>

Hi Laszlo,

couple observations.

     I'm wondering if access from qemu and guest won't
result in mixed memory attributes and if that's acceptable
to the CPU.

Also is if you update memory from qemu you may break
dirty page logging/migration. Unless there is some other way
you keep track. Of course it may not be applicable in your
case (i.e. flash unused after boot).

- Mario

On 11/17/2014 07:49 AM, Laszlo Ersek wrote:
> On 11/17/14 16:29, Paolo Bonzini wrote:
>>
>>
>> On 17/11/2014 15:58, Ard Biesheuvel wrote:
>>> Readonly memslots are often used to implement emulation of ROMs and
>>> NOR flashes, in which case the guest may legally map these regions as
>>> uncached.
>>> To deal with the incoherency associated with uncached guest mappings,
>>> treat all readonly memslots as incoherent, and ensure that pages that
>>> belong to regions tagged as such are flushed to DRAM before being passed
>>> to the guest.
>>
>> On x86, the processor combines the cacheability values from the two
>> levels of page tables.  Is there no way to do the same on ARM?
> 
> Combining occurs on ARMv8 too. The Stage1 (guest) mapping is very strict
> (Device non-Gathering, non-Reordering, no Early Write Acknowledgement --
> for EFI_MEMORY_UC), which basically "overrides" the Stage2 (very lax
> host) memory attributes.
> 
> When qemu writes, as part of emulating the flash programming commands,
> to the RAMBlock that *otherwise* backs the flash range (as a r/o
> memslot), those writes (from host userspace) tend to end up in dcache.
> 
> But, when the guest flips back the flash to romd mode, and tries to read
> back the values from the flash as plain ROM, the dcache is completely
> bypassed due to the strict stage1 mapping, and the guest goes directly
> to DRAM.
> 
> Where qemu's earlier writes are not yet / necessarily visible.
> 
> Please see my original patch (which was incomplete) in the attachment,
> it has a very verbose commit message.
> 
> Anyway, I'll let others explain; they can word it better than I can :)
> 
> FWIW,
> 
> Series
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
> 
> I ported this series to a 3.17.0+ based kernel, and tested it. It works
> fine. The ROM-like view of the NOR flash now reflects the previously
> programmed contents.
> 
> Series
> Tested-by: Laszlo Ersek <lersek@redhat.com>
> 
> Thanks!
> Laszlo
> 
> 
> 
> _______________________________________________
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
> 