Re: [PATCH v2 2/2] PCI: hv: Propagate coherence from VMbus device to PCI device

From: Robin Murphy <robin.murphy@arm.com>
To: Michael Kelley <mikelley@microsoft.com>,
	sthemmin@microsoft.com, kys@microsoft.com,
	haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
	rafael@kernel.org, lenb@kernel.org, lorenzo.pieralisi@arm.com,
	robh@kernel.org, kw@linux.com, bhelgaas@google.com, hch@lst.de,
	m.szyprowski@samsung.com, linux-acpi@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
	linux-pci@vger.kernel.org, iommu@lists.linux-foundation.org
Subject: Re: [PATCH v2 2/2] PCI: hv: Propagate coherence from VMbus device to PCI device
Date: Thu, 24 Mar 2022 12:35:09 +0000	[thread overview]
Message-ID: <b56621da-0f8a-06d5-15a1-7034e4274620@arm.com> (raw)
In-Reply-To: <e6d9af22-df69-bf6a-7877-b916918d0682@arm.com>

On 2022-03-24 12:23, Robin Murphy wrote:
> On 2022-03-23 20:31, Michael Kelley wrote:
>> PCI pass-thru devices in a Hyper-V VM are represented as a VMBus
>> device and as a PCI device.  The coherence of the VMbus device is
>> set based on the VMbus node in ACPI, but the PCI device has no
>> ACPI node and defaults to not hardware coherent.  This results
>> in extra software coherence management overhead on ARM64 when
>> devices are hardware coherent.
>>
>> Fix this by setting up the PCI host bus so that normal
>> PCI mechanisms will propagate the coherence of the VMbus
>> device to the PCI device. There's no effect on x86/x64 where
>> devices are always hardware coherent.
> 
> Honestly, I don't hate this :)
> 
> It seems conceptually accurate, as far as I understand, and in 
> functional terms I'm starting to think it might even be the most correct 
> approach anyway. In the physical world we might be surprised to find the 
> PCI side of a host bridge

And of course by "the PCI side of a host bridge" I think I actually mean 
"a PCI root bus", because in my sloppy terminology I'm thinking about 
hardware bridging from PCI(e) to some SoC-internal protocol, which does 
not have to imply an actual PCI-visible Host Bridge device...

Robin.

> behind anything other than some platform/ACPI 
> device representing the other side of a physical host bridge or root 
> complex, but who's to say that a paravirtual world can't present a more 
> abstract topology? Either way, a one-line way of tying in to the 
> standard flow is hard to turn down.
> 
> Acked-by: Robin Murphy <robin.murphy@arm.com>
> 
>> Signed-off-by: Michael Kelley <mikelley@microsoft.com>
>> ---
>>   drivers/pci/controller/pci-hyperv.c | 9 +++++++++
>>   1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/pci/controller/pci-hyperv.c 
>> b/drivers/pci/controller/pci-hyperv.c
>> index ae0bc2f..88b3b56 100644
>> --- a/drivers/pci/controller/pci-hyperv.c
>> +++ b/drivers/pci/controller/pci-hyperv.c
>> @@ -3404,6 +3404,15 @@ static int hv_pci_probe(struct hv_device *hdev,
>>       hbus->bridge->domain_nr = dom;
>>   #ifdef CONFIG_X86
>>       hbus->sysdata.domain = dom;
>> +#elif defined(CONFIG_ARM64)
>> +    /*
>> +     * Set the PCI bus parent to be the corresponding VMbus
>> +     * device. Then the VMbus device will be assigned as the
>> +     * ACPI companion in pcibios_root_bridge_prepare() and
>> +     * pci_dma_configure() will propagate device coherence
>> +     * information to devices created on the bus.
>> +     */
>> +    hbus->sysdata.parent = hdev->device.parent;
>>   #endif
>>       hbus->hdev = hdev;
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu