* Re: [PATCH v5 2/2] Drivers: hv: Introduce mshv_vtl driver
From: Nuno Das Neves @ 2025-07-17 16:21 UTC (permalink / raw)
To: Michael Kelley, Naman Jain, K . Y . Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui
Cc: Roman Kisel, Anirudh Rayabharam, Saurabh Sengar,
Stanislav Kinsburskii, ALOK TIWARI, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org
In-Reply-To: <SN6PR02MB4157F9F1F8493C74C9FCC6E4D449A@SN6PR02MB4157.namprd02.prod.outlook.com>
On 7/9/2025 10:19 AM, Michael Kelley wrote:
> From: Naman Jain <namjain@linux.microsoft.com> Sent: Wednesday, June 11, 2025 12:27 AM
>> +
>> +union mshv_synic_overlay_page_msr {
>> + u64 as_uint64;
>> + struct {
>> + u64 enabled: 1;
>> + u64 reserved: 11;
>> + u64 pfn: 52;
>> + };
>
> Since this appear to be a Hyper-V synthetic MSR, add __packed?
>
>> +};
>> +
>> +union hv_register_vsm_capabilities {
>> + u64 as_uint64;
>> + struct {
>> + u64 dr6_shared: 1;
>> + u64 mbec_vtl_mask: 16;
>> + u64 deny_lower_vtl_startup: 1;
>> + u64 supervisor_shadow_stack: 1;
>> + u64 hardware_hvpt_available: 1;
>> + u64 software_hvpt_available: 1;
>> + u64 hardware_hvpt_range_bits: 6;
>> + u64 intercept_page_available: 1;
>> + u64 return_action_available: 1;
>> + u64 reserved: 35;
>> + } __packed;
>> +};
>> +
>> +union hv_register_vsm_page_offsets {
>> + struct {
>> + u64 vtl_call_offset : 12;
>> + u64 vtl_return_offset : 12;
>> + u64 reserved_mbz : 40;
>> + };
>> + u64 as_uint64;
>> +} __packed;
>
> We've usually put the __packed on the struct definition. Consistency .... :-)
>
> Don't these three register definitions belong somewhere in the
> hvhdk or hvgdk include files?
>
I agree, hv_register_vsm_capabilities and hv_register_vsm_page_offsets
can be moved to the appropriate include/hyperv/ header/s.
Regarding mshv_synic_overlay_page_msr, it is a generic structure that
appears to be used for several overlay page MSRs (SIMP, SIEF, etc).
But, the type doesn't appear in the hv*dk headers explicitly; it's just
used internally by the hypervisor.
I think it should be renamed with a hv_ prefix to indicate it's part of
the hypervisor ABI, and a brief comment with the provenance:
/* SYNIC_OVERLAY_PAGE_MSR - internal, identical to hv_synic_simp */
union hv_synic_overlay_page_msr {
/* <snip> */
};
And I'm fine with it staying in this file since it's only used here right
now, and doesn't really come from the one of the hyperv headers.
Nuno
^ permalink raw reply
* Re: [PATCH v3] hv_netvsc: Set VF priv_flags to IFF_NO_ADDRCONF before open to prevent IPv6 addrconf
From: patchwork-bot+netdevbpf @ 2025-07-17 14:50 UTC (permalink / raw)
To: Li Tian
Cc: netdev, linux-hyperv, linux-kernel, haiyangz, decui, stephen,
longli
In-Reply-To: <20250716002607.4927-1-litian@redhat.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 16 Jul 2025 08:26:05 +0800 you wrote:
> Set an additional flag IFF_NO_ADDRCONF to prevent ipv6 addrconf.
>
> Commit under Fixes added a new flag change that was not made
> to hv_netvsc resulting in the VF being assinged an IPv6.
>
> Fixes: 8a321cf7becc ("net: add IFF_NO_ADDRCONF and use it in bonding to prevent ipv6 addrconf")
> Suggested-by: Cathy Avery <cavery@redhat.com>
> Signed-off-by: Li Tian <litian@redhat.com>
>
> [...]
Here is the summary with links:
- [v3] hv_netvsc: Set VF priv_flags to IFF_NO_ADDRCONF before open to prevent IPv6 addrconf
https://git.kernel.org/netdev/net/c/d7501e076d85
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 v3] hv_netvsc: Set VF priv_flags to IFF_NO_ADDRCONF before open to prevent IPv6 addrconf
From: Xin Long @ 2025-07-16 21:58 UTC (permalink / raw)
To: Haiyang Zhang
Cc: Simon Horman, Li Tian, netdev@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
Dexuan Cui, Stephen Hemminger, Long Li
In-Reply-To: <SN6PR2101MB0943EAAB55E0BF97E0841419CA56A@SN6PR2101MB0943.namprd21.prod.outlook.com>
On Wed, Jul 16, 2025 at 12:15 PM Haiyang Zhang <haiyangz@microsoft.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Xin Long <lucien.xin@gmail.com>
> > Sent: Wednesday, July 16, 2025 11:14 AM
> > To: Simon Horman <horms@kernel.org>
> > Cc: Li Tian <litian@redhat.com>; netdev@vger.kernel.org; linux-
> > hyperv@vger.kernel.org; linux-kernel@vger.kernel.org; Haiyang Zhang
> > <haiyangz@microsoft.com>; Dexuan Cui <decui@microsoft.com>; Stephen
> > Hemminger <stephen@networkplumber.org>; Long Li <longli@microsoft.com>
> > Subject: [EXTERNAL] Re: [PATCH v3] hv_netvsc: Set VF priv_flags to
> > IFF_NO_ADDRCONF before open to prevent IPv6 addrconf
> >
> > On Wed, Jul 16, 2025 at 5:29 AM Simon Horman <horms@kernel.org> wrote:
> > >
> > > + Xin Long
> > >
> > Thanks for Ccing me.
> >
> > > On Wed, Jul 16, 2025 at 08:26:05AM +0800, Li Tian wrote:
> > > > Set an additional flag IFF_NO_ADDRCONF to prevent ipv6 addrconf.
> > > >
> > > > Commit under Fixes added a new flag change that was not made
> > > > to hv_netvsc resulting in the VF being assinged an IPv6.
> > > >
> > > > Fixes: 8a321cf7becc ("net: add IFF_NO_ADDRCONF and use it in bonding
> > to prevent ipv6 addrconf")
> > > > Suggested-by: Cathy Avery <cavery@redhat.com>
> > > > Signed-off-by: Li Tian <litian@redhat.com>
> > > > ---
> > > > v3:
> > > > - only fixes commit message.
> > > > v2:
> > https://lore.ker/
> > nel.org%2Fnetdev%2F20250710024603.10162-1-
> > litian%40redhat.com%2F&data=05%7C02%7Chaiyangz%40microsoft.com%7C80485948c
> > b344b12f2dd08ddc47b7c6e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63888
> > 2756868249313%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu
> > MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdat
> > a=1ljWIFtnhAiGjdIEgNNlQZGK%2F%2FZHdgHVkvyCWY9%2BKxI%3D&reserved=0
> > > > - instead of replacing flag, add it.
> > > > v1:
> > https://lore.ker/
> > nel.org%2Fnetdev%2F20250710024603.10162-1-
> > litian%40redhat.com%2F&data=05%7C02%7Chaiyangz%40microsoft.com%7C80485948c
> > b344b12f2dd08ddc47b7c6e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63888
> > 2756868272381%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu
> > MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdat
> > a=o%2B2BM9YEi3O2zcqQu9KfPae6PZerBWO%2FhL5KCIeJ9xI%3D&reserved=0
> > > > ---
> > > > drivers/net/hyperv/netvsc_drv.c | 5 ++++-
> > > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > Hi Li Tian,
> > >
> > > Thanks for addressing earlier feedback.
> > >
> > > I don't think you need to repost because of this, but for future
> > reference:
> > >
> > > 1. Because this is a fix for a commit that is present in net
> > > it should be targeted at that tree.
> > >
> > > Subject: [PATCH net vX] ...
> > >
> > > 2. Please use get_maintainers.pl this.patch to generate the CC list. In
> > > this case Xin Long (now CCed) should be included as he is the author
> > of the
> > > patch cited in the Fixes tag.
> > >
> > > b4 can help you with this and other aspects of patch management.
> > >
> > > >
> > > > diff --git a/drivers/net/hyperv/netvsc_drv.c
> > b/drivers/net/hyperv/netvsc_drv.c
> > > > index c41a025c66f0..8be9bce66a4e 100644
> > > > --- a/drivers/net/hyperv/netvsc_drv.c
> > > > +++ b/drivers/net/hyperv/netvsc_drv.c
> > > > @@ -2317,8 +2317,11 @@ static int netvsc_prepare_bonding(struct
> > net_device *vf_netdev)
> > > > if (!ndev)
> > > > return NOTIFY_DONE;
> > > >
> > > > - /* set slave flag before open to prevent IPv6 addrconf */
> > > > + /* Set slave flag and no addrconf flag before open
> > > > + * to prevent IPv6 addrconf.
> > > > + */
> > > > vf_netdev->flags |= IFF_SLAVE;
> > > > + vf_netdev->priv_flags |= IFF_NO_ADDRCONF;
> > If it is only to prevent IPv6 addrconf, I think you can replace IFF_SLAVE
> > with IFF_NO_ADDRCONF.
> >
> > IFF_SLAVE normally comes with IFF_MASTER, like bonding and eql.
> > I don't see IFF_MASTER used in netvsc_drv.c, so IFF_SLAVE probably
> > should be dropped, including the one in __netvsc_vf_setup()?
>
> The IFF_SLAVE is not just for ipv6, the comment should be updated.
> IFF_SLAVE is also used by udev and our other user mode daemons, so it needs
> to stay.
>
Got it, then the patch looks good to me.
Reviewed-by: Xin Long <lucien.xin@gmail.com>
^ permalink raw reply
* Re: [PATCH v3 16/16] objtool: Validate kCFI calls
From: Josh Poimboeuf @ 2025-07-16 21:03 UTC (permalink / raw)
To: Peter Zijlstra
Cc: x86, kys, haiyangz, wei.liu, decui, tglx, mingo, bp, dave.hansen,
hpa, seanjc, pbonzini, ardb, kees, Arnd Bergmann, gregkh,
linux-hyperv, linux-kernel, kvm, linux-efi, samitolvanen, ojeda
In-Reply-To: <20250714103441.496787279@infradead.org>
On Mon, Jul 14, 2025 at 12:20:27PM +0200, Peter Zijlstra wrote:
> Validate that all indirect calls adhere to kCFI rules. Notably doing
> nocfi indirect call to a cfi function is broken.
>
> Apparently some Rust 'core' code violates this and explodes when ran
> with FineIBT.
>
> All the ANNOTATE_NOCFI_SYM sites are prime targets for attackers.
>
> - runtime EFI is especially henous because it also needs to disable
> IBT. Basically calling unknown code without CFI protection at
> runtime is a massice security issue.
>
> - Kexec image handover; if you can exploit this, you get to keep it :-)
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
--
Josh
^ permalink raw reply
* Re: [PATCH 16/16] PCI: vmd: Switch to msi_create_parent_irq_domain()
From: Bjorn Helgaas @ 2025-07-16 20:31 UTC (permalink / raw)
To: Nam Cao
Cc: Antonio Quartulli, 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: <20250716201216.TsY3Kn45@linutronix.de>
On Wed, Jul 16, 2025 at 10:12:16PM +0200, Nam Cao wrote:
> On Wed, Jul 16, 2025 at 09:52:05PM +0200, Antonio Quartulli wrote:
> > Hi Nam,
> Hi Antonio,
>
> > On 26/06/2025 16:48, Nam Cao wrote:
> > [...]
> > > -static void vmd_msi_free(struct irq_domain *domain,
> > > - struct msi_domain_info *info, unsigned int virq)
> > > +static void vmd_msi_free(struct irq_domain *domain, unsigned int virq, unsigned int nr_irqs)
> > > {
> > > struct vmd_irq *vmdirq = irq_get_chip_data(virq);
> > > - synchronize_srcu(&vmdirq->irq->srcu);
> > > + for (int i = 0; i < nr_irqs; ++i) {
> > > + synchronize_srcu(&vmdirq->irq->srcu);
> > > - /* XXX: Potential optimization to rebalance */
> > > - scoped_guard(raw_spinlock_irq, &list_lock)
> > > - vmdirq->irq->count--;
> > > + /* XXX: Potential optimization to rebalance */
> > > + scoped_guard(raw_spinlock_irq, &list_lock)
> > > + vmdirq->irq->count--;
> > > - kfree(vmdirq);
> > > + kfree(vmdirq);
> > > + }
> >
> > By introducing a for loop in this function, you are re-using vmdirq after
> > free'ing it.
> >
> > I can't send a patch because I am not faimliar with this API and I don't
> > know how to fix it.
> >
> > However, the issue was reported today by Coverity.
> >
> > Any idea? :-)
>
> Thanks for the report. That was indeed a mistake from my side.
>
> I hope PCI maintainers don't mind squashing the below diff.
Squashed, thanks! Updated commit:
https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?id=4246b7fccf26
> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> index 48a6096cbbc0..50f0c91d561c 100644
> --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c
> @@ -280,9 +280,11 @@ static int vmd_msi_alloc(struct irq_domain *domain, unsigned int virq,
> static void vmd_msi_free(struct irq_domain *domain, unsigned int virq,
> unsigned int nr_irqs)
> {
> - struct vmd_irq *vmdirq = irq_get_chip_data(virq);
> + struct vmd_irq *vmdirq;
>
> for (int i = 0; i < nr_irqs; ++i) {
> + vmdirq = irq_get_chip_data(virq + i);
> +
> synchronize_srcu(&vmdirq->irq->srcu);
>
> /* XXX: Potential optimization to rebalance */
>
^ permalink raw reply
* Re: [PATCH 16/16] PCI: vmd: Switch to msi_create_parent_irq_domain()
From: Nam Cao @ 2025-07-16 20:12 UTC (permalink / raw)
To: Antonio Quartulli
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: <7d8cfcf5-08db-4712-a98f-2cbfb9beeb85@mandelbit.com>
On Wed, Jul 16, 2025 at 09:52:05PM +0200, Antonio Quartulli wrote:
> Hi Nam,
Hi Antonio,
> On 26/06/2025 16:48, Nam Cao wrote:
> [...]
> > -static void vmd_msi_free(struct irq_domain *domain,
> > - struct msi_domain_info *info, unsigned int virq)
> > +static void vmd_msi_free(struct irq_domain *domain, unsigned int virq, unsigned int nr_irqs)
> > {
> > struct vmd_irq *vmdirq = irq_get_chip_data(virq);
> > - synchronize_srcu(&vmdirq->irq->srcu);
> > + for (int i = 0; i < nr_irqs; ++i) {
> > + synchronize_srcu(&vmdirq->irq->srcu);
> > - /* XXX: Potential optimization to rebalance */
> > - scoped_guard(raw_spinlock_irq, &list_lock)
> > - vmdirq->irq->count--;
> > + /* XXX: Potential optimization to rebalance */
> > + scoped_guard(raw_spinlock_irq, &list_lock)
> > + vmdirq->irq->count--;
> > - kfree(vmdirq);
> > + kfree(vmdirq);
> > + }
>
> By introducing a for loop in this function, you are re-using vmdirq after
> free'ing it.
>
> I can't send a patch because I am not faimliar with this API and I don't
> know how to fix it.
>
> However, the issue was reported today by Coverity.
>
> Any idea? :-)
Thanks for the report. That was indeed a mistake from my side.
I hope PCI maintainers don't mind squashing the below diff.
Sorry for the troubles so far,
Nam
diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
index 48a6096cbbc0..50f0c91d561c 100644
--- a/drivers/pci/controller/vmd.c
+++ b/drivers/pci/controller/vmd.c
@@ -280,9 +280,11 @@ static int vmd_msi_alloc(struct irq_domain *domain, unsigned int virq,
static void vmd_msi_free(struct irq_domain *domain, unsigned int virq,
unsigned int nr_irqs)
{
- struct vmd_irq *vmdirq = irq_get_chip_data(virq);
+ struct vmd_irq *vmdirq;
for (int i = 0; i < nr_irqs; ++i) {
+ vmdirq = irq_get_chip_data(virq + i);
+
synchronize_srcu(&vmdirq->irq->srcu);
/* XXX: Potential optimization to rebalance */
^ permalink raw reply related
* Re: [PATCH 16/16] PCI: vmd: Switch to msi_create_parent_irq_domain()
From: Antonio Quartulli @ 2025-07-16 19:52 UTC (permalink / raw)
To: Nam Cao, 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: <de3f1d737831b251e9cd2cbf9e4c732a5bbba13a.1750858083.git.namcao@linutronix.de>
Hi Nam,
On 26/06/2025 16:48, Nam Cao wrote:
[...]
> -static void vmd_msi_free(struct irq_domain *domain,
> - struct msi_domain_info *info, unsigned int virq)
> +static void vmd_msi_free(struct irq_domain *domain, unsigned int virq, unsigned int nr_irqs)
> {
> struct vmd_irq *vmdirq = irq_get_chip_data(virq);
>
> - synchronize_srcu(&vmdirq->irq->srcu);
> + for (int i = 0; i < nr_irqs; ++i) {
> + synchronize_srcu(&vmdirq->irq->srcu);
>
> - /* XXX: Potential optimization to rebalance */
> - scoped_guard(raw_spinlock_irq, &list_lock)
> - vmdirq->irq->count--;
> + /* XXX: Potential optimization to rebalance */
> + scoped_guard(raw_spinlock_irq, &list_lock)
> + vmdirq->irq->count--;
>
> - kfree(vmdirq);
> + kfree(vmdirq);
> + }
By introducing a for loop in this function, you are re-using vmdirq
after free'ing it.
I can't send a patch because I am not faimliar with this API and I don't
know how to fix it.
However, the issue was reported today by Coverity.
Any idea? :-)
Regards,
--
Antonio Quartulli
CEO and Co-Founder
Mandelbit Srl
https://www.mandelbit.com
^ permalink raw reply
* Re: [PATCH 16/16] PCI: vmd: Switch to msi_create_parent_irq_domain()
From: Bjorn Helgaas @ 2025-07-16 19:41 UTC (permalink / raw)
To: Nirmal Patel
Cc: Nam Cao, 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, Jonathan Derrick, Matthias Brugger,
AngeloGioacchino Del Regno, linux-arm-kernel, linux-hyperv,
linux-rpi-kernel, linux-mediatek, linux-renesas-soc
In-Reply-To: <20250716111009.000022ff@linux.intel.com>
On Wed, Jul 16, 2025 at 11:10:09AM -0700, Nirmal Patel wrote:
> On Thu, 26 Jun 2025 16:48:06 +0200
> Nam Cao <namcao@linutronix.de> wrote:
>
> > Move away from the legacy MSI domain setup, switch to use
> > msi_create_parent_irq_domain().
> > - unsigned int virq, irq_hw_number_t hwirq,
> > - msi_alloc_info_t *arg)
> > +static void vmd_msi_free(struct irq_domain *domain, unsigned int
> > virq, unsigned int nr_irqs); +
> > +static int vmd_msi_alloc(struct irq_domain *domain, unsigned int
> > virq, unsigned int nr_irqs,
> > + void *arg)
>
> Is this wrapped in 80 columns? I can see few lines are more than 80.
> Disregard this if it is wrapped and it can be my claws mail client
> issue.
Wrapped locally, thanks Nirmal.
Bjorn
^ permalink raw reply
* Re: [PATCH 16/16] PCI: vmd: Switch to msi_create_parent_irq_domain()
From: Nirmal Patel @ 2025-07-16 18:10 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, Jonathan Derrick, Matthias Brugger,
AngeloGioacchino Del Regno, linux-arm-kernel, linux-hyperv,
linux-rpi-kernel, linux-mediatek, linux-renesas-soc
In-Reply-To: <de3f1d737831b251e9cd2cbf9e4c732a5bbba13a.1750858083.git.namcao@linutronix.de>
On Thu, 26 Jun 2025 16:48:06 +0200
Nam Cao <namcao@linutronix.de> 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>
> ---
> Cc: Nirmal Patel <nirmal.patel@linux.intel.com>
> Cc: Jonathan Derrick <jonathan.derrick@linux.dev>
> ---
> drivers/pci/controller/Kconfig | 1 +
> drivers/pci/controller/vmd.c | 160
> +++++++++++++++++---------------- 2 files changed, 82 insertions(+),
> 79 deletions(-)
>
> diff --git a/drivers/pci/controller/Kconfig
> b/drivers/pci/controller/Kconfig index 8f56ffd029ba2..41748d083b933
> 100644 --- a/drivers/pci/controller/Kconfig
> +++ b/drivers/pci/controller/Kconfig
> @@ -156,6 +156,7 @@ config PCI_IXP4XX
> config VMD
> depends on PCI_MSI && X86_64 && !UML
> tristate "Intel Volume Management Device Driver"
> + select IRQ_MSI_LIB
> help
> Adds support for the Intel Volume Management Device (VMD).
> VMD is a secondary PCI host bridge that allows PCI Express root ports,
> diff --git a/drivers/pci/controller/vmd.c
> b/drivers/pci/controller/vmd.c index d9b893bf4e456..38693a9487d9b
> 100644 --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c
> @@ -7,6 +7,7 @@
> #include <linux/device.h>
> #include <linux/interrupt.h>
> #include <linux/irq.h>
> +#include <linux/irqchip/irq-msi-lib.h>
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/msi.h>
> @@ -174,9 +175,6 @@ static void vmd_compose_msi_msg(struct irq_data
> *data, struct msi_msg *msg) msg->arch_addr_lo.destid_0_7 =
> index_from_irqs(vmd, irq); }
>
> -/*
> - * We rely on MSI_FLAG_USE_DEF_CHIP_OPS to set the IRQ mask/unmask
> ops.
> - */
> static void vmd_irq_enable(struct irq_data *data)
> {
> struct vmd_irq *vmdirq = data->chip_data;
> @@ -186,7 +184,11 @@ static void vmd_irq_enable(struct irq_data *data)
> list_add_tail_rcu(&vmdirq->node,
> &vmdirq->irq->irq_list); vmdirq->enabled = true;
> }
> +}
>
> +static void vmd_pci_msi_enable(struct irq_data *data)
> +{
> + vmd_irq_enable(data->parent_data);
> data->chip->irq_unmask(data);
> }
>
> @@ -194,8 +196,6 @@ static void vmd_irq_disable(struct irq_data *data)
> {
> struct vmd_irq *vmdirq = data->chip_data;
>
> - data->chip->irq_mask(data);
> -
> scoped_guard(raw_spinlock_irqsave, &list_lock) {
> if (vmdirq->enabled) {
> list_del_rcu(&vmdirq->node);
> @@ -204,19 +204,17 @@ static void vmd_irq_disable(struct irq_data
> *data) }
> }
>
> +static void vmd_pci_msi_disable(struct irq_data *data)
> +{
> + data->chip->irq_mask(data);
> + vmd_irq_disable(data->parent_data);
> +}
> +
> static struct irq_chip vmd_msi_controller = {
> .name = "VMD-MSI",
> - .irq_enable = vmd_irq_enable,
> - .irq_disable = vmd_irq_disable,
> .irq_compose_msi_msg = vmd_compose_msi_msg,
> };
>
> -static irq_hw_number_t vmd_get_hwirq(struct msi_domain_info *info,
> - msi_alloc_info_t *arg)
> -{
> - return 0;
> -}
> -
> /*
> * XXX: We can be even smarter selecting the best IRQ once we solve
> the
> * affinity problem.
> @@ -250,100 +248,110 @@ static struct vmd_irq_list
> *vmd_next_irq(struct vmd_dev *vmd, struct msi_desc *d return
> &vmd->irqs[best]; }
>
> -static int vmd_msi_init(struct irq_domain *domain, struct
> msi_domain_info *info,
> - unsigned int virq, irq_hw_number_t hwirq,
> - msi_alloc_info_t *arg)
> +static void vmd_msi_free(struct irq_domain *domain, unsigned int
> virq, unsigned int nr_irqs); +
> +static int vmd_msi_alloc(struct irq_domain *domain, unsigned int
> virq, unsigned int nr_irqs,
> + void *arg)
Is this wrapped in 80 columns? I can see few lines are more than 80.
Disregard this if it is wrapped and it can be my claws mail client
issue.
> {
> - struct msi_desc *desc = arg->desc;
> - struct vmd_dev *vmd =
> vmd_from_bus(msi_desc_to_pci_dev(desc)->bus);
> - struct vmd_irq *vmdirq = kzalloc(sizeof(*vmdirq),
> GFP_KERNEL);
> + struct msi_desc *desc = ((msi_alloc_info_t *)arg)->desc;
> + struct vmd_dev *vmd = domain->host_data;
> + struct vmd_irq *vmdirq;
>
> - if (!vmdirq)
> - return -ENOMEM;
> + for (int i = 0; i < nr_irqs; ++i) {
> + vmdirq = kzalloc(sizeof(*vmdirq), GFP_KERNEL);
> + if (!vmdirq) {
> + vmd_msi_free(domain, virq, i);
> + return -ENOMEM;
> + }
>
> - INIT_LIST_HEAD(&vmdirq->node);
> - vmdirq->irq = vmd_next_irq(vmd, desc);
> - vmdirq->virq = virq;
> + INIT_LIST_HEAD(&vmdirq->node);
> + vmdirq->irq = vmd_next_irq(vmd, desc);
> + vmdirq->virq = virq + i;
> +
> + irq_domain_set_info(domain, virq + i,
> vmdirq->irq->virq, &vmd_msi_controller,
> + vmdirq, handle_untracked_irq,
> vmd, NULL);
> + }
>
> - irq_domain_set_info(domain, virq, vmdirq->irq->virq,
> info->chip, vmdirq,
> - handle_untracked_irq, vmd, NULL);
> return 0;
> }
>
> -static void vmd_msi_free(struct irq_domain *domain,
> - struct msi_domain_info *info, unsigned int
> virq) +static void vmd_msi_free(struct irq_domain *domain, unsigned
> int virq, unsigned int nr_irqs) {
> struct vmd_irq *vmdirq = irq_get_chip_data(virq);
>
> - synchronize_srcu(&vmdirq->irq->srcu);
> + for (int i = 0; i < nr_irqs; ++i) {
> + synchronize_srcu(&vmdirq->irq->srcu);
>
> - /* XXX: Potential optimization to rebalance */
> - scoped_guard(raw_spinlock_irq, &list_lock)
> - vmdirq->irq->count--;
> + /* XXX: Potential optimization to rebalance */
> + scoped_guard(raw_spinlock_irq, &list_lock)
> + vmdirq->irq->count--;
>
> - kfree(vmdirq);
> + kfree(vmdirq);
> + }
> }
>
> -static int vmd_msi_prepare(struct irq_domain *domain, struct device
> *dev,
> - int nvec, msi_alloc_info_t *arg)
> +static const struct irq_domain_ops vmd_msi_domain_ops = {
> + .alloc = vmd_msi_alloc,
> + .free = vmd_msi_free,
> +};
> +
> +static bool vmd_init_dev_msi_info(struct device *dev, struct
> irq_domain *domain,
> + struct irq_domain *real_parent,
> struct msi_domain_info *info) {
> - struct pci_dev *pdev = to_pci_dev(dev);
> - struct vmd_dev *vmd = vmd_from_bus(pdev->bus);
> + if (WARN_ON_ONCE(info->bus_token !=
> DOMAIN_BUS_PCI_DEVICE_MSIX))
> + return false;
>
> - if (nvec > vmd->msix_count)
> - return vmd->msix_count;
> + if (!msi_lib_init_dev_msi_info(dev, domain, real_parent,
> info))
> + return false;
>
> - memset(arg, 0, sizeof(*arg));
> - return 0;
> + info->chip->irq_enable = vmd_pci_msi_enable;
> + info->chip->irq_disable = vmd_pci_msi_disable;
> + return true;
> }
>
> -static void vmd_set_desc(msi_alloc_info_t *arg, struct msi_desc
> *desc) -{
> - arg->desc = desc;
> -}
> +#define VMD_MSI_FLAGS_SUPPORTED
> (MSI_GENERIC_FLAGS_MASK | MSI_FLAG_PCI_MSIX) +#define
> VMD_MSI_FLAGS_REQUIRED (MSI_FLAG_USE_DEF_DOM_OPS |
> MSI_FLAG_NO_AFFINITY) -static struct msi_domain_ops
> vmd_msi_domain_ops = {
> - .get_hwirq = vmd_get_hwirq,
> - .msi_init = vmd_msi_init,
> - .msi_free = vmd_msi_free,
> - .msi_prepare = vmd_msi_prepare,
> - .set_desc = vmd_set_desc,
> +static const struct msi_parent_ops vmd_msi_parent_ops = {
> + .supported_flags = VMD_MSI_FLAGS_SUPPORTED,
> + .required_flags = VMD_MSI_FLAGS_REQUIRED,
> + .bus_select_token = DOMAIN_BUS_VMD_MSI,
> + .bus_select_mask = MATCH_PCI_MSI,
> + .prefix = "VMD-",
> + .init_dev_msi_info = vmd_init_dev_msi_info,
> };
>
> -static struct msi_domain_info vmd_msi_domain_info = {
> - .flags = MSI_FLAG_USE_DEF_DOM_OPS |
> MSI_FLAG_USE_DEF_CHIP_OPS |
> - MSI_FLAG_NO_AFFINITY | MSI_FLAG_PCI_MSIX,
> - .ops = &vmd_msi_domain_ops,
> - .chip = &vmd_msi_controller,
> -};
> -
> -static void vmd_set_msi_remapping(struct vmd_dev *vmd, bool enable)
> -{
> - u16 reg;
> -
> - pci_read_config_word(vmd->dev, PCI_REG_VMCONFIG, ®);
> - reg = enable ? (reg & ~VMCONFIG_MSI_REMAP) :
> - (reg | VMCONFIG_MSI_REMAP);
> - pci_write_config_word(vmd->dev, PCI_REG_VMCONFIG, reg);
> -}
> -
> static int vmd_create_irq_domain(struct vmd_dev *vmd)
> {
> - struct fwnode_handle *fn;
> + struct irq_domain_info info = {
> + .size = vmd->msix_count,
> + .ops = &vmd_msi_domain_ops,
> + .host_data = vmd,
> + };
>
> - fn = irq_domain_alloc_named_id_fwnode("VMD-MSI",
> vmd->sysdata.domain);
> - if (!fn)
> + info.fwnode = irq_domain_alloc_named_id_fwnode("VMD-MSI",
> vmd->sysdata.domain);
> + if (!info.fwnode)
> return -ENODEV;
>
> - vmd->irq_domain = pci_msi_create_irq_domain(fn,
> &vmd_msi_domain_info, NULL);
> + vmd->irq_domain = msi_create_parent_irq_domain(&info,
> &vmd_msi_parent_ops); if (!vmd->irq_domain) {
> - irq_domain_free_fwnode(fn);
> + irq_domain_free_fwnode(info.fwnode);
> return -ENODEV;
> }
>
> return 0;
> }
>
> +static void vmd_set_msi_remapping(struct vmd_dev *vmd, bool enable)
> +{
> + u16 reg;
> +
> + pci_read_config_word(vmd->dev, PCI_REG_VMCONFIG, ®);
> + reg = enable ? (reg & ~VMCONFIG_MSI_REMAP) :
> + (reg | VMCONFIG_MSI_REMAP);
> + pci_write_config_word(vmd->dev, PCI_REG_VMCONFIG, reg);
> +}
> +
> static void vmd_remove_irq_domain(struct vmd_dev *vmd)
> {
> /*
> @@ -874,12 +882,6 @@ static int vmd_enable_domain(struct vmd_dev
> *vmd, unsigned long features) ret = vmd_create_irq_domain(vmd);
> if (ret)
> return ret;
> -
> - /*
> - * Override the IRQ domain bus token so the domain
> can be
> - * distinguished from a regular PCI/MSI domain.
> - */
> - irq_domain_update_bus_token(vmd->irq_domain,
> DOMAIN_BUS_VMD_MSI); } else {
> vmd_set_msi_remapping(vmd, false);
> }
^ permalink raw reply
* RE: [EXTERNAL] Re: [PATCH v3] hv_netvsc: Set VF priv_flags to IFF_NO_ADDRCONF before open to prevent IPv6 addrconf
From: Haiyang Zhang @ 2025-07-16 16:15 UTC (permalink / raw)
To: Xin Long, Simon Horman
Cc: Li Tian, netdev@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, Dexuan Cui, Stephen Hemminger,
Long Li
In-Reply-To: <CADvbK_cdOTO_UVg6ovx-Si7-ja=ErYw-MnSnR-CL4HwmtKJ8YQ@mail.gmail.com>
> -----Original Message-----
> From: Xin Long <lucien.xin@gmail.com>
> Sent: Wednesday, July 16, 2025 11:14 AM
> To: Simon Horman <horms@kernel.org>
> Cc: Li Tian <litian@redhat.com>; netdev@vger.kernel.org; linux-
> hyperv@vger.kernel.org; linux-kernel@vger.kernel.org; Haiyang Zhang
> <haiyangz@microsoft.com>; Dexuan Cui <decui@microsoft.com>; Stephen
> Hemminger <stephen@networkplumber.org>; Long Li <longli@microsoft.com>
> Subject: [EXTERNAL] Re: [PATCH v3] hv_netvsc: Set VF priv_flags to
> IFF_NO_ADDRCONF before open to prevent IPv6 addrconf
>
> On Wed, Jul 16, 2025 at 5:29 AM Simon Horman <horms@kernel.org> wrote:
> >
> > + Xin Long
> >
> Thanks for Ccing me.
>
> > On Wed, Jul 16, 2025 at 08:26:05AM +0800, Li Tian wrote:
> > > Set an additional flag IFF_NO_ADDRCONF to prevent ipv6 addrconf.
> > >
> > > Commit under Fixes added a new flag change that was not made
> > > to hv_netvsc resulting in the VF being assinged an IPv6.
> > >
> > > Fixes: 8a321cf7becc ("net: add IFF_NO_ADDRCONF and use it in bonding
> to prevent ipv6 addrconf")
> > > Suggested-by: Cathy Avery <cavery@redhat.com>
> > > Signed-off-by: Li Tian <litian@redhat.com>
> > > ---
> > > v3:
> > > - only fixes commit message.
> > > v2:
> https://lore.ker/
> nel.org%2Fnetdev%2F20250710024603.10162-1-
> litian%40redhat.com%2F&data=05%7C02%7Chaiyangz%40microsoft.com%7C80485948c
> b344b12f2dd08ddc47b7c6e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63888
> 2756868249313%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu
> MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdat
> a=1ljWIFtnhAiGjdIEgNNlQZGK%2F%2FZHdgHVkvyCWY9%2BKxI%3D&reserved=0
> > > - instead of replacing flag, add it.
> > > v1:
> https://lore.ker/
> nel.org%2Fnetdev%2F20250710024603.10162-1-
> litian%40redhat.com%2F&data=05%7C02%7Chaiyangz%40microsoft.com%7C80485948c
> b344b12f2dd08ddc47b7c6e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63888
> 2756868272381%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu
> MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdat
> a=o%2B2BM9YEi3O2zcqQu9KfPae6PZerBWO%2FhL5KCIeJ9xI%3D&reserved=0
> > > ---
> > > drivers/net/hyperv/netvsc_drv.c | 5 ++++-
> > > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > Hi Li Tian,
> >
> > Thanks for addressing earlier feedback.
> >
> > I don't think you need to repost because of this, but for future
> reference:
> >
> > 1. Because this is a fix for a commit that is present in net
> > it should be targeted at that tree.
> >
> > Subject: [PATCH net vX] ...
> >
> > 2. Please use get_maintainers.pl this.patch to generate the CC list. In
> > this case Xin Long (now CCed) should be included as he is the author
> of the
> > patch cited in the Fixes tag.
> >
> > b4 can help you with this and other aspects of patch management.
> >
> > >
> > > diff --git a/drivers/net/hyperv/netvsc_drv.c
> b/drivers/net/hyperv/netvsc_drv.c
> > > index c41a025c66f0..8be9bce66a4e 100644
> > > --- a/drivers/net/hyperv/netvsc_drv.c
> > > +++ b/drivers/net/hyperv/netvsc_drv.c
> > > @@ -2317,8 +2317,11 @@ static int netvsc_prepare_bonding(struct
> net_device *vf_netdev)
> > > if (!ndev)
> > > return NOTIFY_DONE;
> > >
> > > - /* set slave flag before open to prevent IPv6 addrconf */
> > > + /* Set slave flag and no addrconf flag before open
> > > + * to prevent IPv6 addrconf.
> > > + */
> > > vf_netdev->flags |= IFF_SLAVE;
> > > + vf_netdev->priv_flags |= IFF_NO_ADDRCONF;
> If it is only to prevent IPv6 addrconf, I think you can replace IFF_SLAVE
> with IFF_NO_ADDRCONF.
>
> IFF_SLAVE normally comes with IFF_MASTER, like bonding and eql.
> I don't see IFF_MASTER used in netvsc_drv.c, so IFF_SLAVE probably
> should be dropped, including the one in __netvsc_vf_setup()?
The IFF_SLAVE is not just for ipv6, the comment should be updated.
IFF_SLAVE is also used by udev and our other user mode daemons, so it needs
to stay.
- Haiyang
^ permalink raw reply
* Re: [PATCH v3] hv_netvsc: Set VF priv_flags to IFF_NO_ADDRCONF before open to prevent IPv6 addrconf
From: Xin Long @ 2025-07-16 15:14 UTC (permalink / raw)
To: Simon Horman
Cc: Li Tian, netdev, linux-hyperv, linux-kernel, Haiyang Zhang,
Dexuan Cui, Stephen Hemminger, Long Li
In-Reply-To: <20250716092927.GO721198@horms.kernel.org>
On Wed, Jul 16, 2025 at 5:29 AM Simon Horman <horms@kernel.org> wrote:
>
> + Xin Long
>
Thanks for Ccing me.
> On Wed, Jul 16, 2025 at 08:26:05AM +0800, Li Tian wrote:
> > Set an additional flag IFF_NO_ADDRCONF to prevent ipv6 addrconf.
> >
> > Commit under Fixes added a new flag change that was not made
> > to hv_netvsc resulting in the VF being assinged an IPv6.
> >
> > Fixes: 8a321cf7becc ("net: add IFF_NO_ADDRCONF and use it in bonding to prevent ipv6 addrconf")
> > Suggested-by: Cathy Avery <cavery@redhat.com>
> > Signed-off-by: Li Tian <litian@redhat.com>
> > ---
> > v3:
> > - only fixes commit message.
> > v2: https://lore.kernel.org/netdev/20250710024603.10162-1-litian@redhat.com/
> > - instead of replacing flag, add it.
> > v1: https://lore.kernel.org/netdev/20250710024603.10162-1-litian@redhat.com/
> > ---
> > drivers/net/hyperv/netvsc_drv.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
>
> Hi Li Tian,
>
> Thanks for addressing earlier feedback.
>
> I don't think you need to repost because of this, but for future reference:
>
> 1. Because this is a fix for a commit that is present in net
> it should be targeted at that tree.
>
> Subject: [PATCH net vX] ...
>
> 2. Please use get_maintainers.pl this.patch to generate the CC list. In
> this case Xin Long (now CCed) should be included as he is the author of the
> patch cited in the Fixes tag.
>
> b4 can help you with this and other aspects of patch management.
>
> >
> > diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> > index c41a025c66f0..8be9bce66a4e 100644
> > --- a/drivers/net/hyperv/netvsc_drv.c
> > +++ b/drivers/net/hyperv/netvsc_drv.c
> > @@ -2317,8 +2317,11 @@ static int netvsc_prepare_bonding(struct net_device *vf_netdev)
> > if (!ndev)
> > return NOTIFY_DONE;
> >
> > - /* set slave flag before open to prevent IPv6 addrconf */
> > + /* Set slave flag and no addrconf flag before open
> > + * to prevent IPv6 addrconf.
> > + */
> > vf_netdev->flags |= IFF_SLAVE;
> > + vf_netdev->priv_flags |= IFF_NO_ADDRCONF;
If it is only to prevent IPv6 addrconf, I think you can replace IFF_SLAVE
with IFF_NO_ADDRCONF.
IFF_SLAVE normally comes with IFF_MASTER, like bonding and eql.
I don't see IFF_MASTER used in netvsc_drv.c, so IFF_SLAVE probably
should be dropped, including the one in __netvsc_vf_setup()?
> > return NOTIFY_DONE;
> > }
> >
> > --
> > 2.50.0
> >
> >
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: microsoft: Add vmbus message-connection-id property
From: Krzysztof Kozlowski @ 2025-07-16 14:35 UTC (permalink / raw)
To: Hardik Garg
Cc: apais, conor+dt, decui, devicetree, haiyangz, hargar, krzk+dt,
kys, linux-hyperv, linux-kernel, robh, ssengar, wei.liu
In-Reply-To: <1752640932-23038-1-git-send-email-hargar@linux.microsoft.com>
On 16/07/2025 06:42, Hardik Garg wrote:
>>>>> What is a connection ID and why it cannot be inferred from existing
>>>>> system API?
>
>>> The connection-id determines which hypervisor communication channel the
>>> guest should use to talk to the VMBus host. Reading from DeviceTree allows
>>> platforms to specify their preferred communication channel, making it more
>>> flexible (I will add this detail in the commit message). Presently, this
>
>>> We don't add properties to make things flexible.
>
> You're right. I should have explained better. The connection ID is a hardware
> configuration detail that defines which specific VMBus channel is used for
> host-guest communication. This value is configured by the host and passed to
> the guest through the host's device tree. Different hypervisor versions and
> configurations may require different channels, and this needs to be specified
> by the platform.
Host is supposed to have multiple guests, so this feels like you are
going to prepare for each guest different DTS with different connection
ID. This feels like poor design. DTS is supposed to be relatively static
configuration, not runtime choice vmguestid+1.
The guest cannot access other configuration channels, can it? If it can,
it would mean it can eavesdrop on other guests? So obviously it cannot.
Therefore from guest point of view this is completely redundant. Guest
cannot use any other value, thus guest should not configure it. The
guest has only one channel and uses only this one which gets to right
place to the host.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3] hv_netvsc: Set VF priv_flags to IFF_NO_ADDRCONF before open to prevent IPv6 addrconf
From: Simon Horman @ 2025-07-16 9:29 UTC (permalink / raw)
To: Li Tian
Cc: netdev, linux-hyperv, linux-kernel, Haiyang Zhang, Dexuan Cui,
Stephen Hemminger, Long Li, Xin Long
In-Reply-To: <20250716002607.4927-1-litian@redhat.com>
+ Xin Long
On Wed, Jul 16, 2025 at 08:26:05AM +0800, Li Tian wrote:
> Set an additional flag IFF_NO_ADDRCONF to prevent ipv6 addrconf.
>
> Commit under Fixes added a new flag change that was not made
> to hv_netvsc resulting in the VF being assinged an IPv6.
>
> Fixes: 8a321cf7becc ("net: add IFF_NO_ADDRCONF and use it in bonding to prevent ipv6 addrconf")
> Suggested-by: Cathy Avery <cavery@redhat.com>
> Signed-off-by: Li Tian <litian@redhat.com>
> ---
> v3:
> - only fixes commit message.
> v2: https://lore.kernel.org/netdev/20250710024603.10162-1-litian@redhat.com/
> - instead of replacing flag, add it.
> v1: https://lore.kernel.org/netdev/20250710024603.10162-1-litian@redhat.com/
> ---
> drivers/net/hyperv/netvsc_drv.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
Hi Li Tian,
Thanks for addressing earlier feedback.
I don't think you need to repost because of this, but for future reference:
1. Because this is a fix for a commit that is present in net
it should be targeted at that tree.
Subject: [PATCH net vX] ...
2. Please use get_maintainers.pl this.patch to generate the CC list. In
this case Xin Long (now CCed) should be included as he is the author of the
patch cited in the Fixes tag.
b4 can help you with this and other aspects of patch management.
>
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index c41a025c66f0..8be9bce66a4e 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -2317,8 +2317,11 @@ static int netvsc_prepare_bonding(struct net_device *vf_netdev)
> if (!ndev)
> return NOTIFY_DONE;
>
> - /* set slave flag before open to prevent IPv6 addrconf */
> + /* Set slave flag and no addrconf flag before open
> + * to prevent IPv6 addrconf.
> + */
> vf_netdev->flags |= IFF_SLAVE;
> + vf_netdev->priv_flags |= IFF_NO_ADDRCONF;
> return NOTIFY_DONE;
> }
>
> --
> 2.50.0
>
>
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: microsoft: Add vmbus message-connection-id property
From: Hardik Garg @ 2025-07-16 4:42 UTC (permalink / raw)
To: krzk
Cc: apais, conor+dt, decui, devicetree, haiyangz, hargar, hargar,
krzk+dt, kys, linux-hyperv, linux-kernel, robh, ssengar, wei.liu
In-Reply-To: <63ca8d08-2fd3-440e-858a-f8d79890016f@kernel.org>
>>>> What is a connection ID and why it cannot be inferred from existing
>>>> system API?
>> The connection-id determines which hypervisor communication channel the
>> guest should use to talk to the VMBus host. Reading from DeviceTree allows
>> platforms to specify their preferred communication channel, making it more
>> flexible (I will add this detail in the commit message). Presently, this
>> We don't add properties to make things flexible.
You're right. I should have explained better. The connection ID is a hardware
configuration detail that defines which specific VMBus channel is used for
host-guest communication. This value is configured by the host and passed to
the guest through the host's device tree. Different hypervisor versions and
configurations may require different channels, and this needs to be specified
by the platform.
>>>> There's a reason why you have here generic property - this is generic
>>>> and/or discoverable and/or whatever software interface. Adding now more
>>>> properties, just because you made it generic, is not the way.
>> Presently the value is hardcoded and we want to provide a functionality to
>> the user to specify their prefered communication channel. This is a
>> virtualized hardware property for us.
>> That's not really acceptable reason. With such approach I would add 100
>> properties to make various things "flexible".
I understand your concern. Let me clarify: this isn't about making things
flexible for flexibility's sake. The connection ID is a fundamental hardware
configuration parameter that is set by the host and must be matched in the
guest. The host configures this value in its device tree and shares it with
the guest. Without the correct channel ID, the VMBus communication fails.
Different hypervisor configurations require different channels, and this
cannot be automatically discovered.
Would you prefer if we handled this configuration through a different
mechanism? I'm open to suggestions.
Thanks,
Hardik
^ permalink raw reply
* [PATCH v3] hv_netvsc: Set VF priv_flags to IFF_NO_ADDRCONF before open to prevent IPv6 addrconf
From: Li Tian @ 2025-07-16 0:26 UTC (permalink / raw)
To: netdev, linux-hyperv
Cc: linux-kernel, Haiyang Zhang, Dexuan Cui, Stephen Hemminger,
Long Li
Set an additional flag IFF_NO_ADDRCONF to prevent ipv6 addrconf.
Commit under Fixes added a new flag change that was not made
to hv_netvsc resulting in the VF being assinged an IPv6.
Fixes: 8a321cf7becc ("net: add IFF_NO_ADDRCONF and use it in bonding to prevent ipv6 addrconf")
Suggested-by: Cathy Avery <cavery@redhat.com>
Signed-off-by: Li Tian <litian@redhat.com>
---
v3:
- only fixes commit message.
v2: https://lore.kernel.org/netdev/20250710024603.10162-1-litian@redhat.com/
- instead of replacing flag, add it.
v1: https://lore.kernel.org/netdev/20250710024603.10162-1-litian@redhat.com/
---
drivers/net/hyperv/netvsc_drv.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index c41a025c66f0..8be9bce66a4e 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -2317,8 +2317,11 @@ static int netvsc_prepare_bonding(struct net_device *vf_netdev)
if (!ndev)
return NOTIFY_DONE;
- /* set slave flag before open to prevent IPv6 addrconf */
+ /* Set slave flag and no addrconf flag before open
+ * to prevent IPv6 addrconf.
+ */
vf_netdev->flags |= IFF_SLAVE;
+ vf_netdev->priv_flags |= IFF_NO_ADDRCONF;
return NOTIFY_DONE;
}
--
2.50.0
^ permalink raw reply related
* Re: [PATCH hyperv-next v4 05/16] Drivers: hv: Rename fields for SynIC message and event pages
From: kernel test robot @ 2025-07-15 21:46 UTC (permalink / raw)
To: Roman Kisel, alok.a.tiwari, arnd, bp, corbet, dave.hansen, decui,
haiyangz, hpa, kys, mhklinux, mingo, rdunlap, tglx, Tianyu.Lan,
wei.liu, linux-arch, linux-coco, linux-doc, linux-hyperv,
linux-kernel, x86
Cc: oe-kbuild-all, apais, benhill, bperkins, sunilmut
In-Reply-To: <20250714221545.5615-6-romank@linux.microsoft.com>
Hi Roman,
kernel test robot noticed the following build warnings:
[auto build test WARNING on d9016a249be5316ec2476f9947356711e70a16ec]
url: https://github.com/intel-lab-lkp/linux/commits/Roman-Kisel/Documentation-hyperv-Confidential-VMBus/20250715-062125
base: d9016a249be5316ec2476f9947356711e70a16ec
patch link: https://lore.kernel.org/r/20250714221545.5615-6-romank%40linux.microsoft.com
patch subject: [PATCH hyperv-next v4 05/16] Drivers: hv: Rename fields for SynIC message and event pages
config: i386-randconfig-061-20250715 (https://download.01.org/0day-ci/archive/20250716/202507160553.amoW6Ty0-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14+deb12u1) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250716/202507160553.amoW6Ty0-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202507160553.amoW6Ty0-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
drivers/hv/hv.c:280:26: sparse: sparse: cast removes address space '__iomem' of expression
drivers/hv/hv.c:299:26: sparse: sparse: cast removes address space '__iomem' of expression
>> drivers/hv/hv.c:361:31: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void *hyp_synic_message_page @@
drivers/hv/hv.c:361:31: sparse: expected void volatile [noderef] __iomem *addr
drivers/hv/hv.c:361:31: sparse: got void *hyp_synic_message_page
>> drivers/hv/hv.c:373:31: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void *hyp_synic_event_page @@
drivers/hv/hv.c:373:31: sparse: expected void volatile [noderef] __iomem *addr
drivers/hv/hv.c:373:31: sparse: got void *hyp_synic_event_page
vim +361 drivers/hv/hv.c
334
335 void hv_synic_disable_regs(unsigned int cpu)
336 {
337 struct hv_per_cpu_context *hv_cpu =
338 per_cpu_ptr(hv_context.cpu_context, cpu);
339 union hv_synic_sint shared_sint;
340 union hv_synic_simp simp;
341 union hv_synic_siefp siefp;
342 union hv_synic_scontrol sctrl;
343
344 shared_sint.as_uint64 = hv_get_msr(HV_MSR_SINT0 + VMBUS_MESSAGE_SINT);
345
346 shared_sint.masked = 1;
347
348 /* Need to correctly cleanup in the case of SMP!!! */
349 /* Disable the interrupt */
350 hv_set_msr(HV_MSR_SINT0 + VMBUS_MESSAGE_SINT, shared_sint.as_uint64);
351
352 simp.as_uint64 = hv_get_msr(HV_MSR_SIMP);
353 /*
354 * In Isolation VM, sim and sief pages are allocated by
355 * paravisor. These pages also will be used by kdump
356 * kernel. So just reset enable bit here and keep page
357 * addresses.
358 */
359 simp.simp_enabled = 0;
360 if (ms_hyperv.paravisor_present || hv_root_partition()) {
> 361 iounmap(hv_cpu->hyp_synic_message_page);
362 hv_cpu->hyp_synic_message_page = NULL;
363 } else {
364 simp.base_simp_gpa = 0;
365 }
366
367 hv_set_msr(HV_MSR_SIMP, simp.as_uint64);
368
369 siefp.as_uint64 = hv_get_msr(HV_MSR_SIEFP);
370 siefp.siefp_enabled = 0;
371
372 if (ms_hyperv.paravisor_present || hv_root_partition()) {
> 373 iounmap(hv_cpu->hyp_synic_event_page);
374 hv_cpu->hyp_synic_event_page = NULL;
375 } else {
376 siefp.base_siefp_gpa = 0;
377 }
378
379 hv_set_msr(HV_MSR_SIEFP, siefp.as_uint64);
380
381 /* Disable the global synic bit */
382 sctrl.as_uint64 = hv_get_msr(HV_MSR_SCONTROL);
383 sctrl.enable = 0;
384 hv_set_msr(HV_MSR_SCONTROL, sctrl.as_uint64);
385
386 if (vmbus_irq != -1)
387 disable_percpu_irq(vmbus_irq);
388 }
389
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2 2/2] x86/hyperv: Switch to msi_create_parent_irq_domain()
From: Nuno Das Neves @ 2025-07-15 19:09 UTC (permalink / raw)
To: Wei Liu, Nam Cao
Cc: K . Y . Srinivasan, Marc Zyngier, Haiyang Zhang, Dexuan Cui,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H . Peter Anvin, linux-hyperv, linux-kernel
In-Reply-To: <aG7932u1SvvAYh2l@liuwe-devbox-ubuntu-v2.lamzopl0uupeniq2etz1fddiyg.xx.internal.cloudapp.net>
On 7/9/2025 4:40 PM, Wei Liu wrote:
> CC Nuno who is also touching on this file.
>
> Nam, thanks for this patch.
>
> Nuno's patches fix a few bugs with the current implementation. I expect
> those patches to have contextual conflicts with this patch. I would like
> to commit Nuno's patches first since those are bug fixes, and then
> circle back to this one.
>
> Nuno, can you please review this patch?
>
I don't think I can give a Reviewed-by since I don't have the context
for these changes.
It doesn't look like this conflicts with the changes in my patches.
The TODO looks fine to me, it can be addressed in a followup.
Nuno
> On Mon, Jun 30, 2025 at 12:26:15PM +0200, Nam Cao wrote:
>> Move away from the legacy MSI domain setup, switch to use
>> msi_create_parent_irq_domain().
>>
>> While doing the conversion, I noticed that hv_irq_compose_msi_msg() is
>> doing more than it is supposed to (composing message content). The
>> interrupt allocation bits should be moved into hv_msi_domain_alloc().
>> However, I have no hardware to test this change, therefore I leave a TODO
>> note.
>>
>> Signed-off-by: Nam Cao <namcao@linutronix.de>
>> ---
>> arch/x86/hyperv/irqdomain.c | 111 ++++++++++++++++++++++++------------
>> drivers/hv/Kconfig | 1 +
>> 2 files changed, 77 insertions(+), 35 deletions(-)
>>
>> diff --git a/arch/x86/hyperv/irqdomain.c b/arch/x86/hyperv/irqdomain.c
>> index 31f0d29cbc5e3..9b3b65ffbd2e2 100644
>> --- a/arch/x86/hyperv/irqdomain.c
>> +++ b/arch/x86/hyperv/irqdomain.c
>> @@ -10,6 +10,7 @@
>>
>> #include <linux/pci.h>
>> #include <linux/irq.h>
>> +#include <linux/irqchip/irq-msi-lib.h>
>> #include <asm/mshyperv.h>
>>
>> static int hv_map_interrupt(union hv_device_id device_id, bool level,
>> @@ -276,59 +277,99 @@ static void hv_teardown_msi_irq(struct pci_dev *dev, struct irq_data *irqd)
>> hv_status_err(status, "\n");
>> }
>>
>> -static void hv_msi_free_irq(struct irq_domain *domain,
>> - struct msi_domain_info *info, unsigned int virq)
>> -{
>> - struct irq_data *irqd = irq_get_irq_data(virq);
>> - struct msi_desc *desc;
>> -
>> - if (!irqd)
>> - return;
>> -
>> - desc = irq_data_get_msi_desc(irqd);
>> - if (!desc || !desc->irq || WARN_ON_ONCE(!dev_is_pci(desc->dev)))
>> - return;
>> -
>> - hv_teardown_msi_irq(to_pci_dev(desc->dev), irqd);
>> -}
>> -
>> /*
>> * IRQ Chip for MSI PCI/PCI-X/PCI-Express Devices,
>> * which implement the MSI or MSI-X Capability Structure.
>> */
>> static struct irq_chip hv_pci_msi_controller = {
>> .name = "HV-PCI-MSI",
>> - .irq_unmask = pci_msi_unmask_irq,
>> - .irq_mask = pci_msi_mask_irq,
>> .irq_ack = irq_chip_ack_parent,
>> - .irq_retrigger = irq_chip_retrigger_hierarchy,
>> .irq_compose_msi_msg = hv_irq_compose_msi_msg,
>> - .irq_set_affinity = msi_domain_set_affinity,
>> - .flags = IRQCHIP_SKIP_SET_WAKE | IRQCHIP_MOVE_DEFERRED,
>> + .irq_set_affinity = irq_chip_set_affinity_parent,
>> };
>>
>> -static struct msi_domain_ops pci_msi_domain_ops = {
>> - .msi_free = hv_msi_free_irq,
>> - .msi_prepare = pci_msi_prepare,
>> +static bool hv_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;
>> +
>> + chip->flags |= IRQCHIP_SKIP_SET_WAKE | IRQCHIP_MOVE_DEFERRED;
>> +
>> + info->ops->msi_prepare = pci_msi_prepare;
>> +
>> + return true;
>> +}
>> +
>> +#define HV_MSI_FLAGS_SUPPORTED (MSI_GENERIC_FLAGS_MASK | MSI_FLAG_PCI_MSIX)
>> +#define HV_MSI_FLAGS_REQUIRED (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS)
>> +
>> +static struct msi_parent_ops hv_msi_parent_ops = {
>> + .supported_flags = HV_MSI_FLAGS_SUPPORTED,
>> + .required_flags = HV_MSI_FLAGS_REQUIRED,
>> + .bus_select_token = DOMAIN_BUS_NEXUS,
>> + .bus_select_mask = MATCH_PCI_MSI,
>> + .chip_flags = MSI_CHIP_FLAG_SET_ACK,
>> + .prefix = "HV-",
>> + .init_dev_msi_info = hv_init_dev_msi_info,
>> };
>>
>> -static struct msi_domain_info hv_pci_msi_domain_info = {
>> - .flags = MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
>> - MSI_FLAG_PCI_MSIX,
>> - .ops = &pci_msi_domain_ops,
>> - .chip = &hv_pci_msi_controller,
>> - .handler = handle_edge_irq,
>> - .handler_name = "edge",
>> +static int hv_msi_domain_alloc(struct irq_domain *d, unsigned int virq, unsigned int nr_irqs,
>> + void *arg)
>> +{
>> + /*
>> + * TODO: The allocation bits of hv_irq_compose_msi_msg(), i.e. everything except
>> + * entry_to_msi_msg() should be in here.
>> + */
>> +
>> + int ret;
>> +
>> + ret = irq_domain_alloc_irqs_parent(d, virq, nr_irqs, arg);
>> + if (ret)
>> + return ret;
>> +
>> + for (int i = 0; i < nr_irqs; ++i) {
>> + irq_domain_set_info(d, virq + i, 0, &hv_pci_msi_controller, NULL,
>> + handle_edge_irq, NULL, "edge");
>> + }
>> + return 0;
>> +}
>> +
>> +static void hv_msi_domain_free(struct irq_domain *d, unsigned int virq, unsigned int nr_irqs)
>> +{
>> + for (int i = 0; i < nr_irqs; ++i) {
>> + struct irq_data *irqd = irq_domain_get_irq_data(d, virq);
>> + struct msi_desc *desc;
>> +
>> + desc = irq_data_get_msi_desc(irqd);
>> + if (!desc || !desc->irq || WARN_ON_ONCE(!dev_is_pci(desc->dev)))
>> + continue;
>> +
>> + hv_teardown_msi_irq(to_pci_dev(desc->dev), irqd);
>> + }
>> + irq_domain_free_irqs_top(d, virq, nr_irqs);
>> +}
>> +
>> +static const struct irq_domain_ops hv_msi_domain_ops = {
>> + .select = msi_lib_irq_domain_select,
>> + .alloc = hv_msi_domain_alloc,
>> + .free = hv_msi_domain_free,
>> };
>>
>> struct irq_domain * __init hv_create_pci_msi_domain(void)
>> {
>> struct irq_domain *d = NULL;
>> - struct fwnode_handle *fn;
>>
>> - fn = irq_domain_alloc_named_fwnode("HV-PCI-MSI");
>> - if (fn)
>> - d = pci_msi_create_irq_domain(fn, &hv_pci_msi_domain_info, x86_vector_domain);
>> + struct irq_domain_info info = {
>> + .fwnode = irq_domain_alloc_named_fwnode("HV-PCI-MSI"),
>> + .ops = &hv_msi_domain_ops,
>> + .parent = x86_vector_domain,
>> + };
>> +
>> + if (info.fwnode)
>> + d = msi_create_parent_irq_domain(&info, &hv_msi_parent_ops);
>>
>> /* No point in going further if we can't get an irq domain */
>> BUG_ON(!d);
>> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
>> index 1cd188b73b743..e62a0f8b34198 100644
>> --- a/drivers/hv/Kconfig
>> +++ b/drivers/hv/Kconfig
>> @@ -10,6 +10,7 @@ config HYPERV
>> select X86_HV_CALLBACK_VECTOR if X86
>> select OF_EARLY_FLATTREE if OF
>> select SYSFB if !HYPERV_VTL_MODE
>> + select IRQ_MSI_LIB if X86
>> help
>> Select this option to run Linux as a Hyper-V client operating
>> system.
>> --
>> 2.39.5
>>
^ permalink raw reply
* Re: [PATCH hyperv-next v4 04/16] arch/x86: mshyperv: Trap on access for some synthetic MSRs
From: kernel test robot @ 2025-07-15 17:58 UTC (permalink / raw)
To: Roman Kisel, alok.a.tiwari, arnd, bp, corbet, dave.hansen, decui,
haiyangz, hpa, kys, mhklinux, mingo, rdunlap, tglx, Tianyu.Lan,
wei.liu, linux-arch, linux-coco, linux-doc, linux-hyperv,
linux-kernel, x86
Cc: oe-kbuild-all, apais, benhill, bperkins, sunilmut
In-Reply-To: <20250714221545.5615-5-romank@linux.microsoft.com>
Hi Roman,
kernel test robot noticed the following build errors:
[auto build test ERROR on d9016a249be5316ec2476f9947356711e70a16ec]
url: https://github.com/intel-lab-lkp/linux/commits/Roman-Kisel/Documentation-hyperv-Confidential-VMBus/20250715-062125
base: d9016a249be5316ec2476f9947356711e70a16ec
patch link: https://lore.kernel.org/r/20250714221545.5615-5-romank%40linux.microsoft.com
patch subject: [PATCH hyperv-next v4 04/16] arch/x86: mshyperv: Trap on access for some synthetic MSRs
config: x86_64-buildonly-randconfig-002-20250715 (https://download.01.org/0day-ci/archive/20250716/202507160105.yQ34bnKl-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14+deb12u1) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250716/202507160105.yQ34bnKl-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202507160105.yQ34bnKl-lkp@intel.com/
All errors (new ones prefixed by >>):
ld: vmlinux.o: in function `hv_set_non_nested_msr':
>> arch/x86/kernel/cpu/mshyperv.c:91: undefined reference to `vmbus_is_confidential'
vim +91 arch/x86/kernel/cpu/mshyperv.c
79
80 void hv_set_non_nested_msr(unsigned int reg, u64 value)
81 {
82 if (hv_is_synic_msr(reg) && ms_hyperv.paravisor_present) {
83 /* The hypervisor will get the intercept. */
84 hv_ivm_msr_write(reg, value);
85
86 if (hv_is_sint_msr(reg)) {
87 /*
88 * Write proxy bit in the case of non-confidential VMBus.
89 * Using wrmsrq instruction so the following goes to the paravisor.
90 */
> 91 u32 proxy = vmbus_is_confidential() ? 0 : 1;
92
93 value |= (proxy << 20);
94 native_wrmsrq(reg, value);
95 }
96 } else {
97 native_wrmsrq(reg, value);
98 }
99 }
100 EXPORT_SYMBOL_GPL(hv_set_non_nested_msr);
101
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] mshv_eventfd: convert to CLASS(fd)
From: Nuno Das Neves @ 2025-07-15 17:15 UTC (permalink / raw)
To: Al Viro, linux-fsdevel; +Cc: linux-hyperv
In-Reply-To: <20250712165244.GA1880847@ZenIV>
On 7/12/2025 9:52 AM, Al Viro wrote:
> [in viro/vfs.git #work.fd; if nobody objects, into #for-next it goes...]
>
> similar to 66635b077624 ("assorted variants of irqfd setup: convert
> to CLASS(fd)") a year ago...
>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> ---
> diff --git a/drivers/hv/mshv_eventfd.c b/drivers/hv/mshv_eventfd.c
> index 8dd22be2ca0b..48c514da34eb 100644
> --- a/drivers/hv/mshv_eventfd.c
> +++ b/drivers/hv/mshv_eventfd.c
> @@ -377,10 +377,11 @@ static int mshv_irqfd_assign(struct mshv_partition *pt,
> struct eventfd_ctx *eventfd = NULL, *resamplefd = NULL;
> struct mshv_irqfd *irqfd, *tmp;
> unsigned int events;
> - struct fd f;
> int ret;
> int idx;
>
> + CLASS(fd, f)(args->fd);
> +
> irqfd = kzalloc(sizeof(*irqfd), GFP_KERNEL);
> if (!irqfd)
> return -ENOMEM;
> @@ -390,8 +391,7 @@ static int mshv_irqfd_assign(struct mshv_partition *pt,
> INIT_WORK(&irqfd->irqfd_shutdown, mshv_irqfd_shutdown);
> seqcount_spinlock_init(&irqfd->irqfd_irqe_sc, &pt->pt_irqfds_lock);
>
> - f = fdget(args->fd);
> - if (!fd_file(f)) {
> + if (fd_empty(f)) {
> ret = -EBADF;
> goto out;
> }
> @@ -496,12 +496,6 @@ static int mshv_irqfd_assign(struct mshv_partition *pt,
> mshv_assert_irq_slow(irqfd);
>
> srcu_read_unlock(&pt->pt_irq_srcu, idx);
> - /*
> - * do not drop the file until the irqfd is fully initialized, otherwise
> - * we might race against the POLLHUP
> - */
> - fdput(f);
> -
> return 0;
>
> fail:
> @@ -514,8 +508,6 @@ static int mshv_irqfd_assign(struct mshv_partition *pt,
> if (eventfd && !IS_ERR(eventfd))
> eventfd_ctx_put(eventfd);
>
> - fdput(f);
> -
> out:
> kfree(irqfd);
> return ret;
Looks fine to me, thanks.
Reviewed-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
^ permalink raw reply
* RE: [EXTERNAL] Re: [PATCH net] hv_netvsc: Switch VF namespace in netvsc_open instead
From: Haiyang Zhang @ 2025-07-15 15:49 UTC (permalink / raw)
To: Jakub Kicinski, Haiyang Zhang
Cc: linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
KY Srinivasan, wei.liu@kernel.org, Dexuan Cui,
edumazet@google.com, pabeni@redhat.com,
stephen@networkplumber.org, davem@davemloft.net,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <20250714182914.27c94a91@kernel.org>
> -----Original Message-----
> From: Jakub Kicinski <kuba@kernel.org>
> Sent: Monday, July 14, 2025 9:29 PM
> To: Haiyang Zhang <haiyangz@linux.microsoft.com>
> Cc: linux-hyperv@vger.kernel.org; netdev@vger.kernel.org; Haiyang Zhang
> <haiyangz@microsoft.com>; KY Srinivasan <kys@microsoft.com>;
> wei.liu@kernel.org; Dexuan Cui <decui@microsoft.com>; edumazet@google.com;
> pabeni@redhat.com; stephen@networkplumber.org; davem@davemloft.net; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org
> Subject: [EXTERNAL] Re: [PATCH net] hv_netvsc: Switch VF namespace in
> netvsc_open instead
>
> On Fri, 11 Jul 2025 13:57:10 -0700 Haiyang Zhang wrote:
> > The existing code move the VF NIC to new namespace when NETDEV_REGISTER
> is
> > received on netvsc NIC. During deletion of the namespace,
> > default_device_exit_batch() >> default_device_exit_net() is called. When
> > netvsc NIC is moved back and registered to the default namespace, it
> > automatically brings VF NIC back to the default namespace. This will
> cause
> > the default_device_exit_net() >> for_each_netdev_safe loop unable to
> detect
> > the list end, and hit NULL ptr:
>
> Are you saying that when netns is dismantled both devices are listed
> for moving back to default, but the netvsc_event_set_vf_ns() logic
> tries to undo the move / move the VF before the netns dismantle loop
> got to it?
netvsc_event_set_vf_ns() moves the VF to default ns before the netns
dismantle loop got to it, and causes the Null prt error.
> This needs a better fix, moving on open is way too hacky.
> Perhaps we should start with reverting 4c262801ea60 and then trying
> to implement it in a more robust way?
This patch reverts the 4c262801ea60, and moves the logic to netvsc_open().
I was thinking some other ways too... But seems I couldn't find a way
to know it's in the for_each_netdev_safe loop, and to skip moving the
VF in netvsc_event_set_vf_ns() this case.
Thanks,
- Haiyang
^ permalink raw reply
* RE: [EXTERNAL] Re: [PATCH net,v2] hv_netvsc: Switch VF namespace in netvsc_open instead
From: Haiyang Zhang @ 2025-07-15 15:30 UTC (permalink / raw)
To: Simon Horman, Haiyang Zhang
Cc: linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
KY Srinivasan, wei.liu@kernel.org, Dexuan Cui,
andrew+netdev@lunn.ch, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, davem@davemloft.net,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
cavery@redhat.com
In-Reply-To: <20250715130547.GV721198@horms.kernel.org>
> -----Original Message-----
> From: Simon Horman <horms@kernel.org>
> Sent: Tuesday, July 15, 2025 9:06 AM
> To: Haiyang Zhang <haiyangz@linux.microsoft.com>
> Cc: linux-hyperv@vger.kernel.org; netdev@vger.kernel.org; Haiyang Zhang
> <haiyangz@microsoft.com>; KY Srinivasan <kys@microsoft.com>;
> wei.liu@kernel.org; Dexuan Cui <decui@microsoft.com>;
> andrew+netdev@lunn.ch; edumazet@google.com; kuba@kernel.org;
> pabeni@redhat.com; davem@davemloft.net; linux-kernel@vger.kernel.org;
> stable@vger.kernel.org; cavery@redhat.com
> Subject: [EXTERNAL] Re: [PATCH net,v2] hv_netvsc: Switch VF namespace in
> netvsc_open instead
>
> On Mon, Jul 14, 2025 at 09:41:37AM -0700, Haiyang Zhang wrote:
> > From: Haiyang Zhang <haiyangz@microsoft.com>
> >
> > The existing code move the VF NIC to new namespace when NETDEV_REGISTER
> is
> > received on netvsc NIC. During deletion of the namespace,
> > default_device_exit_batch() >> default_device_exit_net() is called. When
> > netvsc NIC is moved back and registered to the default namespace, it
> > automatically brings VF NIC back to the default namespace. This will
> cause
> > the default_device_exit_net() >> for_each_netdev_safe loop unable to
> detect
> > the list end, and hit NULL ptr:
> >
> > [ 231.449420] mana 7870:00:00.0 enP30832s1: Moved VF to namespace with:
> eth0
> > [ 231.449656] BUG: kernel NULL pointer dereference, address:
> 0000000000000010
> > [ 231.450246] #PF: supervisor read access in kernel mode
> > [ 231.450579] #PF: error_code(0x0000) - not-present page
> > [ 231.450916] PGD 17b8a8067 P4D 0
> > [ 231.451163] Oops: Oops: 0000 [#1] SMP NOPTI
> > [ 231.451450] CPU: 82 UID: 0 PID: 1394 Comm: kworker/u768:1 Not tainted
> 6.16.0-rc4+ #3 VOLUNTARY
> > [ 231.452042] Hardware name: Microsoft Corporation Virtual
> Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024
> > [ 231.452692] Workqueue: netns cleanup_net
> > [ 231.452947] RIP: 0010:default_device_exit_batch+0x16c/0x3f0
> > [ 231.453326] Code: c0 0c f5 b3 e8 d5 db fe ff 48 85 c0 74 15 48 c7 c2
> f8 fd ca b2 be 10 00 00 00 48 8d 7d c0 e8 7b 77 25 00 49 8b 86 28 01 00 00
> <48> 8b 50 10 4c 8b 2a 4c 8d 62 f0 49 83 ed 10 4c 39 e0 0f 84 d6 00
> > [ 231.454294] RSP: 0018:ff75fc7c9bf9fd00 EFLAGS: 00010246
> > [ 231.454610] RAX: 0000000000000000 RBX: 0000000000000002 RCX:
> 61c8864680b583eb
> > [ 231.455094] RDX: ff1fa9f71462d800 RSI: ff75fc7c9bf9fd38 RDI:
> 0000000030766564
> > [ 231.455686] RBP: ff75fc7c9bf9fd78 R08: 0000000000000000 R09:
> 0000000000000000
> > [ 231.456126] R10: 0000000000000001 R11: 0000000000000004 R12:
> ff1fa9f70088e340
> > [ 231.456621] R13: ff1fa9f70088e340 R14: ffffffffb3f50c20 R15:
> ff1fa9f7103e6340
> > [ 231.457161] FS: 0000000000000000(0000) GS:ff1faa6783a08000(0000)
> knlGS:0000000000000000
> > [ 231.457707] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 231.458031] CR2: 0000000000000010 CR3: 0000000179ab2006 CR4:
> 0000000000b73ef0
> > [ 231.458434] Call Trace:
> > [ 231.458600] <TASK>
> > [ 231.458777] ops_undo_list+0x100/0x220
> > [ 231.459015] cleanup_net+0x1b8/0x300
> > [ 231.459285] process_one_work+0x184/0x340
> >
> > To fix it, move the VF namespace switching code from the NETDEV_REGISTER
> > event handler to netvsc_open().
> >
> > Cc: stable@vger.kernel.org
> > Cc: cavery@redhat.com
> > Fixes: 4c262801ea60 ("hv_netvsc: Fix VF namespace also in synthetic NIC
> NETDEV_REGISTER event")
> > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
>
> With this change do we go back to the situation that existed prior
> to the cited patch? Quoting the cited commit:
>
> The existing code moves VF to the same namespace as the synthetic NIC
> during netvsc_register_vf(). But, if the synthetic device is moved to
> a
> new namespace after the VF registration, the VF won't be moved
> together.
>
> Or perhaps not because if synthetic device is moved then, in practice, it
> will subsequently be reopened? (Because it is closed as part of the move
> to a different netns?)
There are two cases:
1) the synthetic device is moved to a new namespace before the VF device is
offered from PCI:
During netvsc_register_vf() >> dev_change_net_namespace() will put VF to
the same namespace.
2) the synthetic device is moved to a new namespace after the VF device is
offered from PCI:
The commit 4c262801ea60 does the move in netvsc_event_set_vf_ns >> dev_change_net_namespace().
But it will cause Null ptr error during namespace deletion >> default_device_exit_net().
This patch keeps the code path (1) unchanged, and fix the code path (2).
And yes, __dev_change_net_namespace() >> netif_close(dev), so in the new
namespace the NIC always needs to be re-opened before using.
Thanks,
- Haiyang
^ permalink raw reply
* RE: [PATCH v3 12/16] x86_64,hyperv: Use direct call to hypercall-page
From: Michael Kelley @ 2025-07-15 14:52 UTC (permalink / raw)
To: Peter Zijlstra, x86@kernel.org
Cc: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com,
seanjc@google.com, pbonzini@redhat.com, ardb@kernel.org,
kees@kernel.org, Arnd Bergmann, gregkh@linuxfoundation.org,
jpoimboe@kernel.org, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
linux-efi@vger.kernel.org, samitolvanen@google.com,
ojeda@kernel.org
In-Reply-To: <20250714103441.011387946@infradead.org>
From: Peter Zijlstra <peterz@infradead.org> Sent: Monday, July 14, 2025 3:20 AM
>
Same nit here: Use "x86/hyperv:" as the Subject prefix, for consistency with
past practice.
Michael
> Instead of using an indirect call to the hypercall page, use a direct
> call instead. This avoids all CFI problems, including the one where
> the hypercall page doesn't have IBT on.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Reviewed-by: Michael Kelley <mhklinux@outlook.com>
> ---
> arch/x86/hyperv/hv_init.c | 61 ++++++++++++++++++++++------------------------
> 1 file changed, 30 insertions(+), 31 deletions(-)
>
> --- a/arch/x86/hyperv/hv_init.c
> +++ b/arch/x86/hyperv/hv_init.c
> @@ -17,7 +17,6 @@
> #include <asm/desc.h>
> #include <asm/e820/api.h>
> #include <asm/sev.h>
> -#include <asm/ibt.h>
> #include <asm/hypervisor.h>
> #include <hyperv/hvhdk.h>
> #include <asm/mshyperv.h>
> @@ -38,23 +37,41 @@
> void *hv_hypercall_pg;
>
> #ifdef CONFIG_X86_64
> +static u64 __hv_hyperfail(u64 control, u64 param1, u64 param2)
> +{
> + return U64_MAX;
> +}
> +
> +DEFINE_STATIC_CALL(__hv_hypercall, __hv_hyperfail);
> +
> u64 hv_std_hypercall(u64 control, u64 param1, u64 param2)
> {
> u64 hv_status;
>
> - if (!hv_hypercall_pg)
> - return U64_MAX;
> -
> register u64 __r8 asm("r8") = param2;
> - asm volatile (CALL_NOSPEC
> + asm volatile ("call " STATIC_CALL_TRAMP_STR(__hv_hypercall)
> : "=a" (hv_status), ASM_CALL_CONSTRAINT,
> "+c" (control), "+d" (param1), "+r" (__r8)
> - : THUNK_TARGET(hv_hypercall_pg)
> - : "cc", "memory", "r9", "r10", "r11");
> + : : "cc", "memory", "r9", "r10", "r11");
>
> return hv_status;
> }
> +
> +typedef u64 (*hv_hypercall_f)(u64 control, u64 param1, u64 param2);
> +
> +static inline void hv_set_hypercall_pg(void *ptr)
> +{
> + hv_hypercall_pg = ptr;
> +
> + if (!ptr)
> + ptr = &__hv_hyperfail;
> + static_call_update(__hv_hypercall, (hv_hypercall_f)ptr);
> +}
> #else
> +static inline void hv_set_hypercall_pg(void *ptr)
> +{
> + hv_hypercall_pg = ptr;
> +}
> EXPORT_SYMBOL_GPL(hv_hypercall_pg);
> #endif
>
> @@ -349,7 +366,7 @@ static int hv_suspend(void)
> * pointer is restored on resume.
> */
> hv_hypercall_pg_saved = hv_hypercall_pg;
> - hv_hypercall_pg = NULL;
> + hv_set_hypercall_pg(NULL);
>
> /* Disable the hypercall page in the hypervisor */
> rdmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
> @@ -375,7 +392,7 @@ static void hv_resume(void)
> vmalloc_to_pfn(hv_hypercall_pg_saved);
> wrmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
>
> - hv_hypercall_pg = hv_hypercall_pg_saved;
> + hv_set_hypercall_pg(hv_hypercall_pg_saved);
> hv_hypercall_pg_saved = NULL;
>
> /*
> @@ -529,8 +546,8 @@ void __init hyperv_init(void)
> if (hv_isolation_type_tdx() && !ms_hyperv.paravisor_present)
> goto skip_hypercall_pg_init;
>
> - hv_hypercall_pg = __vmalloc_node_range(PAGE_SIZE, 1, VMALLOC_START,
> - VMALLOC_END, GFP_KERNEL, PAGE_KERNEL_ROX,
> + hv_hypercall_pg = __vmalloc_node_range(PAGE_SIZE, 1, MODULES_VADDR,
> + MODULES_END, GFP_KERNEL, PAGE_KERNEL_ROX,
> VM_FLUSH_RESET_PERMS, NUMA_NO_NODE,
> __builtin_return_address(0));
> if (hv_hypercall_pg == NULL)
> @@ -568,27 +585,9 @@ void __init hyperv_init(void)
> wrmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
> }
>
> -skip_hypercall_pg_init:
> - /*
> - * Some versions of Hyper-V that provide IBT in guest VMs have a bug
> - * in that there's no ENDBR64 instruction at the entry to the
> - * hypercall page. Because hypercalls are invoked via an indirect call
> - * to the hypercall page, all hypercall attempts fail when IBT is
> - * enabled, and Linux panics. For such buggy versions, disable IBT.
> - *
> - * Fixed versions of Hyper-V always provide ENDBR64 on the hypercall
> - * page, so if future Linux kernel versions enable IBT for 32-bit
> - * builds, additional hypercall page hackery will be required here
> - * to provide an ENDBR32.
> - */
> -#ifdef CONFIG_X86_KERNEL_IBT
> - if (cpu_feature_enabled(X86_FEATURE_IBT) &&
> - *(u32 *)hv_hypercall_pg != gen_endbr()) {
> - setup_clear_cpu_cap(X86_FEATURE_IBT);
> - pr_warn("Disabling IBT because of Hyper-V bug\n");
> - }
> -#endif
> + hv_set_hypercall_pg(hv_hypercall_pg);
>
> +skip_hypercall_pg_init:
> /*
> * hyperv_init() is called before LAPIC is initialized: see
> * apic_intr_mode_init() -> x86_platform.apic_post_init() and
>
^ permalink raw reply
* RE: [PATCH v3 11/16] x86,hyperv: Clean up hv_do_hypercall()
From: Michael Kelley @ 2025-07-15 14:51 UTC (permalink / raw)
To: Peter Zijlstra, x86@kernel.org
Cc: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com,
seanjc@google.com, pbonzini@redhat.com, ardb@kernel.org,
kees@kernel.org, Arnd Bergmann, gregkh@linuxfoundation.org,
jpoimboe@kernel.org, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
linux-efi@vger.kernel.org, samitolvanen@google.com,
ojeda@kernel.org
In-Reply-To: <20250714103440.897136093@infradead.org>
From: Peter Zijlstra <peterz@infradead.org> Sent: Monday, July 14, 2025 3:20 AM
>
Nit: For the patch "Subject", the prefix should be "x86/hyperv:" for
consistency with past practice. There's definitely been some variation
over time, but "x86/hyperv:" has been the most consistently used, and
that's what I try to remind people to use.
Michael
> What used to be a simple few instructions has turned into a giant mess
> (for x86_64). Not only does it use static_branch wrong, it mixes it
> with dynamic branches for no apparent reason.
>
> Notably it uses static_branch through an out-of-line function call,
> which completely defeats the purpose, since instead of a simple
> JMP/NOP site, you get a CALL+RET+TEST+Jcc sequence in return, which is
> absolutely idiotic.
>
> Add to that a dynamic test of hyperv_paravisor_present, something
> which is set once and never changed.
>
> Replace all this idiocy with a single direct function call to the
> right hypercall variant.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Tested-by: Michael Kelley <mhklinux@outlook.com>
> Reviewed-by: Michael Kelley <mhklinux@outlook.com>
> ---
> arch/x86/hyperv/hv_init.c | 20 +++++
> arch/x86/hyperv/ivm.c | 15 ++++
> arch/x86/include/asm/mshyperv.h | 137 +++++++++++-----------------------------
> arch/x86/kernel/cpu/mshyperv.c | 19 +++--
> 4 files changed, 89 insertions(+), 102 deletions(-)
>
> --- a/arch/x86/hyperv/hv_init.c
> +++ b/arch/x86/hyperv/hv_init.c
> @@ -36,7 +36,27 @@
> #include <linux/highmem.h>
>
> void *hv_hypercall_pg;
> +
> +#ifdef CONFIG_X86_64
> +u64 hv_std_hypercall(u64 control, u64 param1, u64 param2)
> +{
> + u64 hv_status;
> +
> + if (!hv_hypercall_pg)
> + return U64_MAX;
> +
> + register u64 __r8 asm("r8") = param2;
> + asm volatile (CALL_NOSPEC
> + : "=a" (hv_status), ASM_CALL_CONSTRAINT,
> + "+c" (control), "+d" (param1), "+r" (__r8)
> + : THUNK_TARGET(hv_hypercall_pg)
> + : "cc", "memory", "r9", "r10", "r11");
> +
> + return hv_status;
> +}
> +#else
> EXPORT_SYMBOL_GPL(hv_hypercall_pg);
> +#endif
>
> union hv_ghcb * __percpu *hv_ghcb_pg;
>
> --- a/arch/x86/hyperv/ivm.c
> +++ b/arch/x86/hyperv/ivm.c
> @@ -377,9 +377,23 @@ int hv_snp_boot_ap(u32 cpu, unsigned lon
> return ret;
> }
>
> +u64 hv_snp_hypercall(u64 control, u64 param1, u64 param2)
> +{
> + u64 hv_status;
> +
> + register u64 __r8 asm("r8") = param2;
> + asm volatile("vmmcall"
> + : "=a" (hv_status), ASM_CALL_CONSTRAINT,
> + "+c" (control), "+d" (param1), "+r" (__r8)
> + : : "cc", "memory", "r9", "r10", "r11");
> +
> + return hv_status;
> +}
> +
> #else
> static inline void hv_ghcb_msr_write(u64 msr, u64 value) {}
> static inline void hv_ghcb_msr_read(u64 msr, u64 *value) {}
> +u64 hv_snp_hypercall(u64 control, u64 param1, u64 param2) { return U64_MAX; }
> #endif /* CONFIG_AMD_MEM_ENCRYPT */
>
> #ifdef CONFIG_INTEL_TDX_GUEST
> @@ -429,6 +443,7 @@ u64 hv_tdx_hypercall(u64 control, u64 pa
> #else
> static inline void hv_tdx_msr_write(u64 msr, u64 value) {}
> static inline void hv_tdx_msr_read(u64 msr, u64 *value) {}
> +u64 hv_tdx_hypercall(u64 control, u64 param1, u64 param2) { return U64_MAX; }
> #endif /* CONFIG_INTEL_TDX_GUEST */
>
> #if defined(CONFIG_AMD_MEM_ENCRYPT) || defined(CONFIG_INTEL_TDX_GUEST)
> --- a/arch/x86/include/asm/mshyperv.h
> +++ b/arch/x86/include/asm/mshyperv.h
> @@ -6,6 +6,7 @@
> #include <linux/nmi.h>
> #include <linux/msi.h>
> #include <linux/io.h>
> +#include <linux/static_call.h>
> #include <asm/nospec-branch.h>
> #include <asm/paravirt.h>
> #include <asm/msr.h>
> @@ -39,16 +40,21 @@ static inline unsigned char hv_get_nmi_r
> return 0;
> }
>
> -#if IS_ENABLED(CONFIG_HYPERV)
> -extern bool hyperv_paravisor_present;
> +extern u64 hv_tdx_hypercall(u64 control, u64 param1, u64 param2);
> +extern u64 hv_snp_hypercall(u64 control, u64 param1, u64 param2);
> +extern u64 hv_std_hypercall(u64 control, u64 param1, u64 param2);
>
> +#if IS_ENABLED(CONFIG_HYPERV)
> extern void *hv_hypercall_pg;
>
> extern union hv_ghcb * __percpu *hv_ghcb_pg;
>
> bool hv_isolation_type_snp(void);
> bool hv_isolation_type_tdx(void);
> -u64 hv_tdx_hypercall(u64 control, u64 param1, u64 param2);
> +
> +#ifdef CONFIG_X86_64
> +DECLARE_STATIC_CALL(hv_hypercall, hv_std_hypercall);
> +#endif
>
> /*
> * DEFAULT INIT GPAT and SEGMENT LIMIT value in struct VMSA
> @@ -65,37 +71,15 @@ static inline u64 hv_do_hypercall(u64 co
> {
> u64 input_address = input ? virt_to_phys(input) : 0;
> u64 output_address = output ? virt_to_phys(output) : 0;
> - u64 hv_status;
>
> #ifdef CONFIG_X86_64
> - if (hv_isolation_type_tdx() && !hyperv_paravisor_present)
> - return hv_tdx_hypercall(control, input_address, output_address);
> -
> - if (hv_isolation_type_snp() && !hyperv_paravisor_present) {
> - __asm__ __volatile__("mov %[output_address], %%r8\n"
> - "vmmcall"
> - : "=a" (hv_status), ASM_CALL_CONSTRAINT,
> - "+c" (control), "+d" (input_address)
> - : [output_address] "r" (output_address)
> - : "cc", "memory", "r8", "r9", "r10", "r11");
> - return hv_status;
> - }
> -
> - if (!hv_hypercall_pg)
> - return U64_MAX;
> -
> - __asm__ __volatile__("mov %[output_address], %%r8\n"
> - CALL_NOSPEC
> - : "=a" (hv_status), ASM_CALL_CONSTRAINT,
> - "+c" (control), "+d" (input_address)
> - : [output_address] "r" (output_address),
> - THUNK_TARGET(hv_hypercall_pg)
> - : "cc", "memory", "r8", "r9", "r10", "r11");
> + return static_call_mod(hv_hypercall)(control, input_address, output_address);
> #else
> u32 input_address_hi = upper_32_bits(input_address);
> u32 input_address_lo = lower_32_bits(input_address);
> u32 output_address_hi = upper_32_bits(output_address);
> u32 output_address_lo = lower_32_bits(output_address);
> + u64 hv_status;
>
> if (!hv_hypercall_pg)
> return U64_MAX;
> @@ -108,8 +92,8 @@ static inline u64 hv_do_hypercall(u64 co
> "D"(output_address_hi), "S"(output_address_lo),
> THUNK_TARGET(hv_hypercall_pg)
> : "cc", "memory");
> -#endif /* !x86_64 */
> return hv_status;
> +#endif /* !x86_64 */
> }
>
> /* Hypercall to the L0 hypervisor */
> @@ -121,41 +105,23 @@ static inline u64 hv_do_nested_hypercall
> /* Fast hypercall with 8 bytes of input and no output */
> static inline u64 _hv_do_fast_hypercall8(u64 control, u64 input1)
> {
> - u64 hv_status;
> -
> #ifdef CONFIG_X86_64
> - if (hv_isolation_type_tdx() && !hyperv_paravisor_present)
> - return hv_tdx_hypercall(control, input1, 0);
> -
> - if (hv_isolation_type_snp() && !hyperv_paravisor_present) {
> - __asm__ __volatile__(
> - "vmmcall"
> - : "=a" (hv_status), ASM_CALL_CONSTRAINT,
> - "+c" (control), "+d" (input1)
> - :: "cc", "r8", "r9", "r10", "r11");
> - } else {
> - __asm__ __volatile__(CALL_NOSPEC
> - : "=a" (hv_status), ASM_CALL_CONSTRAINT,
> - "+c" (control), "+d" (input1)
> - : THUNK_TARGET(hv_hypercall_pg)
> - : "cc", "r8", "r9", "r10", "r11");
> - }
> + return static_call_mod(hv_hypercall)(control, input1, 0);
> #else
> - {
> - u32 input1_hi = upper_32_bits(input1);
> - u32 input1_lo = lower_32_bits(input1);
> -
> - __asm__ __volatile__ (CALL_NOSPEC
> - : "=A"(hv_status),
> - "+c"(input1_lo),
> - ASM_CALL_CONSTRAINT
> - : "A" (control),
> - "b" (input1_hi),
> - THUNK_TARGET(hv_hypercall_pg)
> - : "cc", "edi", "esi");
> - }
> -#endif
> + u32 input1_hi = upper_32_bits(input1);
> + u32 input1_lo = lower_32_bits(input1);
> + u64 hv_status;
> +
> + __asm__ __volatile__ (CALL_NOSPEC
> + : "=A"(hv_status),
> + "+c"(input1_lo),
> + ASM_CALL_CONSTRAINT
> + : "A" (control),
> + "b" (input1_hi),
> + THUNK_TARGET(hv_hypercall_pg)
> + : "cc", "edi", "esi");
> return hv_status;
> +#endif
> }
>
> static inline u64 hv_do_fast_hypercall8(u16 code, u64 input1)
> @@ -175,45 +141,24 @@ static inline u64 hv_do_fast_nested_hype
> /* Fast hypercall with 16 bytes of input */
> static inline u64 _hv_do_fast_hypercall16(u64 control, u64 input1, u64 input2)
> {
> - u64 hv_status;
> -
> #ifdef CONFIG_X86_64
> - if (hv_isolation_type_tdx() && !hyperv_paravisor_present)
> - return hv_tdx_hypercall(control, input1, input2);
> -
> - if (hv_isolation_type_snp() && !hyperv_paravisor_present) {
> - __asm__ __volatile__("mov %[input2], %%r8\n"
> - "vmmcall"
> - : "=a" (hv_status), ASM_CALL_CONSTRAINT,
> - "+c" (control), "+d" (input1)
> - : [input2] "r" (input2)
> - : "cc", "r8", "r9", "r10", "r11");
> - } else {
> - __asm__ __volatile__("mov %[input2], %%r8\n"
> - CALL_NOSPEC
> - : "=a" (hv_status), ASM_CALL_CONSTRAINT,
> - "+c" (control), "+d" (input1)
> - : [input2] "r" (input2),
> - THUNK_TARGET(hv_hypercall_pg)
> - : "cc", "r8", "r9", "r10", "r11");
> - }
> + return static_call_mod(hv_hypercall)(control, input1, input2);
> #else
> - {
> - u32 input1_hi = upper_32_bits(input1);
> - u32 input1_lo = lower_32_bits(input1);
> - u32 input2_hi = upper_32_bits(input2);
> - u32 input2_lo = lower_32_bits(input2);
> -
> - __asm__ __volatile__ (CALL_NOSPEC
> - : "=A"(hv_status),
> - "+c"(input1_lo), ASM_CALL_CONSTRAINT
> - : "A" (control), "b" (input1_hi),
> - "D"(input2_hi), "S"(input2_lo),
> - THUNK_TARGET(hv_hypercall_pg)
> - : "cc");
> - }
> -#endif
> + u32 input1_hi = upper_32_bits(input1);
> + u32 input1_lo = lower_32_bits(input1);
> + u32 input2_hi = upper_32_bits(input2);
> + u32 input2_lo = lower_32_bits(input2);
> + u64 hv_status;
> +
> + __asm__ __volatile__ (CALL_NOSPEC
> + : "=A"(hv_status),
> + "+c"(input1_lo), ASM_CALL_CONSTRAINT
> + : "A" (control), "b" (input1_hi),
> + "D"(input2_hi), "S"(input2_lo),
> + THUNK_TARGET(hv_hypercall_pg)
> + : "cc");
> return hv_status;
> +#endif
> }
>
> static inline u64 hv_do_fast_hypercall16(u16 code, u64 input1, u64 input2)
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -38,10 +38,6 @@
> bool hv_nested;
> struct ms_hyperv_info ms_hyperv;
>
> -/* Used in modules via hv_do_hypercall(): see arch/x86/include/asm/mshyperv.h */
> -bool hyperv_paravisor_present __ro_after_init;
> -EXPORT_SYMBOL_GPL(hyperv_paravisor_present);
> -
> #if IS_ENABLED(CONFIG_HYPERV)
> static inline unsigned int hv_get_nested_msr(unsigned int reg)
> {
> @@ -288,8 +284,18 @@ static void __init x86_setup_ops_for_tsc
> old_restore_sched_clock_state = x86_platform.restore_sched_clock_state;
> x86_platform.restore_sched_clock_state = hv_restore_sched_clock_state;
> }
> +
> +#ifdef CONFIG_X86_64
> +DEFINE_STATIC_CALL(hv_hypercall, hv_std_hypercall);
> +EXPORT_STATIC_CALL_TRAMP_GPL(hv_hypercall);
> +#define hypercall_update(hc) static_call_update(hv_hypercall, hc)
> +#endif
> #endif /* CONFIG_HYPERV */
>
> +#ifndef hypercall_update
> +#define hypercall_update(hc) (void)hc
> +#endif
> +
> static uint32_t __init ms_hyperv_platform(void)
> {
> u32 eax;
> @@ -484,14 +490,14 @@ static void __init ms_hyperv_init_platfo
> ms_hyperv.shared_gpa_boundary =
> BIT_ULL(ms_hyperv.shared_gpa_boundary_bits);
>
> - hyperv_paravisor_present = !!ms_hyperv.paravisor_present;
> -
> pr_info("Hyper-V: Isolation Config: Group A 0x%x, Group B 0x%x\n",
> ms_hyperv.isolation_config_a, ms_hyperv.isolation_config_b);
>
>
> if (hv_get_isolation_type() == HV_ISOLATION_TYPE_SNP) {
> static_branch_enable(&isolation_type_snp);
> + if (!ms_hyperv.paravisor_present)
> + hypercall_update(hv_snp_hypercall);
> } else if (hv_get_isolation_type() == HV_ISOLATION_TYPE_TDX) {
> static_branch_enable(&isolation_type_tdx);
>
> @@ -499,6 +505,7 @@ static void __init ms_hyperv_init_platfo
> ms_hyperv.hints &= ~HV_X64_APIC_ACCESS_RECOMMENDED;
>
> if (!ms_hyperv.paravisor_present) {
> + hypercall_update(hv_tdx_hypercall);
> /*
> * Mark the Hyper-V TSC page feature as disabled
> * in a TDX VM without paravisor so that the
>
^ permalink raw reply
* Re: [PATCH net,v2] hv_netvsc: Switch VF namespace in netvsc_open instead
From: Simon Horman @ 2025-07-15 13:05 UTC (permalink / raw)
To: Haiyang Zhang
Cc: linux-hyperv, netdev, haiyangz, kys, wei.liu, decui,
andrew+netdev, edumazet, kuba, pabeni, davem, linux-kernel,
stable, cavery
In-Reply-To: <1752511297-8817-1-git-send-email-haiyangz@linux.microsoft.com>
On Mon, Jul 14, 2025 at 09:41:37AM -0700, Haiyang Zhang wrote:
> From: Haiyang Zhang <haiyangz@microsoft.com>
>
> The existing code move the VF NIC to new namespace when NETDEV_REGISTER is
> received on netvsc NIC. During deletion of the namespace,
> default_device_exit_batch() >> default_device_exit_net() is called. When
> netvsc NIC is moved back and registered to the default namespace, it
> automatically brings VF NIC back to the default namespace. This will cause
> the default_device_exit_net() >> for_each_netdev_safe loop unable to detect
> the list end, and hit NULL ptr:
>
> [ 231.449420] mana 7870:00:00.0 enP30832s1: Moved VF to namespace with: eth0
> [ 231.449656] BUG: kernel NULL pointer dereference, address: 0000000000000010
> [ 231.450246] #PF: supervisor read access in kernel mode
> [ 231.450579] #PF: error_code(0x0000) - not-present page
> [ 231.450916] PGD 17b8a8067 P4D 0
> [ 231.451163] Oops: Oops: 0000 [#1] SMP NOPTI
> [ 231.451450] CPU: 82 UID: 0 PID: 1394 Comm: kworker/u768:1 Not tainted 6.16.0-rc4+ #3 VOLUNTARY
> [ 231.452042] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024
> [ 231.452692] Workqueue: netns cleanup_net
> [ 231.452947] RIP: 0010:default_device_exit_batch+0x16c/0x3f0
> [ 231.453326] Code: c0 0c f5 b3 e8 d5 db fe ff 48 85 c0 74 15 48 c7 c2 f8 fd ca b2 be 10 00 00 00 48 8d 7d c0 e8 7b 77 25 00 49 8b 86 28 01 00 00 <48> 8b 50 10 4c 8b 2a 4c 8d 62 f0 49 83 ed 10 4c 39 e0 0f 84 d6 00
> [ 231.454294] RSP: 0018:ff75fc7c9bf9fd00 EFLAGS: 00010246
> [ 231.454610] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 61c8864680b583eb
> [ 231.455094] RDX: ff1fa9f71462d800 RSI: ff75fc7c9bf9fd38 RDI: 0000000030766564
> [ 231.455686] RBP: ff75fc7c9bf9fd78 R08: 0000000000000000 R09: 0000000000000000
> [ 231.456126] R10: 0000000000000001 R11: 0000000000000004 R12: ff1fa9f70088e340
> [ 231.456621] R13: ff1fa9f70088e340 R14: ffffffffb3f50c20 R15: ff1fa9f7103e6340
> [ 231.457161] FS: 0000000000000000(0000) GS:ff1faa6783a08000(0000) knlGS:0000000000000000
> [ 231.457707] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 231.458031] CR2: 0000000000000010 CR3: 0000000179ab2006 CR4: 0000000000b73ef0
> [ 231.458434] Call Trace:
> [ 231.458600] <TASK>
> [ 231.458777] ops_undo_list+0x100/0x220
> [ 231.459015] cleanup_net+0x1b8/0x300
> [ 231.459285] process_one_work+0x184/0x340
>
> To fix it, move the VF namespace switching code from the NETDEV_REGISTER
> event handler to netvsc_open().
>
> Cc: stable@vger.kernel.org
> Cc: cavery@redhat.com
> Fixes: 4c262801ea60 ("hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event")
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
With this change do we go back to the situation that existed prior
to the cited patch? Quoting the cited commit:
The existing code moves VF to the same namespace as the synthetic NIC
during netvsc_register_vf(). But, if the synthetic device is moved to a
new namespace after the VF registration, the VF won't be moved together.
Or perhaps not because if synthetic device is moved then, in practice, it
will subsequently be reopened? (Because it is closed as part of the move
to a different netns?)
I am unsure.
^ permalink raw reply
* Re: [PATCH hyperv-next v4 03/16] arch: hyperv: Get/set SynIC synth.registers via paravisor
From: kernel test robot @ 2025-07-15 12:46 UTC (permalink / raw)
To: Roman Kisel, alok.a.tiwari, arnd, bp, corbet, dave.hansen, decui,
haiyangz, hpa, kys, mhklinux, mingo, rdunlap, tglx, Tianyu.Lan,
wei.liu, linux-arch, linux-coco, linux-doc, linux-hyperv,
linux-kernel, x86
Cc: llvm, oe-kbuild-all, apais, benhill, bperkins, sunilmut
In-Reply-To: <20250714221545.5615-4-romank@linux.microsoft.com>
Hi Roman,
kernel test robot noticed the following build errors:
[auto build test ERROR on d9016a249be5316ec2476f9947356711e70a16ec]
url: https://github.com/intel-lab-lkp/linux/commits/Roman-Kisel/Documentation-hyperv-Confidential-VMBus/20250715-062125
base: d9016a249be5316ec2476f9947356711e70a16ec
patch link: https://lore.kernel.org/r/20250714221545.5615-4-romank%40linux.microsoft.com
patch subject: [PATCH hyperv-next v4 03/16] arch: hyperv: Get/set SynIC synth.registers via paravisor
config: i386-buildonly-randconfig-005-20250715 (https://download.01.org/0day-ci/archive/20250715/202507152017.8UNXIbRJ-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250715/202507152017.8UNXIbRJ-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202507152017.8UNXIbRJ-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from arch/x86/kvm/vmx/main.c:5:
In file included from arch/x86/kvm/vmx/vmx.h:16:
In file included from arch/x86/kvm/vmx/vmx_ops.h:9:
In file included from arch/x86/kvm/vmx/vmx_onhyperv.h:7:
In file included from arch/x86/include/asm/mshyperv.h:345:
>> include/asm-generic/mshyperv.h:377:4: error: call to undeclared function 'hv_para_set_synic_register'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
377 | hv_para_set_synic_register(HV_MSR_EOM, 0);
| ^
1 error generated.
--
In file included from arch/x86/kvm/svm/hyperv.c:7:
In file included from arch/x86/kvm/svm/hyperv.h:9:
In file included from arch/x86/include/asm/mshyperv.h:345:
>> include/asm-generic/mshyperv.h:377:4: error: call to undeclared function 'hv_para_set_synic_register'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
377 | hv_para_set_synic_register(HV_MSR_EOM, 0);
| ^
In file included from arch/x86/kvm/svm/hyperv.c:7:
In file included from arch/x86/kvm/svm/hyperv.h:11:
In file included from arch/x86/kvm/svm/../hyperv.h:24:
In file included from include/linux/kvm_host.h:11:
include/linux/signal.h:98:11: warning: array index 3 is past the end of the array (that has type 'unsigned long[2]') [-Warray-bounds]
98 | return (set->sig[3] | set->sig[2] |
| ^ ~
arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
24 | unsigned long sig[_NSIG_WORDS];
| ^
In file included from arch/x86/kvm/svm/hyperv.c:7:
In file included from arch/x86/kvm/svm/hyperv.h:11:
In file included from arch/x86/kvm/svm/../hyperv.h:24:
In file included from include/linux/kvm_host.h:11:
include/linux/signal.h:98:25: warning: array index 2 is past the end of the array (that has type 'unsigned long[2]') [-Warray-bounds]
98 | return (set->sig[3] | set->sig[2] |
| ^ ~
arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
24 | unsigned long sig[_NSIG_WORDS];
| ^
In file included from arch/x86/kvm/svm/hyperv.c:7:
In file included from arch/x86/kvm/svm/hyperv.h:11:
In file included from arch/x86/kvm/svm/../hyperv.h:24:
In file included from include/linux/kvm_host.h:11:
include/linux/signal.h:114:11: warning: array index 3 is past the end of the array (that has type 'const unsigned long[2]') [-Warray-bounds]
114 | return (set1->sig[3] == set2->sig[3]) &&
| ^ ~
arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
24 | unsigned long sig[_NSIG_WORDS];
| ^
In file included from arch/x86/kvm/svm/hyperv.c:7:
In file included from arch/x86/kvm/svm/hyperv.h:11:
In file included from arch/x86/kvm/svm/../hyperv.h:24:
In file included from include/linux/kvm_host.h:11:
include/linux/signal.h:114:27: warning: array index 3 is past the end of the array (that has type 'const unsigned long[2]') [-Warray-bounds]
114 | return (set1->sig[3] == set2->sig[3]) &&
| ^ ~
arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
24 | unsigned long sig[_NSIG_WORDS];
| ^
In file included from arch/x86/kvm/svm/hyperv.c:7:
In file included from arch/x86/kvm/svm/hyperv.h:11:
In file included from arch/x86/kvm/svm/../hyperv.h:24:
In file included from include/linux/kvm_host.h:11:
include/linux/signal.h:115:5: warning: array index 2 is past the end of the array (that has type 'const unsigned long[2]') [-Warray-bounds]
115 | (set1->sig[2] == set2->sig[2]) &&
| ^ ~
arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
24 | unsigned long sig[_NSIG_WORDS];
| ^
In file included from arch/x86/kvm/svm/hyperv.c:7:
In file included from arch/x86/kvm/svm/hyperv.h:11:
In file included from arch/x86/kvm/svm/../hyperv.h:24:
In file included from include/linux/kvm_host.h:11:
include/linux/signal.h:115:21: warning: array index 2 is past the end of the array (that has type 'const unsigned long[2]') [-Warray-bounds]
115 | (set1->sig[2] == set2->sig[2]) &&
| ^ ~
arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
24 | unsigned long sig[_NSIG_WORDS];
| ^
In file included from arch/x86/kvm/svm/hyperv.c:7:
In file included from arch/x86/kvm/svm/hyperv.h:11:
In file included from arch/x86/kvm/svm/../hyperv.h:24:
In file included from include/linux/kvm_host.h:11:
include/linux/signal.h:157:1: warning: array index 3 is past the end of the array (that has type 'const unsigned long[2]') [-Warray-bounds]
157 | _SIG_SET_BINOP(sigorsets, _sig_or)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/signal.h:138:8: note: expanded from macro '_SIG_SET_BINOP'
138 | a3 = a->sig[3]; a2 = a->sig[2]; \
| ^ ~
arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
24 | unsigned long sig[_NSIG_WORDS];
| ^
In file included from arch/x86/kvm/svm/hyperv.c:7:
In file included from arch/x86/kvm/svm/hyperv.h:11:
In file included from arch/x86/kvm/svm/../hyperv.h:24:
In file included from include/linux/kvm_host.h:11:
include/linux/signal.h:157:1: warning: array index 2 is past the end of the array (that has type 'const unsigned long[2]') [-Warray-bounds]
157 | _SIG_SET_BINOP(sigorsets, _sig_or)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/signal.h:138:24: note: expanded from macro '_SIG_SET_BINOP'
138 | a3 = a->sig[3]; a2 = a->sig[2]; \
| ^ ~
arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
24 | unsigned long sig[_NSIG_WORDS];
| ^
In file included from arch/x86/kvm/svm/hyperv.c:7:
In file included from arch/x86/kvm/svm/hyperv.h:11:
In file included from arch/x86/kvm/svm/../hyperv.h:24:
In file included from include/linux/kvm_host.h:11:
include/linux/signal.h:157:1: warning: array index 3 is past the end of the array (that has type 'const unsigned long[2]') [-Warray-bounds]
157 | _SIG_SET_BINOP(sigorsets, _sig_or)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/signal.h:139:8: note: expanded from macro '_SIG_SET_BINOP'
139 | b3 = b->sig[3]; b2 = b->sig[2]; \
| ^ ~
arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
24 | unsigned long sig[_NSIG_WORDS];
vim +/hv_para_set_synic_register +377 include/asm-generic/mshyperv.h
344
345 /* Free the message slot and signal end-of-message if required */
346 static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
347 {
348 /*
349 * On crash we're reading some other CPU's message page and we need
350 * to be careful: this other CPU may already had cleared the header
351 * and the host may already had delivered some other message there.
352 * In case we blindly write msg->header.message_type we're going
353 * to lose it. We can still lose a message of the same type but
354 * we count on the fact that there can only be one
355 * CHANNELMSG_UNLOAD_RESPONSE and we don't care about other messages
356 * on crash.
357 */
358 if (cmpxchg(&msg->header.message_type, old_msg_type,
359 HVMSG_NONE) != old_msg_type)
360 return;
361
362 /*
363 * The cmxchg() above does an implicit memory barrier to
364 * ensure the write to MessageType (ie set to
365 * HVMSG_NONE) happens before we read the
366 * MessagePending and EOMing. Otherwise, the EOMing
367 * will not deliver any more messages since there is
368 * no empty slot
369 */
370 if (msg->header.message_flags.msg_pending) {
371 /*
372 * This will cause message queue rescan to
373 * possibly deliver another msg from the
374 * hypervisor
375 */
376 if (vmbus_is_confidential())
> 377 hv_para_set_synic_register(HV_MSR_EOM, 0);
378 else
379 hv_set_msr(HV_MSR_EOM, 0);
380 }
381 }
382
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ 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