[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e3d7fda8-5263-211c-3686-f699765ab715@nvidia.com>
Date: Fri, 30 Apr 2021 06:25:08 -0500
From: Shanker R Donthineni <sdonthineni@...dia.com>
To: Alex Williamson <alex.williamson@...hat.com>
CC: Marc Zyngier <maz@...nel.org>, Will Deacon <will@...nel.org>,
"Catalin Marinas" <catalin.marinas@....com>,
Christoffer Dall <christoffer.dall@....com>,
<linux-arm-kernel@...ts.infradead.org>,
<kvmarm@...ts.cs.columbia.edu>, <linux-kernel@...r.kernel.org>,
<kvm@...r.kernel.org>, Vikram Sethi <vsethi@...dia.com>,
Jason Sequeira <jsequeira@...dia.com>
Subject: Re: [RFC 1/2] vfio/pci: keep the prefetchable attribute of a BAR
region in VMA
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.
Powered by blists - more mailing lists