[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ec8c1b9e-6ada-49c1-a3e3-47452208d26c@linux.microsoft.com>
Date: Mon, 20 May 2024 12:25:35 -0700
From: Roman Kisel <romank@...ux.microsoft.com>
To: Rob Herring <robh@...nel.org>
Cc: arnd@...db.de, bhelgaas@...gle.com, bp@...en8.de,
catalin.marinas@....com, dave.hansen@...ux.intel.com, decui@...rosoft.com,
haiyangz@...rosoft.com, hpa@...or.com, kw@...ux.com, kys@...rosoft.com,
lenb@...nel.org, lpieralisi@...nel.org, mingo@...hat.com,
mhklinux@...look.com, rafael@...nel.org, tglx@...utronix.de,
wei.liu@...nel.org, will@...nel.org, linux-acpi@...r.kernel.org,
linux-arch@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-pci@...r.kernel.org, x86@...nel.org, ssengar@...rosoft.com,
sunilmut@...rosoft.com, vdso@...bites.dev
Subject: Re: [PATCH v2 5/6] drivers/hv/vmbus: Get the irq number from
DeviceTree
On 5/17/2024 10:14 AM, Rob Herring wrote:
> On Tue, May 14, 2024 at 5:45 PM Roman Kisel <romank@...ux.microsoft.com> wrote:
>>
>> The vmbus driver uses ACPI for interrupt assignment on
>> arm64 hence it won't function in the VTL mode where only
>> DeviceTree can be used.
>>
>> Update the vmbus driver to discover interrupt configuration
>> via DeviceTree.
>>
>> Signed-off-by: Roman Kisel <romank@...ux.microsoft.com>
>> ---
>> drivers/hv/vmbus_drv.c | 37 +++++++++++++++++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>>
>> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
>> index e25223cee3ab..52f01bd1c947 100644
>> --- a/drivers/hv/vmbus_drv.c
>> +++ b/drivers/hv/vmbus_drv.c
>> @@ -36,6 +36,7 @@
>> #include <linux/syscore_ops.h>
>> #include <linux/dma-map-ops.h>
>> #include <linux/pci.h>
>> +#include <linux/of_irq.h>
>
> If you are using this header in a driver, you are doing it wrong. We
> have common functions which work on both ACPI or DT, so use them if
> you have a need to support both.
>
Understood, thank you! I'll look more for the examples. If you happen to
have in mind the place where the idiomatic/more preferred approach is
used, please let me know, would owe you a great debt of gratitude.
> Though my first question on a binding will be the same as on every
> 'hypervisor binding'. Why can't you make your hypervisor interfaces
> discoverable? It's all s/w, not some h/w device which is fixed.
>
I've taken a look at the related art. AWS's Firecracker, Intel's Cloud
Hypervisor, Google's CrosVM, QEmu allow the guest use the
well-established battle-tested generic approaches (ACPI,
DeviceTree/OpenFirmware) of describing the virtual hardware and its
resources rather than making the guest use their own specific
interfaces. That holds true for the s/w devices like
"vcpu-stall-detector" and VirtIO that do not have counterparts built as
hardware, too.
Here, the guest needs to set up VMBus (the intra-partition communication
transport) to be able to talk to the host partition. Receiving a message
needs an interrupt service routine attached to the interrupt injected
into the guest virtual processor, and DeviceTree lets provide the
interrupt number. If a custom interface were used here, it'd look less
expected due to others relying on ACPI and DT for configuring virtual
devices and busses. A specialized interface would add more code (new
code) instead of relying on the approach that is widely used.
> Rob
--
Thank you,
Roman
Powered by blists - more mailing lists