On Sat, Sep 13, 2014 at 12:38:39PM +0100, Marc Zyngier wrote: > On 2014-09-13 12:15, Ard Biesheuvel wrote: > >On 13 September 2014 12:41, Marc Zyngier <marc.zyngier@xxxxxxx> > >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@xxxxxxxxxx> > >> > >> > >>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. > > That I completely agree with. > > >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. > > I think we should honor whatever userspace requests when mapping the > device as a memslot (things mapped directly by KVM should be > whatever KVM decides to use). > > I'm still unclear about the "forward writes to userspace" thing. I > see it makes sense for emulated devices that are memory-like, but > I'm not so sure about physical devices mapped in the guest (using > VFIO, I presume?). > See my other mail, if it doesn't make sense (?) then we should return an error when trying to create said read-only memslot. -Christoffer _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
