* RE: [PATCH 14/16] PCI: hv: Switch to msi_create_parent_irq_domain()
From: Thomas Gleixner @ 2025-07-03 19:59 UTC (permalink / raw)
To: Michael Kelley, Nam Cao, Marc Zyngier, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, Karthikeyan Mitran, Hou Zhiqiang,
Thomas Petazzoni, Pali Rohár, K . Y . Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Joyce Ooi, Jim Quinlan,
Nicolas Saenz Julienne, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Ryder Lee, Jianjun Wang, Marek Vasut, Yoshihiro Shimoda,
Michal Simek, Daire McNamara, Nirmal Patel, Jonathan Derrick,
Matthias Brugger, AngeloGioacchino Del Regno,
linux-arm-kernel@lists.infradead.org,
linux-hyperv@vger.kernel.org,
linux-rpi-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <SN6PR02MB4157A6F9B2ABD3C69CE5B521D443A@SN6PR02MB4157.namprd02.prod.outlook.com>
On Thu, Jul 03 2025 at 17:41, Michael Kelley wrote:
> From: Nam Cao <namcao@linutronix.de> Sent: Thursday, June 26, 2025 7:48 AM
>>
>> Move away from the legacy MSI domain setup, switch to use
>> msi_create_parent_irq_domain().
>
> From a build standpoint, this patch does not apply cleanly to
> linux-next20250630. See also an issue below where a needed irq
> function isn't exported.
Does it conflict against the PCI tree?
> At runtime, I've done basic smoke testing on an x86 VM in the Azure
> cloud that has a Mellanox NIC VF and two NVMe devices as PCI devices.
> So far everything looks good. But I'm still doing additional testing, and
> I want to also test on an ARM64 VM. Please give me another day or two
> to be completely satisfied.
Sure.
>> +static void hv_pcie_domain_free(struct irq_domain *d, unsigned int virq, unsigned int nr_irqs)
>> +{
>> + struct msi_domain_info *info = d->host_data;
>> +
>> + for (int i = 0; i < nr_irqs; i++)
>> + hv_msi_free(d, info, virq + i);
>> +
>> + irq_domain_free_irqs_top(d, virq, nr_irqs);
>
> This code can be built as a module, so irq_domain_free_irqs_top() needs to be
> exported, which it currently is not.
Nam, can you please create a seperate patch, which exports this and take
care of the conflict?
Thanks,
tglx
^ permalink raw reply
* RE: [PATCH 14/16] PCI: hv: Switch to msi_create_parent_irq_domain()
From: Michael Kelley @ 2025-07-03 17:41 UTC (permalink / raw)
To: Nam Cao, Marc Zyngier, Thomas Gleixner, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, Karthikeyan Mitran, Hou Zhiqiang,
Thomas Petazzoni, Pali Rohár, K . Y . Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Joyce Ooi, Jim Quinlan,
Nicolas Saenz Julienne, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Ryder Lee, Jianjun Wang, Marek Vasut, Yoshihiro Shimoda,
Michal Simek, Daire McNamara, Nirmal Patel, Jonathan Derrick,
Matthias Brugger, AngeloGioacchino Del Regno,
linux-arm-kernel@lists.infradead.org,
linux-hyperv@vger.kernel.org,
linux-rpi-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <024f0122314198fe0a42fef01af53e8953a687ec.1750858083.git.namcao@linutronix.de>
From: Nam Cao <namcao@linutronix.de> Sent: Thursday, June 26, 2025 7:48 AM
>
> Move away from the legacy MSI domain setup, switch to use
> msi_create_parent_irq_domain().
From a build standpoint, this patch does not apply cleanly to
linux-next20250630. See also an issue below where a needed irq
function isn't exported.
At runtime, I've done basic smoke testing on an x86 VM in the Azure
cloud that has a Mellanox NIC VF and two NVMe devices as PCI devices.
So far everything looks good. But I'm still doing additional testing, and
I want to also test on an ARM64 VM. Please give me another day or two
to be completely satisfied.
Michael Kelley
>
> Signed-off-by: Nam Cao <namcao@linutronix.de>
> ---
> Cc: K. Y. Srinivasan <kys@microsoft.com>
> Cc: Haiyang Zhang <haiyangz@microsoft.com>
> Cc: Wei Liu <wei.liu@kernel.org>
> Cc: Dexuan Cui <decui@microsoft.com>
> Cc: linux-hyperv@vger.kernel.org
> ---
> drivers/pci/Kconfig | 1 +
> drivers/pci/controller/pci-hyperv.c | 98 +++++++++++++++++++++++------
> 2 files changed, 80 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 9c0e4aaf4e8cb..9a249c65aedcd 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -223,6 +223,7 @@ config PCI_HYPERV
> tristate "Hyper-V PCI Frontend"
> depends on ((X86 && X86_64) || ARM64) && HYPERV && PCI_MSI && SYSFS
> select PCI_HYPERV_INTERFACE
> + select IRQ_MSI_LIB
> help
> The PCI device frontend driver allows the kernel to import arbitrary
> PCI devices from a PCI backend to support PCI driver domains.
> diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
> index ef5d655a0052c..3a24fadddb83b 100644
> --- a/drivers/pci/controller/pci-hyperv.c
> +++ b/drivers/pci/controller/pci-hyperv.c
> @@ -44,6 +44,7 @@
> #include <linux/delay.h>
> #include <linux/semaphore.h>
> #include <linux/irq.h>
> +#include <linux/irqchip/irq-msi-lib.h>
> #include <linux/msi.h>
> #include <linux/hyperv.h>
> #include <linux/refcount.h>
> @@ -508,7 +509,6 @@ struct hv_pcibus_device {
> struct list_head children;
> struct list_head dr_list;
>
> - struct msi_domain_info msi_info;
> struct irq_domain *irq_domain;
>
> struct workqueue_struct *wq;
> @@ -1687,7 +1687,7 @@ static void hv_msi_free(struct irq_domain *domain, struct msi_domain_info *info,
> struct msi_desc *msi = irq_data_get_msi_desc(irq_data);
>
> pdev = msi_desc_to_pci_dev(msi);
> - hbus = info->data;
> + hbus = domain->host_data;
> int_desc = irq_data_get_irq_chip_data(irq_data);
> if (!int_desc)
> return;
> @@ -1705,7 +1705,6 @@ static void hv_msi_free(struct irq_domain *domain, struct msi_domain_info *info,
>
> static void hv_irq_mask(struct irq_data *data)
> {
> - pci_msi_mask_irq(data);
> if (data->parent_data->chip->irq_mask)
> irq_chip_mask_parent(data);
> }
> @@ -1716,7 +1715,6 @@ static void hv_irq_unmask(struct irq_data *data)
>
> if (data->parent_data->chip->irq_unmask)
> irq_chip_unmask_parent(data);
> - pci_msi_unmask_irq(data);
> }
>
> struct compose_comp_ctxt {
> @@ -2101,6 +2099,44 @@ static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> msg->data = 0;
> }
>
> +static bool hv_pcie_init_dev_msi_info(struct device *dev, struct irq_domain *domain,
> + struct irq_domain *real_parent, struct msi_domain_info *info)
> +{
> + struct irq_chip *chip = info->chip;
> +
> + if (!msi_lib_init_dev_msi_info(dev, domain, real_parent, info))
> + return false;
> +
> + info->ops->msi_prepare = hv_msi_prepare;
> +
> + chip->irq_set_affinity = irq_chip_set_affinity_parent;
> +
> + if (IS_ENABLED(CONFIG_X86))
> + chip->flags |= IRQCHIP_MOVE_DEFERRED;
> +
> + return true;
> +}
> +
> +#define HV_PCIE_MSI_FLAGS_REQUIRED (MSI_FLAG_USE_DEF_DOM_OPS
> | \
> + MSI_FLAG_USE_DEF_CHIP_OPS | \
> + MSI_FLAG_PCI_MSI_MASK_PARENT)
> +#define HV_PCIE_MSI_FLAGS_SUPPORTED (MSI_FLAG_MULTI_PCI_MSI
> | \
> + MSI_FLAG_PCI_MSIX | \
> + MSI_GENERIC_FLAGS_MASK)
> +
> +static const struct msi_parent_ops hv_pcie_msi_parent_ops = {
> + .required_flags = HV_PCIE_MSI_FLAGS_REQUIRED,
> + .supported_flags = HV_PCIE_MSI_FLAGS_SUPPORTED,
> + .bus_select_token = DOMAIN_BUS_PCI_MSI,
> +#ifdef CONFIG_X86
> + .chip_flags = MSI_CHIP_FLAG_SET_ACK,
> +#elif defined(CONFIG_ARM64)
> + .chip_flags = MSI_CHIP_FLAG_SET_EOI,
> +#endif
> + .prefix = "HV-",
> + .init_dev_msi_info = hv_pcie_init_dev_msi_info,
> +};
> +
> /* HW Interrupt Chip Descriptor */
> static struct irq_chip hv_msi_irq_chip = {
> .name = "Hyper-V PCIe MSI",
> @@ -2108,7 +2144,6 @@ static struct irq_chip hv_msi_irq_chip = {
> .irq_set_affinity = irq_chip_set_affinity_parent,
> #ifdef CONFIG_X86
> .irq_ack = irq_chip_ack_parent,
> - .flags = IRQCHIP_MOVE_DEFERRED,
> #elif defined(CONFIG_ARM64)
> .irq_eoi = irq_chip_eoi_parent,
> #endif
> @@ -2116,9 +2151,37 @@ static struct irq_chip hv_msi_irq_chip = {
> .irq_unmask = hv_irq_unmask,
> };
>
> -static struct msi_domain_ops hv_msi_ops = {
> - .msi_prepare = hv_msi_prepare,
> - .msi_free = hv_msi_free,
> +static int hv_pcie_domain_alloc(struct irq_domain *d, unsigned int virq, unsigned int nr_irqs,
> + void *arg)
> +{
> + /* TODO: move the content of hv_compose_msi_msg() in here */
> + int ret;
> +
> + ret = irq_domain_alloc_irqs_parent(d, virq, nr_irqs, arg);
> + if (ret < 0)
> + return ret;
> +
> + for (int i = 0; i < nr_irqs; i++) {
> + irq_domain_set_info(d, virq + i, 0, &hv_msi_irq_chip, NULL, FLOW_HANDLER, NULL,
> + FLOW_NAME);
> + }
> +
> + return 0;
> +}
> +
> +static void hv_pcie_domain_free(struct irq_domain *d, unsigned int virq, unsigned int nr_irqs)
> +{
> + struct msi_domain_info *info = d->host_data;
> +
> + for (int i = 0; i < nr_irqs; i++)
> + hv_msi_free(d, info, virq + i);
> +
> + irq_domain_free_irqs_top(d, virq, nr_irqs);
This code can be built as a module, so irq_domain_free_irqs_top() needs to be
exported, which it currently is not.
> +}
> +
> +static const struct irq_domain_ops hv_pcie_domain_ops = {
> + .alloc = hv_pcie_domain_alloc,
> + .free = hv_pcie_domain_free,
> };
>
> /**
> @@ -2136,17 +2199,14 @@ static struct msi_domain_ops hv_msi_ops = {
> */
> static int hv_pcie_init_irq_domain(struct hv_pcibus_device *hbus)
> {
> - hbus->msi_info.chip = &hv_msi_irq_chip;
> - hbus->msi_info.ops = &hv_msi_ops;
> - hbus->msi_info.flags = (MSI_FLAG_USE_DEF_DOM_OPS |
> - MSI_FLAG_USE_DEF_CHIP_OPS | MSI_FLAG_MULTI_PCI_MSI |
> - MSI_FLAG_PCI_MSIX);
> - hbus->msi_info.handler = FLOW_HANDLER;
> - hbus->msi_info.handler_name = FLOW_NAME;
> - hbus->msi_info.data = hbus;
> - hbus->irq_domain = pci_msi_create_irq_domain(hbus->fwnode,
> - &hbus->msi_info,
> - hv_pci_get_root_domain());
> + struct irq_domain_info info = {
> + .fwnode = hbus->fwnode,
> + .ops = &hv_pcie_domain_ops,
> + .host_data = hbus,
> + .parent = hv_pci_get_root_domain(),
> + };
> +
> + hbus->irq_domain = msi_create_parent_irq_domain(&info, &hv_pcie_msi_parent_ops);
> if (!hbus->irq_domain) {
> dev_err(&hbus->hdev->device,
> "Failed to build an MSI IRQ domain\n");
> --
> 2.39.5
>
^ permalink raw reply
* Re: [PATCH 00/16] PCI: MSI parent domain conversion
From: Bjorn Helgaas @ 2025-07-03 17:28 UTC (permalink / raw)
To: Nam Cao
Cc: Marc Zyngier, Thomas Gleixner, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci, linux-kernel, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár,
K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Joyce Ooi,
Jim Quinlan, Nicolas Saenz Julienne, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Ryder Lee, Jianjun Wang, Marek Vasut, Yoshihiro Shimoda,
Michal Simek, Daire McNamara, Nirmal Patel, Jonathan Derrick,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-hyperv, linux-rpi-kernel, linux-mediatek, linux-renesas-soc
In-Reply-To: <cover.1750858083.git.namcao@linutronix.de>
On Thu, Jun 26, 2025 at 04:47:50PM +0200, Nam Cao wrote:
> The initial implementation of PCI/MSI interrupt domains in the hierarchical
> interrupt domain model used a shortcut by providing a global PCI/MSI
> domain.
>
> This works because the PCI/MSI[X] hardware is standardized and uniform, but
> it violates the basic design principle of hierarchical interrupt domains:
> Each hardware block involved in the interrupt delivery chain should have a
> separate interrupt domain.
>
> For PCI/MSI[X], the interrupt controller is per PCI device and not a global
> made-up entity.
>
> Unsurprisingly, the shortcut turned out to have downsides as it does not
> allow dynamic allocation of interrupt vectors after initialization and it
> prevents supporting IMS on PCI. For further details, see:
>
> https://lore.kernel.org/lkml/20221111120501.026511281@linutronix.de/
>
> The solution is implementing per device MSI domains, this means the
> entities which provide global PCI/MSI domain so far have to implement MSI
> parent domain functionality instead.
>
> This series converts the PCI controller drivers to implement MSI parent
> domain.
>
> drivers/pci/Kconfig | 1 +
> drivers/pci/controller/Kconfig | 11 +
> drivers/pci/controller/dwc/Kconfig | 1 +
> .../pci/controller/dwc/pcie-designware-host.c | 68 ++----
> drivers/pci/controller/dwc/pcie-designware.h | 1 -
> drivers/pci/controller/mobiveil/Kconfig | 1 +
> .../controller/mobiveil/pcie-mobiveil-host.c | 42 ++--
> .../pci/controller/mobiveil/pcie-mobiveil.h | 1 -
> drivers/pci/controller/pci-aardvark.c | 59 ++---
> drivers/pci/controller/pci-hyperv.c | 98 ++++++--
> drivers/pci/controller/pcie-altera-msi.c | 44 ++--
> drivers/pci/controller/pcie-brcmstb.c | 44 ++--
> drivers/pci/controller/pcie-iproc-msi.c | 45 ++--
> drivers/pci/controller/pcie-mediatek-gen3.c | 67 ++---
> drivers/pci/controller/pcie-mediatek.c | 46 ++--
> drivers/pci/controller/pcie-rcar-host.c | 69 ++----
> drivers/pci/controller/pcie-xilinx-dma-pl.c | 48 ++--
> drivers/pci/controller/pcie-xilinx-nwl.c | 45 ++--
> drivers/pci/controller/pcie-xilinx.c | 55 +++--
> drivers/pci/controller/plda/Kconfig | 1 +
> drivers/pci/controller/plda/pcie-plda-host.c | 44 ++--
> drivers/pci/controller/plda/pcie-plda.h | 1 -
> drivers/pci/controller/vmd.c | 229 +++++++++---------
> 23 files changed, 504 insertions(+), 517 deletions(-)
Looks good to me, thanks! I think Mani will probably pick this up.
I might have included the specific "legacy MSI domain" thing you're
replacing. It looks like you're replacing pci_msi_create_irq_domain()
with msi_create_parent_irq_domain()?
Minor merge conflict in pcie-mediatek-gen3.c with dcbea1c7e94e ("PCI:
mediatek-gen3: Use dev_fwnode() for irq_domain_create_linear()"). No
problem, we can easily fix that up.
The "++i" in vmd.c stuck out to me since "i++" is so much more common.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
^ permalink raw reply
* Re: [PATCH 16/16] PCI: vmd: Switch to msi_create_parent_irq_domain()
From: Thomas Gleixner @ 2025-07-03 13:37 UTC (permalink / raw)
To: Nam Cao, Marc Zyngier, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci, linux-kernel, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár,
K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Joyce Ooi,
Jim Quinlan, Nicolas Saenz Julienne, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Ryder Lee, Jianjun Wang, Marek Vasut, Yoshihiro Shimoda,
Michal Simek, Daire McNamara, Nirmal Patel, Jonathan Derrick,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-hyperv, linux-rpi-kernel, linux-mediatek, linux-renesas-soc
Cc: Nam Cao
In-Reply-To: <de3f1d737831b251e9cd2cbf9e4c732a5bbba13a.1750858083.git.namcao@linutronix.de>
On Thu, Jun 26 2025 at 16:48, Nam Cao wrote:
> Move away from the legacy MSI domain setup, switch to use
> msi_create_parent_irq_domain().
>
> Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [PATCH 15/16] PCI: vmd: Convert to lock guards
From: Thomas Gleixner @ 2025-07-03 13:34 UTC (permalink / raw)
To: Nam Cao, Marc Zyngier, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci, linux-kernel, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár,
K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Joyce Ooi,
Jim Quinlan, Nicolas Saenz Julienne, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Ryder Lee, Jianjun Wang, Marek Vasut, Yoshihiro Shimoda,
Michal Simek, Daire McNamara, Nirmal Patel, Jonathan Derrick,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-hyperv, linux-rpi-kernel, linux-mediatek, linux-renesas-soc
Cc: Nam Cao
In-Reply-To: <836cca37449c70922a2bea1fb13f37940a7a7132.1750858083.git.namcao@linutronix.de>
On Thu, Jun 26 2025 at 16:48, Nam Cao wrote:
> Convert lock/unlock pairs to lock guard and tidy up the code.
>
> Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [PATCH 14/16] PCI: hv: Switch to msi_create_parent_irq_domain()
From: Thomas Gleixner @ 2025-07-03 13:33 UTC (permalink / raw)
To: Nam Cao, Marc Zyngier, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci, linux-kernel, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár,
K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Joyce Ooi,
Jim Quinlan, Nicolas Saenz Julienne, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Ryder Lee, Jianjun Wang, Marek Vasut, Yoshihiro Shimoda,
Michal Simek, Daire McNamara, Nirmal Patel, Jonathan Derrick,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-hyperv, linux-rpi-kernel, linux-mediatek, linux-renesas-soc
Cc: Nam Cao
In-Reply-To: <024f0122314198fe0a42fef01af53e8953a687ec.1750858083.git.namcao@linutronix.de>
On Thu, Jun 26 2025 at 16:48, Nam Cao wrote:
> Move away from the legacy MSI domain setup, switch to use
> msi_create_parent_irq_domain().
>
> Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [PATCH 13/16] PCI: plda: Switch to msi_create_parent_irq_domain()
From: Thomas Gleixner @ 2025-07-03 13:30 UTC (permalink / raw)
To: Nam Cao, Marc Zyngier, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci, linux-kernel, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár,
K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Joyce Ooi,
Jim Quinlan, Nicolas Saenz Julienne, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Ryder Lee, Jianjun Wang, Marek Vasut, Yoshihiro Shimoda,
Michal Simek, Daire McNamara, Nirmal Patel, Jonathan Derrick,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-hyperv, linux-rpi-kernel, linux-mediatek, linux-renesas-soc
Cc: Nam Cao
In-Reply-To: <1279fe6500a1d8135d8f5feb2f055df008746c88.1750858083.git.namcao@linutronix.de>
On Thu, Jun 26 2025 at 16:48, Nam Cao wrote:
> Move away from the legacy MSI domain setup, switch to use
> msi_create_parent_irq_domain().
>
> Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [PATCH 12/16] PCI: xilinx: Switch to msi_create_parent_irq_domain()
From: Thomas Gleixner @ 2025-07-03 13:29 UTC (permalink / raw)
To: Nam Cao, Marc Zyngier, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci, linux-kernel, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár,
K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Joyce Ooi,
Jim Quinlan, Nicolas Saenz Julienne, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Ryder Lee, Jianjun Wang, Marek Vasut, Yoshihiro Shimoda,
Michal Simek, Daire McNamara, Nirmal Patel, Jonathan Derrick,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-hyperv, linux-rpi-kernel, linux-mediatek, linux-renesas-soc
Cc: Nam Cao
In-Reply-To: <b1353c797ce53714c22823de3bd2ae3d09fcd84f.1750858083.git.namcao@linutronix.de>
On Thu, Jun 26 2025 at 16:48, Nam Cao wrote:
> Move away from the legacy MSI domain setup, switch to use
> msi_create_parent_irq_domain().
>
> Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [PATCH 11/16] PCI: xilinx-nwl: Switch to msi_create_parent_irq_domain()
From: Thomas Gleixner @ 2025-07-03 13:28 UTC (permalink / raw)
To: Nam Cao, Marc Zyngier, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci, linux-kernel, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár,
K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Joyce Ooi,
Jim Quinlan, Nicolas Saenz Julienne, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Ryder Lee, Jianjun Wang, Marek Vasut, Yoshihiro Shimoda,
Michal Simek, Daire McNamara, Nirmal Patel, Jonathan Derrick,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-hyperv, linux-rpi-kernel, linux-mediatek, linux-renesas-soc
Cc: Nam Cao
In-Reply-To: <5ac6e216bf2eaa438c8854baf2ff3e5cf0b2284f.1750858083.git.namcao@linutronix.de>
On Thu, Jun 26 2025 at 16:48, Nam Cao wrote:
> Move away from the legacy MSI domain setup, switch to use
> msi_create_parent_irq_domain().
>
> Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [PATCH 10/16] PCI: xilinx-xdma: Switch to msi_create_parent_irq_domain()
From: Thomas Gleixner @ 2025-07-03 13:27 UTC (permalink / raw)
To: Nam Cao, Marc Zyngier, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci, linux-kernel, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár,
K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Joyce Ooi,
Jim Quinlan, Nicolas Saenz Julienne, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Ryder Lee, Jianjun Wang, Marek Vasut, Yoshihiro Shimoda,
Michal Simek, Daire McNamara, Nirmal Patel, Jonathan Derrick,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-hyperv, linux-rpi-kernel, linux-mediatek, linux-renesas-soc
Cc: Nam Cao
In-Reply-To: <b4620dc1808f217a69d0ae50700ffa12ffd657eb.1750858083.git.namcao@linutronix.de>
On Thu, Jun 26 2025 at 16:48, Nam Cao wrote:
> Move away from the legacy MSI domain setup, switch to use
> msi_create_parent_irq_domain().
>
> Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [PATCH 09/16] PCI: rcar-host: Switch to msi_create_parent_irq_domain()
From: Thomas Gleixner @ 2025-07-03 13:26 UTC (permalink / raw)
To: Nam Cao, Marc Zyngier, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci, linux-kernel, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár,
K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Joyce Ooi,
Jim Quinlan, Nicolas Saenz Julienne, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Ryder Lee, Jianjun Wang, Marek Vasut, Yoshihiro Shimoda,
Michal Simek, Daire McNamara, Nirmal Patel, Jonathan Derrick,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-hyperv, linux-rpi-kernel, linux-mediatek, linux-renesas-soc
Cc: Nam Cao, Geert Uytterhoeven, Magnus Damm
In-Reply-To: <ab4005db0a829549be1f348f6c27be50a2118b5e.1750858083.git.namcao@linutronix.de>
On Thu, Jun 26 2025 at 16:47, Nam Cao wrote:
> Move away from the legacy MSI domain setup, switch to use
> msi_create_parent_irq_domain().
>
> Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [PATCH 08/16] PCI: mediatek: Switch to msi_create_parent_irq_domain()
From: Thomas Gleixner @ 2025-07-03 13:25 UTC (permalink / raw)
To: Nam Cao, Marc Zyngier, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci, linux-kernel, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár,
K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Joyce Ooi,
Jim Quinlan, Nicolas Saenz Julienne, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Ryder Lee, Jianjun Wang, Marek Vasut, Yoshihiro Shimoda,
Michal Simek, Daire McNamara, Nirmal Patel, Jonathan Derrick,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-hyperv, linux-rpi-kernel, linux-mediatek, linux-renesas-soc
Cc: Nam Cao
In-Reply-To: <76f6e6ce6021607cd0fdfd79fef7d2eb69d9f361.1750858083.git.namcao@linutronix.de>
On Thu, Jun 26 2025 at 16:47, Nam Cao wrote:
> Move away from the legacy MSI domain setup, switch to use
> msi_create_parent_irq_domain().
>
> Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [PATCH 07/16] PCI: mediatek-gen3: Switch to msi_create_parent_irq_domain()
From: Thomas Gleixner @ 2025-07-03 13:24 UTC (permalink / raw)
To: Nam Cao, Marc Zyngier, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci, linux-kernel, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár,
K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Joyce Ooi,
Jim Quinlan, Nicolas Saenz Julienne, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Ryder Lee, Jianjun Wang, Marek Vasut, Yoshihiro Shimoda,
Michal Simek, Daire McNamara, Nirmal Patel, Jonathan Derrick,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-hyperv, linux-rpi-kernel, linux-mediatek, linux-renesas-soc
Cc: Nam Cao
In-Reply-To: <bfbd2e375269071b69e1aa85e629ee4b7c99518f.1750858083.git.namcao@linutronix.de>
On Thu, Jun 26 2025 at 16:47, Nam Cao wrote:
> Move away from the legacy MSI domain setup, switch to use
> msi_create_parent_irq_domain().
>
> Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [PATCH 06/16] PCI: iproc: Switch to msi_create_parent_irq_domain()
From: Thomas Gleixner @ 2025-07-03 13:23 UTC (permalink / raw)
To: Nam Cao, Marc Zyngier, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci, linux-kernel, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár,
K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Joyce Ooi,
Jim Quinlan, Nicolas Saenz Julienne, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Ryder Lee, Jianjun Wang, Marek Vasut, Yoshihiro Shimoda,
Michal Simek, Daire McNamara, Nirmal Patel, Jonathan Derrick,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-hyperv, linux-rpi-kernel, linux-mediatek, linux-renesas-soc
Cc: Nam Cao
In-Reply-To: <53946d74caf1fd134a1820eac82c3cf64d48779f.1750858083.git.namcao@linutronix.de>
On Thu, Jun 26 2025 at 16:47, Nam Cao wrote:
> Move away from the legacy MSI domain setup, switch to use
> msi_create_parent_irq_domain().
>
> Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [PATCH 05/16] PCI: brcmstb: Switch to msi_create_parent_irq_domain()
From: Thomas Gleixner @ 2025-07-03 13:23 UTC (permalink / raw)
To: Nam Cao, Marc Zyngier, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci, linux-kernel, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár,
K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Joyce Ooi,
Jim Quinlan, Nicolas Saenz Julienne, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Ryder Lee, Jianjun Wang, Marek Vasut, Yoshihiro Shimoda,
Michal Simek, Daire McNamara, Nirmal Patel, Jonathan Derrick,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-hyperv, linux-rpi-kernel, linux-mediatek, linux-renesas-soc
Cc: Nam Cao
In-Reply-To: <fa72703e06c2ee2c7554082c7152913eb0dd294f.1750858083.git.namcao@linutronix.de>
On Thu, Jun 26 2025 at 16:47, Nam Cao wrote:
> Move away from the legacy MSI domain setup, switch to use
> msi_create_parent_irq_domain().
>
> Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [PATCH 04/16] PCI: altera-msi: Switch to msi_create_parent_irq_domain()
From: Thomas Gleixner @ 2025-07-03 13:22 UTC (permalink / raw)
To: Nam Cao, Marc Zyngier, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci, linux-kernel, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár,
K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Joyce Ooi,
Jim Quinlan, Nicolas Saenz Julienne, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Ryder Lee, Jianjun Wang, Marek Vasut, Yoshihiro Shimoda,
Michal Simek, Daire McNamara, Nirmal Patel, Jonathan Derrick,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-hyperv, linux-rpi-kernel, linux-mediatek, linux-renesas-soc
Cc: Nam Cao
In-Reply-To: <0a88da04bb82bd588828a7889e9d58c515ea5dbb.1750858083.git.namcao@linutronix.de>
On Thu, Jun 26 2025 at 16:47, Nam Cao wrote:
> Move away from the legacy MSI domain setup, switch to use
> msi_create_parent_irq_domain().
>
> Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [PATCH 03/16] PCI: aardvark: Switch to msi_create_parent_irq_domain()
From: Thomas Gleixner @ 2025-07-03 13:21 UTC (permalink / raw)
To: Nam Cao, Marc Zyngier, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci, linux-kernel, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár,
K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Joyce Ooi,
Jim Quinlan, Nicolas Saenz Julienne, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Ryder Lee, Jianjun Wang, Marek Vasut, Yoshihiro Shimoda,
Michal Simek, Daire McNamara, Nirmal Patel, Jonathan Derrick,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-hyperv, linux-rpi-kernel, linux-mediatek, linux-renesas-soc
Cc: Nam Cao
In-Reply-To: <68b2f9387bbe4f08bcd428bfab83ad1219fb8d80.1750858083.git.namcao@linutronix.de>
On Thu, Jun 26 2025 at 16:47, Nam Cao wrote:
> Move away from the legacy MSI domain setup, switch to use
> msi_create_parent_irq_domain().
>
> Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [PATCH 02/16] PCI: mobiveil: Switch to msi_create_parent_irq_domain()
From: Thomas Gleixner @ 2025-07-03 13:20 UTC (permalink / raw)
To: Nam Cao, Marc Zyngier, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci, linux-kernel, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár,
K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Joyce Ooi,
Jim Quinlan, Nicolas Saenz Julienne, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Ryder Lee, Jianjun Wang, Marek Vasut, Yoshihiro Shimoda,
Michal Simek, Daire McNamara, Nirmal Patel, Jonathan Derrick,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-hyperv, linux-rpi-kernel, linux-mediatek, linux-renesas-soc
Cc: Nam Cao
In-Reply-To: <af46c15c47a7716f7e0c50d0f7391509c95b49c2.1750858083.git.namcao@linutronix.de>
On Thu, Jun 26 2025 at 16:47, Nam Cao wrote:
> Move away from the legacy MSI domain setup, switch to use
> msi_create_parent_irq_domain().
>
> Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [PATCH 01/16] PCI: dwc: Switch to msi_create_parent_irq_domain()
From: Thomas Gleixner @ 2025-07-03 13:19 UTC (permalink / raw)
To: Nam Cao, Marc Zyngier, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, linux-pci, linux-kernel, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár,
K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Joyce Ooi,
Jim Quinlan, Nicolas Saenz Julienne, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Ryder Lee, Jianjun Wang, Marek Vasut, Yoshihiro Shimoda,
Michal Simek, Daire McNamara, Nirmal Patel, Jonathan Derrick,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-hyperv, linux-rpi-kernel, linux-mediatek, linux-renesas-soc
Cc: Nam Cao, Jingoo Han
In-Reply-To: <04d4a96046490e50139826c16423954e033cdf89.1750858083.git.namcao@linutronix.de>
On Thu, Jun 26 2025 at 16:47, Nam Cao wrote:
> Move away from the legacy MSI domain setup, switch to use
> msi_create_parent_irq_domain().
>
> Signed-off-by: Nam Cao <namcao@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [RFC PATCH 1/1] KVM: VMX: Use Hyper-V EPT flush for local TLB flushes
From: Jeremi Piotrowski @ 2025-07-02 16:11 UTC (permalink / raw)
To: Vitaly Kuznetsov, Sean Christopherson, Paolo Bonzini, kvm
Cc: Dave Hansen, linux-kernel, alanjiang, chinang.ma,
andrea.pellegrini, Kevin Tian, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, linux-hyperv
In-Reply-To: <875xghoaac.fsf@redhat.com>
On 27/06/2025 10:31, Vitaly Kuznetsov wrote:
> Jeremi Piotrowski <jpiotrowski@linux.microsoft.com> writes:
>
>> Use Hyper-V's HvCallFlushGuestPhysicalAddressSpace for local TLB flushes.
>> This makes any KVM_REQ_TLB_FLUSH_CURRENT (such as on root alloc) visible to
>> all CPUs which means we no longer need to do a KVM_REQ_TLB_FLUSH on CPU
>> migration.
>>
>> The goal is to avoid invept-global in KVM_REQ_TLB_FLUSH. Hyper-V uses a
>> shadow page table for the nested hypervisor (KVM) and has to invalidate all
>> EPT roots when invept-global is issued. This has a performance impact on
>> all nested VMs. KVM issues KVM_REQ_TLB_FLUSH on CPU migration, and under
>> load the performance hit causes vCPUs to use up more of their slice of CPU
>> time, leading to more CPU migrations. This has a snowball effect and causes
>> CPU usage spikes.
>>
>> By issuing the hypercall we are now guaranteed that any root modification
>> that requires a local TLB flush becomes visible to all CPUs. The same
>> hypercall is already used in kvm_arch_flush_remote_tlbs and
>> kvm_arch_flush_remote_tlbs_range. The KVM expectation is that roots are
>> flushed locally on alloc and we achieve consistency on migration by
>> flushing all roots - the new behavior of achieving consistency on alloc on
>> Hyper-V is a superset of the expected guarantees. This makes the
>> KVM_REQ_TLB_FLUSH on CPU migration no longer necessary on Hyper-V.
>
> Sounds reasonable overall, my only concern (not sure if valid or not) is
> that using the hypercall for local flushes is going to be more expensive
> than invept-context we do today and thus while the performance is
> improved for the scenario when vCPUs are migrating a lot, we will take a
> hit in other cases.
>
Discussion below, I think the impact should be limited and will try to quantify it.
>>
>> Coincidentally - we now match the behavior of SVM on Hyper-V.
>>
>> Signed-off-by: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
>> ---
>> arch/x86/include/asm/kvm_host.h | 1 +
>> arch/x86/kvm/vmx/vmx.c | 20 +++++++++++++++++---
>> arch/x86/kvm/vmx/vmx_onhyperv.h | 6 ++++++
>> arch/x86/kvm/x86.c | 3 +++
>> 4 files changed, 27 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
>> index b4a391929cdb..d3acab19f425 100644
>> --- a/arch/x86/include/asm/kvm_host.h
>> +++ b/arch/x86/include/asm/kvm_host.h
>> @@ -1077,6 +1077,7 @@ struct kvm_vcpu_arch {
>>
>> #if IS_ENABLED(CONFIG_HYPERV)
>> hpa_t hv_root_tdp;
>> + bool hv_vmx_use_flush_guest_mapping;
>> #endif
>> };
>>
>> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
>> index 4953846cb30d..f537e0df56fc 100644
>> --- a/arch/x86/kvm/vmx/vmx.c
>> +++ b/arch/x86/kvm/vmx/vmx.c
>> @@ -1485,8 +1485,12 @@ void vmx_vcpu_load_vmcs(struct kvm_vcpu *vcpu, int cpu)
>> /*
>> * Flush all EPTP/VPID contexts, the new pCPU may have stale
>> * TLB entries from its previous association with the vCPU.
>> + * Unless we are running on Hyper-V where we promotes local TLB
>
> s,promotes,promote, or, as Sean doesn't like pronouns,
>
> "... where local TLB flushes are promoted ..."
>
Will do.
>> + * flushes to be visible across all CPUs so no need to do again
>> + * on migration.
>> */
>> - kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu);
>> + if (!vmx_hv_use_flush_guest_mapping(vcpu))
>> + kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu);
>>
>> /*
>> * Linux uses per-cpu TSS and GDT, so set these when switching
>> @@ -3243,11 +3247,21 @@ void vmx_flush_tlb_current(struct kvm_vcpu *vcpu)
>> if (!VALID_PAGE(root_hpa))
>> return;
>>
>> - if (enable_ept)
>> + if (enable_ept) {
>> + /*
>> + * hyperv_flush_guest_mapping() has the semantics of
>> + * invept-single across all pCPUs. This makes root
>> + * modifications consistent across pCPUs, so an invept-global
>> + * on migration is no longer required.
>> + */
>> + if (vmx_hv_use_flush_guest_mapping(vcpu))
>> + return (void)WARN_ON_ONCE(hyperv_flush_guest_mapping(root_hpa));
>> +
>
> HvCallFlushGuestPhysicalAddressSpace sounds like a heavy operation as it
> affects all processors. Is there any visible perfomance impact of this
> change when there are no migrations (e.g. with vCPU pinning)? Or do we
> believe that Hyper-V actually handles invept-context the exact same way?
>
I'm going to have to do some more investigation to answer that - do you have an
idea of a workload that would be sensitive to tlb flushes that I could compare
this on?
In terms of cost, Hyper-V needs to invalidate the VMs shadow page table for a root
and do the tlb flush. The first part is CPU intensive but is the same in both cases
(hypercall and invept-single). The tlb flush part will require a bit more work for
the hypercall as it needs to happen on all cores, and the tlb will now be empty
for that root.
My assumption is that these local tlb flushes are rather rare as they will
only happen when:
- new root is allocated
- we need to switch to a special root
So not very frequent post vm boot (with or without pinning). And the effect of the
tlb being empty for that root on other CPUs should be a neutral, as users of the
root would have performed the same local flush at a later point in time (when using it).
All the other mmu updates use kvm_flush_remote_tlbs* which already go through the
hypercall.
Jeremi
^ permalink raw reply
* Re: [EXTERNAL] Re: [PATCH v2] tools/hv: fcopy: Fix irregularities with size of ring buffer
From: Naman Jain @ 2025-07-02 6:56 UTC (permalink / raw)
To: Long Li, Olaf Hering
Cc: KY Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Michael Kelley,
linux-hyperv@vger.kernel.org, Saurabh Sengar
In-Reply-To: <DS2PR21MB51813681D55C8833729D6954CE40A@DS2PR21MB5181.namprd21.prod.outlook.com>
On 7/2/2025 12:02 PM, Long Li wrote:
>> Subject: [EXTERNAL] Re: [PATCH v2] tools/hv: fcopy: Fix irregularities with size of
>> ring buffer
>>
>> Tue, 1 Jul 2025 16:18:37 +0530 Naman Jain <namjain@linux.microsoft.com>:
>>
>>> + syslog(LOG_ERR, "Could not determine ring size, using
>> default: %u bytes",
>>> + HV_RING_SIZE_DEFAULT);
>>
>> I think this is not an actionable error.
>> Maybe use the default just silently?
>>
>
> How about just fail fcopy?
>
> This will have a consistent behavior.
>
> Long
I am OK with that as well. I provided an explanation regarding best
effort fallback mechanism in my other reply in this thread.
From silently ignoring it (1) to failing fcopy (2), or simply logging
as info (3), I would personally prefer either (2) or (3) or keep it in
current form. I'll wait for this discussion to conclude though since we
have varied opinions on this.
Regards,
Naman
^ permalink raw reply
* RE: [EXTERNAL] Re: [PATCH v2] tools/hv: fcopy: Fix irregularities with size of ring buffer
From: Long Li @ 2025-07-02 6:32 UTC (permalink / raw)
To: Olaf Hering, Naman Jain
Cc: KY Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Michael Kelley,
linux-hyperv@vger.kernel.org, Saurabh Sengar
In-Reply-To: <20250701131532.125b960c.olaf@aepfle.de>
> Subject: [EXTERNAL] Re: [PATCH v2] tools/hv: fcopy: Fix irregularities with size of
> ring buffer
>
> Tue, 1 Jul 2025 16:18:37 +0530 Naman Jain <namjain@linux.microsoft.com>:
>
> > + syslog(LOG_ERR, "Could not determine ring size, using
> default: %u bytes",
> > + HV_RING_SIZE_DEFAULT);
>
> I think this is not an actionable error.
> Maybe use the default just silently?
>
How about just fail fcopy?
This will have a consistent behavior.
Long
^ permalink raw reply
* Re: [PATCH v2] tools/hv: fcopy: Fix irregularities with size of ring buffer
From: Naman Jain @ 2025-07-02 5:31 UTC (permalink / raw)
To: Olaf Hering
Cc: K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Michael Kelley, linux-hyperv, Saurabh Sengar
In-Reply-To: <20250701131532.125b960c.olaf@aepfle.de>
On 7/1/2025 4:45 PM, Olaf Hering wrote:
> Tue, 1 Jul 2025 16:18:37 +0530 Naman Jain <namjain@linux.microsoft.com>:
>
>> + syslog(LOG_ERR, "Could not determine ring size, using default: %u bytes",
>> + HV_RING_SIZE_DEFAULT);
>
> I think this is not an actionable error.
> Maybe use the default just silently?
>
>
> Olaf
So let's suppose a case, where the actual ring buffer size was different
than the default value, and for some reason, we were not able to
determine the ring size from the sysfs entry. This results in wrong size
configured in FCopy daemon. FCopy does not work in that scenario and
silently fails. We would definitely like to inform that to the user.
Default size case is just to provide a best effort way of making it
work.
I am fine to change it to LOG_INFO or keep it the same. Please let me
know your thoughts.
Regards,
Naman
^ permalink raw reply
* Re: [PATCH net-next] net: mana: Handle Reset Request from MANA NIC
From: patchwork-bot+netdevbpf @ 2025-07-02 2:40 UTC (permalink / raw)
To: Haiyang Zhang
Cc: linux-hyperv, netdev, haiyangz, decui, stephen, kys, paulros,
olaf, vkuznets, davem, wei.liu, edumazet, kuba, pabeni, leon,
longli, ssengar, linux-rdma, daniel, john.fastabend, bpf, ast,
hawk, tglx, shradhagupta, andrew+netdev, kotaranov, horms,
linux-kernel
In-Reply-To: <1751055983-29760-1-git-send-email-haiyangz@linux.microsoft.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 27 Jun 2025 13:26:23 -0700 you wrote:
> From: Haiyang Zhang <haiyangz@microsoft.com>
>
> Upon receiving the Reset Request, pause the connection and clean up
> queues, wait for the specified period, then resume the NIC.
> In the cleanup phase, the HWC is no longer responding, so set hwc_timeout
> to zero to skip waiting on the response.
>
> [...]
Here is the summary with links:
- [net-next] net: mana: Handle Reset Request from MANA NIC
https://git.kernel.org/netdev/net-next/c/fbe346ce9d62
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* RE: [EXTERNAL] Re: [PATCH] hv_sock: Return the readable bytes in hvs_stream_has_data()
From: Dexuan Cui @ 2025-07-01 18:37 UTC (permalink / raw)
To: Paolo Abeni, niuxuewei97@gmail.com, KY Srinivasan, Haiyang Zhang,
wei.liu@kernel.org, sgarzare@redhat.com, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, horms@kernel.org,
linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <346e4b8a-2e62-420b-9816-6a35b8b63da1@redhat.com>
> From: Paolo Abeni <pabeni@redhat.com>
> Sent: Tuesday, July 1, 2025 6:05 AM
> ...
> > static s64 hvs_stream_has_data(struct vsock_sock *vsk)
> > {
> > struct hvsock *hvs = vsk->trans;
> > + bool need_refill = !hvs->recv_desc;
> > s64 ret;
>
> Minor nit: when reposting please respect the reverse christmas tree
> order above moving 'need_refill' initialization after the following 'if'
> statement.
>
> /P
Thanks! Will do.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox