| Message ID | 1418124368-28418-3-git-send-email-christoffer.dall@linaro.org |
|---|---|
| State | Accepted |
| Commit | 07a9748c78cfc39b54f06125a216b67b9c8f09ed |
| Headers | show |
On 9 December 2014 at 12:26, Christoffer Dall <christoffer.dall@linaro.org> wrote: > From: Ard Biesheuvel <ard.biesheuvel@linaro.org> > > Instead of using kvm_is_mmio_pfn() to decide whether a host region > should be stage 2 mapped with device attributes, add a new static > function kvm_is_device_pfn() that disregards RAM pages with the > reserved bit set, as those should usually not be mapped as device > memory. > > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> As I mentioned last week, this patch (and the next one) are already in 3.18 so unless there is some policy I am unaware of, these do not have to be submitted again.
On Tue, Dec 09, 2014 at 01:29:52PM +0100, Ard Biesheuvel wrote: > On 9 December 2014 at 12:26, Christoffer Dall > <christoffer.dall@linaro.org> wrote: > > From: Ard Biesheuvel <ard.biesheuvel@linaro.org> > > > > Instead of using kvm_is_mmio_pfn() to decide whether a host region > > should be stage 2 mapped with device attributes, add a new static > > function kvm_is_device_pfn() that disregards RAM pages with the > > reserved bit set, as those should usually not be mapped as device > > memory. > > > > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > > Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> > > As I mentioned last week, this patch (and the next one) are already in > 3.18 so unless there is some policy I am unaware of, these do not have > to be submitted again. > They're in kvmarm/next, which is a stable branch (doesn't rebase) so our only choice would be to revert this commit specifically in kvmarm/next before sending the pull request. Since that would be more confusing than help anything, and Paolo said to just include the duplicate commit in the pull request, here it is. As we can see in linux-next, it's not really a problem. -Christoffer
On 9 December 2014 at 13:38, Christoffer Dall <christoffer.dall@linaro.org> wrote: > On Tue, Dec 09, 2014 at 01:29:52PM +0100, Ard Biesheuvel wrote: >> On 9 December 2014 at 12:26, Christoffer Dall >> <christoffer.dall@linaro.org> wrote: >> > From: Ard Biesheuvel <ard.biesheuvel@linaro.org> >> > >> > Instead of using kvm_is_mmio_pfn() to decide whether a host region >> > should be stage 2 mapped with device attributes, add a new static >> > function kvm_is_device_pfn() that disregards RAM pages with the >> > reserved bit set, as those should usually not be mapped as device >> > memory. >> > >> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> >> > Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> >> >> As I mentioned last week, this patch (and the next one) are already in >> 3.18 so unless there is some policy I am unaware of, these do not have >> to be submitted again. >> > They're in kvmarm/next, which is a stable branch (doesn't rebase) so our > only choice would be to revert this commit specifically in kvmarm/next > before sending the pull request. Since that would be more confusing > than help anything, and Paolo said to just include the duplicate commit > in the pull request, here it is. > > As we can see in linux-next, it's not really a problem. > OK, thanks for the explanation.
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c index 57a403a..b007438 100644 --- a/arch/arm/kvm/mmu.c +++ b/arch/arm/kvm/mmu.c @@ -834,6 +834,11 @@ static bool kvm_is_write_fault(struct kvm_vcpu *vcpu) return kvm_vcpu_dabt_iswrite(vcpu); } +static bool kvm_is_device_pfn(unsigned long pfn) +{ + return !pfn_valid(pfn); +} + static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, struct kvm_memory_slot *memslot, unsigned long hva, unsigned long fault_status) @@ -904,7 +909,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, if (is_error_pfn(pfn)) return -EFAULT; - if (kvm_is_mmio_pfn(pfn)) + if (kvm_is_device_pfn(pfn)) mem_type = PAGE_S2_DEVICE; spin_lock(&kvm->mmu_lock);