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

Open Source and information security mailing list archives

Message-ID: <b56621da-0f8a-06d5-15a1-7034e4274620@arm.com>
Date:   Thu, 24 Mar 2022 12:35:09 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Michael Kelley <mikelley@...rosoft.com>, sthemmin@...rosoft.com,
        kys@...rosoft.com, haiyangz@...rosoft.com, wei.liu@...nel.org,
        decui@...rosoft.com, rafael@...nel.org, lenb@...nel.org,
        lorenzo.pieralisi@....com, robh@...nel.org, kw@...ux.com,
        bhelgaas@...gle.com, hch@....de, m.szyprowski@...sung.com,
        linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-hyperv@...r.kernel.org, linux-pci@...r.kernel.org,
        iommu@...ts.linux-foundation.org
Subject: Re: [PATCH v2 2/2] PCI: hv: Propagate coherence from VMbus device to
 PCI device

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@....com>
> 
>> Signed-off-by: Michael Kelley <mikelley@...rosoft.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@...ts.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives