On 28 June 2016 at 15:10, Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > On Tue, Jun 28, 2016 at 02:20:43PM +0200, Christoffer Dall wrote: >> On Tue, Jun 28, 2016 at 01:06:36PM +0200, Laszlo Ersek wrote: >> > On 06/28/16 12:04, Christoffer Dall wrote: >> > > On Mon, Jun 27, 2016 at 03:57:28PM +0200, Ard Biesheuvel wrote: >> > >> So if vga-pci.c is the only problematic device, for which a reasonable >> > >> alternative exists (virtio-gpu), I think the only feasible solution is >> > >> to educate QEMU not to allow RAM memslots being exposed via PCI BARs >> > >> when running under KVM/ARM. >> > > >> > > It would be good if we could support vga-pci under KVM/ARM, but if >> > > there's no other way than rewriting the arm64 kernel's memory mappings >> > > completely, then probably we're stuck there, unfortunately. > > Just to be clear, the behaviour of mismatched memory attributes is > defined in the ARM ARM and so far Linux worked fine with such cacheable > vs non-cacheable (as long as only one of them is accessed *or* cache > maintenance is performed accordingly). I don't think the arm64 kernel > memory map needs to be rewritten. > That would suggest that having an uncached userland mapping in QEMU and an uncached kernel mapping in the guest would be ok as long as we don't access the host kernel's cacheable alias? In that case, Drew's approach would be feasible, and the pci_register_bar() function in QEMU could be modified to force the userland mapping and the stage2 mapping to 'device' [when running under KVM/ARM] if it refers to a memslot that is backed by host memory. -- Ard. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
