All of lore.kernel.org
 help / color / mirror / Atom feed
From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] ARM: kvm: define PAGE_S2_DEVICE as read-only by default
Date: Sat, 13 Sep 2014 13:15:45 +0200	[thread overview]
Message-ID: <CAKv+Gu8J8o2=CS9tGVbkavHep6gNwSSegZ0fxqsVE2AVDVzdpA@mail.gmail.com> (raw)
In-Reply-To: <bcbc1c52f9e1eeb24f0bd1956236f0a3@www.loen.fr>

On 13 September 2014 12:41, Marc Zyngier <marc.zyngier@arm.com> wrote:
> Hi Ard,
>
> On 2014-09-13 11:17, Ard Biesheuvel wrote:
>>
>> Now that we support read-only memslots, we need to make sure that
>> pass-through device mappings are not mapped writable if the guest
>> has requested them to be read-only. The existing implementation
>> already honours this by calling kvm_set_s2pte_writable() on the new
>> pte in case of writable mappings, so all we need to do is define
>> the default pgprot_t value used for devices to be PTE_S2_RDONLY.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
>
> I feel very uncomfortable with this change. Why would we map a device RO? Is
> that only for completeness sake?
>

We would map a device RO so that QEMU (or whatever is managing KVM)
can emulate the writes. I don't have a clear cut use case, to be
honest, but setting up a writable mapping for a memslot that was
explicitly set up as read-only seems wrong in any case.

Note that the particular problem I was seeing was primarily caused by
kvm_is_mmio_pfn()'s false positive on the zero page, but it unveiled
this particular issue as well.

> Note that we also use PAGE_S2_DEVICE for things that are not mapped through
> a memslot, such as the GIC.
>

Yes, and I realize now that this breaks it.
My apologies: I have an additional patch locally that sets up MMIO
ranges in one go instead of faulting them in one page at a time as we
do now, and there the read-write case is handled correctly in
kvm_phys_addr_ioremap(). However, I thought it was better to send
these out separately first, but apparently not.

So if we can agree on whether or not MMIO backed mappings should be
read-write even if the memslot says no, I will follow up with a proper
series if there are still changes required.

-- 
Ard.


>
>> ---
>>  arch/arm/include/asm/pgtable.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/include/asm/pgtable.h
>> b/arch/arm/include/asm/pgtable.h
>> index 01baef07cd0c..92b2fbe18868 100644
>> --- a/arch/arm/include/asm/pgtable.h
>> +++ b/arch/arm/include/asm/pgtable.h
>> @@ -100,7 +100,7 @@ extern pgprot_t             pgprot_s2_device;
>>  #define PAGE_HYP               _MOD_PROT(pgprot_kernel, L_PTE_HYP)
>>  #define PAGE_HYP_DEVICE                _MOD_PROT(pgprot_hyp_device,
>> L_PTE_HYP)
>>  #define PAGE_S2                        _MOD_PROT(pgprot_s2,
>> L_PTE_S2_RDONLY)
>> -#define PAGE_S2_DEVICE         _MOD_PROT(pgprot_s2_device, L_PTE_S2_RDWR)
>> +#define PAGE_S2_DEVICE         _MOD_PROT(pgprot_s2_device,
>> L_PTE_S2_RDONLY)
>>
>>  #define __PAGE_NONE            __pgprot(_L_PTE_DEFAULT | L_PTE_RDONLY |
>> L_PTE_XN | L_PTE_NONE)
>>  #define __PAGE_SHARED          __pgprot(_L_PTE_DEFAULT | L_PTE_USER |
>> L_PTE_XN)
>
>
> --
> Fast, cheap, reliable. Pick two.

  reply	other threads:[~2014-09-13 11:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-13 10:17 [PATCH 1/2] ARM: kvm: define PAGE_S2_DEVICE as read-only by default Ard Biesheuvel
2014-09-13 10:17 ` [PATCH 2/2] arm64: " Ard Biesheuvel
2014-09-13 10:41 ` [PATCH 1/2] ARM: " Marc Zyngier
2014-09-13 11:15   ` Ard Biesheuvel [this message]
2014-09-13 17:06     ` Christoffer Dall
2014-09-14  4:49       ` Ard Biesheuvel
2014-09-14  9:09         ` Marc Zyngier
2014-09-14  9:43           ` Ard Biesheuvel
2014-09-14 22:57             ` Ard Biesheuvel
2014-09-15  3:37               ` Peter Maydell
2014-09-15 19:41               ` Mario Smarduch
2014-09-15 19:45                 ` Peter Maydell
2014-09-17 19:19               ` Mario Smarduch

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='CAKv+Gu8J8o2=CS9tGVbkavHep6gNwSSegZ0fxqsVE2AVDVzdpA@mail.gmail.com' \
    --to=ard.biesheuvel@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.