Hi Shanker, On Fri, 30 Apr 2021 12:25:08 +0100, Shanker R Donthineni <sdonthineni@xxxxxxxxxx> wrote: > > Hi Alex > > On 4/29/21 2:46 PM, Alex Williamson wrote: > > If an alignment fault is fixed by configuring a WC mapping, doesn't > > that suggest that the driver performed an unaligned access itself and > > is relying on write combining by the processor to correct that error? > > That's wrong. Fix the driver or please offer another explanation of > > how the WC mapping resolves this. I suspect you could enable tracing > > in QEMU, disable MMIO mmaps on the vfio-pci device and find the invalid > > access. > > > >> We've two concerns here: > >> - Performance impacts for pass-through devices. > >> - The definition of ioremap_wc() function doesn't match the host > >> kernel on ARM64 > > Performance I can understand, but I think you're also using it to mask > > a driver bug which should be resolved first. Thank > > We’ve already instrumented the driver code and found the code path > for the unaligned accesses. We’ll fix this issue if it’s not > following WC semantics. > > Fixing the performance concern will be under KVM stage-2 page-table > control. We're looking for a guidance/solution for updating stage-2 > PTE based on PCI-BAR attribute. Before we start discussing the *how*, I'd like to clearly understand what *arm64* memory attributes you are relying on. We already have established that the unaligned access was a bug, which was the biggest argument in favour of NORMAL_NC. What are the other requirements? Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
