From: James Morse <james.morse@arm.com> To: Marc Zyngier <maz@kernel.org> Cc: "Julien Thierry" <julien.thierry.kdev@gmail.com>, "Suzuki K Poulose" <suzuki.poulose@arm.com>, "James Hogan" <jhogan@kernel.org>, "Paul Mackerras" <paulus@ozlabs.org>, "Paolo Bonzini" <pbonzini@redhat.com>, "Radim Krčmář" <rkrcmar@redhat.com>, "Sean Christopherson" <sean.j.christopherson@intel.com>, "Vitaly Kuznetsov" <vkuznets@redhat.com>, "Wanpeng Li" <wanpengli@tencent.com>, "Jim Mattson" <jmattson@google.com>, "Joerg Roedel" <joro@8bytes.org>, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-mips@vger.kernel.org, kvm-ppc@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH 7/7] KVM: arm/arm64: Elide CMOs when unmapping a range Date: Thu, 19 Dec 2019 13:46:19 +0000 [thread overview] Message-ID: <01c9439f-0de1-78ca-632b-f662876cc4a1@arm.com> (raw) In-Reply-To: <de462fe29fb40fb1644e6a071e6c0c69@www.loen.fr> Hi Marc, On 18/12/2019 15:30, Marc Zyngier wrote: > On 2019-12-18 15:07, James Morse wrote: >> On 13/12/2019 18:25, Marc Zyngier wrote: >>> If userspace issues a munmap() on a set of pages, there is no >>> expectation that the pages are cleaned to the PoC. >>> So let's >>> not do more work than strictly necessary, and set the magic >>> flag that avoids CMOs in this case. >> >> I think this assumes the pages went from anonymous->free, so no-one >> cares about the contents. >> >> If the pages are backed by a file, won't dirty pages will still get >> written back before the page is free? (e.g. EFI flash 'file' mmap()ed in) > > I believe so. Is that a problem? If we skipped the dcache maintenance on unmap, when the the dirty page is later reclaimed the clean+stale lines are written back to the file. File-backed dirty pages will stick around in the page cache in the hope someone else needs them. This would happen for a guest:device-mapping that is written to, but is actually backed by a mmap()d file. I think the EFI flash emulation does exactly this. >> What if this isn't the only mapping of the page? Can't it be swapped >> out from another VMA? (tenuous example, poor man's memory mirroring?) > > Swap-out wouldn't trigger this code path, as it would use a different > MMU notifier event (MMU_NOTIFY_CLEAR vs MMU_NOTIFY_UNMAP), I believe. This was a half thought-through special case of the above. The sequence would be: VM-A and VM-B both share a mapping of $page. 1. VM-A writes to $page through a device mapping 2. The kernel unmaps $page from VM-A for swap. KVM does the maintenance 3. VM-B writes to $page through a device mapping 4. VM-B exits, KVM skips the maintenance, $page may have clean+stale lines 5. Swap finds no further mappings, and writes $page and its clean+stale lines to disk. Two VMs with a shared mapping is the 'easy' example. I think you just need a second mapping for this to happen: it means the page isn't really free after the VM has exited. Thanks, James
prev parent reply other threads:[~2019-12-19 13:46 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-13 18:24 [PATCH 0/7] KVM: arm/arm64: Help VMs dying quicker Marc Zyngier 2019-12-13 18:24 ` [PATCH 1/7] KVM: Pass mmu_notifier_range down to kvm_unmap_hva_range() Marc Zyngier 2019-12-13 18:59 ` Suzuki Kuruppassery Poulose 2019-12-14 10:37 ` Marc Zyngier 2019-12-15 10:27 ` Marc Zyngier 2020-01-15 18:10 ` Paolo Bonzini 2019-12-13 18:24 ` [PATCH 2/7] KVM: arm/arm64: Pass flags along Stage-2 unmapping functions Marc Zyngier 2019-12-13 18:24 ` [PATCH 3/7] KVM: arm/arm64: Condition cache maintenance on unmap with a flag Marc Zyngier 2019-12-13 18:25 ` [PATCH 4/7] KVM: arm/arm64: Condition TLB " Marc Zyngier 2019-12-13 18:25 ` [PATCH 5/7] KVM: arm/arm64: Elide both CMOs and TBLIs on freeing the whole Stage-2 Marc Zyngier 2019-12-13 18:25 ` [PATCH 6/7] KVM: arm/arm64: Elide CMOs when retrying a block mapping Marc Zyngier 2019-12-13 18:25 ` [PATCH 7/7] KVM: arm/arm64: Elide CMOs when unmapping a range Marc Zyngier 2019-12-18 15:07 ` James Morse 2019-12-18 15:30 ` Marc Zyngier 2019-12-19 13:46 ` James Morse [this message]
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=01c9439f-0de1-78ca-632b-f662876cc4a1@arm.com \ --to=james.morse@arm.com \ --cc=jhogan@kernel.org \ --cc=jmattson@google.com \ --cc=joro@8bytes.org \ --cc=julien.thierry.kdev@gmail.com \ --cc=kvm-ppc@vger.kernel.org \ --cc=kvm@vger.kernel.org \ --cc=kvmarm@lists.cs.columbia.edu \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-mips@vger.kernel.org \ --cc=maz@kernel.org \ --cc=paulus@ozlabs.org \ --cc=pbonzini@redhat.com \ --cc=rkrcmar@redhat.com \ --cc=sean.j.christopherson@intel.com \ --cc=suzuki.poulose@arm.com \ --cc=vkuznets@redhat.com \ --cc=wanpengli@tencent.com \ --subject='Re: [PATCH 7/7] KVM: arm/arm64: Elide CMOs when unmapping a range' \ /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
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).