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. > > It's been mentioned earlier that the specific combination of S1 and S2 > > mappings on aarch64 is actually an *architecture bug*. If we accept that > > qualification, then we should realize our efforts here target finding a > > *workaround*. I haven't read this thread in detail but I doubt it's an architecture bug. You may say a missing feature. > > In your blog post > > <http://www.linaro.org/blog/core-dump/on-the-performance-of-arm-virtualization/>, > > you mention VHE ("Virtualization Host Extensions"). That's clearly a > > sign of the architecture adapting to virt software needs. > > > > Do you see any chance that the S1-S2 combinations too can be fixed in a > > new revision of the architecture? > > I really can't speculate about this, I assume there are reasons for why > the architecture is defined in this particular way, but I haven't > investigated this aspect in any depth. In general, there are software issues with forcing cacheability at S2 when S1 required non-cacheable transactions, with all the coherency assumptions. The problem becomes even more complicated when memory types, not just cacheability, are "upgraded". E.g. forcing S1 Device to S2 Normal with consequences on memory ordering that the guest is not aware of. While there are potential, specific, hardware solutions, they can't be "back-ported" to existing CPU implementation, so we need a solution in software. *If* the only software solution has severe performance implications and it is on a critical path, the architecture might be improved in the future (like we did with VHE). But I don't think that's the case here. -- Catalin _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
