Re: [RFC PATCH] PCI: Add quirk to always map ivshmem as write-back

[Alexey Kardashevskiy]

On 26/6/25 02:28, Manivannan Sadhasivam wrote:
> On Tue, Jun 24, 2025 at 11:42:47AM +1000, Alexey Kardashevskiy wrote:
> > Ping? Thanks,
> >
> >
> > On 12/6/25 18:27, Alexey Kardashevskiy wrote:
> > > Wrong email for Nikunj :) And I missed the KVM ml. Sorry for the noise.
> > >
> > >
> > > On 12/6/25 18:22, Alexey Kardashevskiy wrote:
> > > > QEMU Inter-VM Shared Memory (ivshmem) is designed to share a memory
> > > > region between guest and host. The host creates a file, passes it to QEMU
> > > > which it presents to the guest via PCI BAR#2. The guest userspace
> > > > can map /sys/bus/pci/devices/0000:01:02.3/resource2(_wc) to use the region
> > > > without having the guest driver for the device at all.
> > > >
> > > > The problem with this, since it is a PCI resource, the PCI sysfs
> > > > reasonably enforces:
> > > > - no caching when mapped via "resourceN" (PTE::PCD on x86) or
> > > > - write-through when mapped via "resourceN_wc" (PTE::PWT on x86).
> > > >
> > > > As the result, the host writes are seen by the guest immediately
> > > > (as the region is just a mapped file) but it takes quite some time for
> > > > the host to see non-cached guest writes.
> > > >
> > > > Add a quirk to always map ivshmem's BAR2 as cacheable (==write-back) as
> > > > ivshmem is backed by RAM anyway.
> > > > (Re)use already defined but not used IORESOURCE_CACHEABLE flag.
>
> It just makes me nervous to change the sematics of the sysfs attribute, even if
> the user knows what it is expecting.

On 1) Intel 2) without VFIO, the user already gets this semantic. Which seems... alright?

> Now the "resourceN_wc" essentially becomes
> "resourceN_wb", which goes against the rule of sysfs I'm afraid.

What is this rule?

> > > > This does not affect other ways of mapping a PCI BAR, a driver can use
> > > > memremap() for this functionality.
> > > >
> > > > Signed-off-by: Alexey Kardashevskiy <aik@xxxxxxx>
> > > > ---
> > > >
> > > > What is this IORESOURCE_CACHEABLE for actually?
> > > >
> > > > Anyway, the alternatives are:
> > > >
> > > > 1. add a new node in sysfs - "resourceN_wb" - for mapping as writeback
> > > > but this requires changing existing (and likely old) userspace tools;
>
> I guess this would the cleanest approach. The old tools can continue to suffer
> from the performance issue and the new tools can work more faster.

Well yes but the only possible user of this is going to be ivshmem as every other cache coherent thing has a driver which can pick any sort of caching policy, and nobody will ever want a slow ivshmem because there will be no added benefit. I can send a patch if we get consensus on this though. Thanks,


--
Alexey