* Re: [PATCH v2] x86/hyperv: Fix kdump on Azure CVMs
From: kernel test robot @ 2025-08-19 21:19 UTC (permalink / raw)
To: Vitaly Kuznetsov, linux-hyperv
Cc: oe-kbuild-all, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, x86, linux-kernel, Nuno Das Neves, Tianyu Lan,
Michael Kelley, Li Tian, Philipp Rudo
In-Reply-To: <20250818095400.1610209-1-vkuznets@redhat.com>
Hi Vitaly,
kernel test robot noticed the following build warnings:
[auto build test WARNING on tip/x86/core]
[also build test WARNING on arm64/for-next/core tip/master linus/master v6.17-rc2]
[cannot apply to tip/auto-latest next-20250819]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Vitaly-Kuznetsov/x86-hyperv-Fix-kdump-on-Azure-CVMs/20250818-175830
base: tip/x86/core
patch link: https://lore.kernel.org/r/20250818095400.1610209-1-vkuznets%40redhat.com
patch subject: [PATCH v2] x86/hyperv: Fix kdump on Azure CVMs
config: x86_64-randconfig-101-20250819 (https://download.01.org/0day-ci/archive/20250820/202508200507.78h11riS-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
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/202508200507.78h11riS-lkp@intel.com/
cocci warnings: (new ones prefixed by >>)
>> arch/x86/hyperv/ivm.c:601:2-3: Unneeded semicolon
arch/x86/hyperv/ivm.c:504:3-4: Unneeded semicolon
arch/x86/hyperv/ivm.c:561:3-4: Unneeded semicolon
vim +601 arch/x86/hyperv/ivm.c
565
566 void hv_ivm_clear_host_access(void)
567 {
568 struct hv_gpa_range_for_visibility *input;
569 struct hv_enc_pfn_region *ent;
570 unsigned long flags;
571 u64 hv_status;
572 int cur, i;
573
574 if (!hv_is_isolation_supported())
575 return;
576
577 raw_spin_lock_irqsave(&hv_list_enc_lock, flags);
578
579 input = *this_cpu_ptr(hyperv_pcpu_input_arg);
580 if (!input)
581 goto unlock;
582
583 list_for_each_entry(ent, &hv_list_enc, list) {
584 for (i = 0, cur = 0; i < ent->count; i++) {
585 input->gpa_page_list[cur] = ent->pfn + i;
586 cur++;
587
588 if (cur == HV_MAX_MODIFY_GPA_REP_COUNT || i == ent->count - 1) {
589 input->partition_id = HV_PARTITION_ID_SELF;
590 input->host_visibility = VMBUS_PAGE_NOT_VISIBLE;
591 input->reserved0 = 0;
592 input->reserved1 = 0;
593 hv_status = hv_do_rep_hypercall(
594 HVCALL_MODIFY_SPARSE_GPA_PAGE_HOST_VISIBILITY,
595 cur, 0, input, NULL);
596 WARN_ON_ONCE(!hv_result_success(hv_status));
597 cur = 0;
598 }
599 }
600
> 601 };
602
603 unlock:
604 raw_spin_unlock_irqrestore(&hv_list_enc_lock, flags);
605 }
606 EXPORT_SYMBOL_GPL(hv_ivm_clear_host_access);
607
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH hyperv-next v4 15/16] Drivers: hv: Support establishing the confidential VMBus connection
From: dan.j.williams @ 2025-08-19 20:26 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: apais, benhill, bperkins, sunilmut
In-Reply-To: <20250714221545.5615-16-romank@linux.microsoft.com>
Roman Kisel wrote:
> To establish the confidential VMBus connection the CoCo VM guest
> first attempts to connect to the VMBus server run by the paravisor.
> If that fails, the guest falls back to the non-confidential VMBus.
>
> Implement that in the VMBus driver initialization.
>
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> ---
> drivers/hv/vmbus_drv.c | 189 ++++++++++++++++++++++++++++-------------
> 1 file changed, 130 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
[..]
> @@ -1401,41 +1474,42 @@ static int vmbus_bus_init(void)
> }
> }
>
> - ret = hv_synic_alloc();
> - if (ret)
> - goto err_alloc;
> -
> - works = alloc_percpu(struct work_struct);
> - if (!works) {
> - ret = -ENOMEM;
> - goto err_alloc;
> - }
> -
> /*
> - * Initialize the per-cpu interrupt state and stimer state.
> - * Then connect to the host.
> + * Attempt to establish the confidential VMBus connection first if this VM is
> + * a hardware confidential VM, and the paravisor is present.
> + *
> + * All scenarios here are:
> + * 1. No paravisor,
> + * 2. Paravisor without VMBus relay, no hardware isolation,
> + * 3. Paravisor without VMBus relay, with hardware isolation,
> + * 4. Paravisor with VMBus relay, no hardware isolation,
> + * 5. Paravisor with VMBus relay, with hardware isolation.
> + *
> + * In the cloud, scenarios 1, 4, 5 are most common, and outside the cloud,
> + * scenario 1 should be the most common at the moment. Detecting of the Confidential
> + * VMBus support below takes that into account running `vmbus_alloc_synic_and_connect()`
> + * only once (barring any faults not related to VMBus) in these cases. That is true
> + * for the scenario 2, too, albeit it might be not as feature-rich as 1, 4, 5.
> + *
> + * However, the code will be doing much more work in scenario 3 where it will have to
> + * first initialize lots of structures for every CPU only to likely tear them down later
> + * and start again, now without attempting to use Confidential VMBus, thus taking a
> + * performance hit. Such systems are rather uncomoon today, don't support more than
> + * ~300 CPUs, and are rarely used with many dozens of CPUs. As the time goes on, that
> + * will be even less common. Hence, the preference is to not specialize the code for
> + * that scenario.
I read this blurb looking for answers to my question below, no luck, and
left further wondering what is the comment trying to convey to future
maintenance?
> */
> - cpus_read_lock();
> - for_each_online_cpu(cpu) {
> - struct work_struct *work = per_cpu_ptr(works, cpu);
> + ret = -ENODEV;
> + if (ms_hyperv.paravisor_present && (hv_isolation_type_tdx() || hv_isolation_type_snp())) {
> + is_confidential = true;
In comparison to PCIe TDISP where there is an explicit validation step
of cryptographic evidence that the platform is what it claims to be, I
am missing the same for this.
I would expect something like a paravisor signed golden measurement with
a certificate that can be built-in to the kernel to validate that "yes,
in addition to the platform claims that can be emulated, this bus
enumeration is signed by an authority this kernel image trusts."
My motivation for commenting here is for alignment purposes with the
PCIe TDISP enabling and wider concerns about accepting other devices for
private operation. Specifically, I want to align on a shared
representation in the device-core (struct device) to communicate that a
device is either on a bus that has been accepted for private operation
(confidential-vmbus today, potentially signed-ACPI-devices tomorrow), or
is a device that has been individually accepted for private operation
(PCIe TDISP). In both cases there needs to be either a golden
measurement mechanism built-in, or a userspace acceptance dependency in
the flow.
Otherwise what mitigates a guest conveying secrets to a device that is
merely emulating a trusted bus/device?
^ permalink raw reply
* RE: [PATCH v2] x86/hyperv: Fix kdump on Azure CVMs
From: Michael Kelley @ 2025-08-19 17:30 UTC (permalink / raw)
To: Vitaly Kuznetsov, linux-hyperv@vger.kernel.org
Cc: K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui,
x86@kernel.org, linux-kernel@vger.kernel.org, Nuno Das Neves,
Tianyu Lan, Li Tian, Philipp Rudo
In-Reply-To: <20250818095400.1610209-1-vkuznets@redhat.com>
From: Vitaly Kuznetsov <vkuznets@redhat.com> Sent: Monday, August 18, 2025 2:54 AM
>
> Azure CVM instance types featuring a paravisor hang upon kdump. The
> investigation shows that makedumpfile causes a hang when it steps on a page
> which was previously share with the host
> (HVCALL_MODIFY_SPARSE_GPA_PAGE_HOST_VISIBILITY). The new kernel has no
> knowledge of these 'special' regions (which are Vmbus connection pages,
> GPADL buffers, ...). There are several ways to approach the issue:
> - Convey the knowledge about these regions to the new kernel somehow.
> - Unshare these regions before accessing in the new kernel (it is unclear
> if there's a way to query the status for a given GPA range).
> - Unshare these regions before jumping to the new kernel (which this patch
> implements).
>
> To make the procedure as robust as possible, store PFN ranges of shared
> regions in a linked list instead of storing GVAs and re-using
> hv_vtom_set_host_visibility(). This also allows to avoid memory allocation
> on the kdump/kexec path.
>
> The patch skips implementing weird corner case in hv_list_enc_remove()
> when a PFN in the middle of a region is unshared. First, it is unlikely
> that such requests happen. Second, it is not a big problem if
> hv_list_enc_remove() doesn't actually remove some regions as this will
> only result in an extra hypercall doing nothing upon kexec/kdump; there's
> no need to be perfect.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
> Changes since v1:
> - fix build on ARM [kernel test robot]
> ---
> arch/arm64/include/asm/mshyperv.h | 3 +
> arch/x86/hyperv/ivm.c | 153 ++++++++++++++++++++++++++++++
> arch/x86/include/asm/mshyperv.h | 2 +
> drivers/hv/vmbus_drv.c | 2 +
> 4 files changed, 160 insertions(+)
>
> diff --git a/arch/arm64/include/asm/mshyperv.h
> b/arch/arm64/include/asm/mshyperv.h
> index b721d3134ab6..af11abf403b4 100644
> --- a/arch/arm64/include/asm/mshyperv.h
> +++ b/arch/arm64/include/asm/mshyperv.h
> @@ -53,6 +53,9 @@ static inline u64 hv_get_non_nested_msr(unsigned int reg)
> return hv_get_msr(reg);
> }
>
> +/* Isolated VMs are unsupported on ARM, no cleanup needed */
> +static inline void hv_ivm_clear_host_access(void) {}
Stubs such as this should be handled differently. We've instead
put __weak stubs in drivers/hv/hv_common.c, and let x86 code
override. That approach avoids needing to update arch/arm64
code and to get acks from arm64 maintainers for functionality that
is (currently) x86-only. arch/arm64/include/asm/mshyperv.h is
pretty small because of this approach.
For consistency, this stub should follow that existing pattern. See
hv_is_isolation_supported() as an example.
> +
> /* SMCCC hypercall parameters */
> #define HV_SMCCC_FUNC_NUMBER 1
> #define HV_FUNC_ID ARM_SMCCC_CALL_VAL( \
> diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c
> index ade6c665c97e..a6e614672836 100644
> --- a/arch/x86/hyperv/ivm.c
> +++ b/arch/x86/hyperv/ivm.c
> @@ -462,6 +462,150 @@ void hv_ivm_msr_read(u64 msr, u64 *value)
> hv_ghcb_msr_read(msr, value);
> }
>
> +/*
> + * Keep track of the PFN regions which were shared with the host. The access
> + * must be revoked upon kexec/kdump (see hv_ivm_clear_host_access()).
> + */
> +struct hv_enc_pfn_region {
> + struct list_head list;
> + u64 pfn;
> + int count;
> +};
I'm wondering if there's an existing kernel data structure that would handle
the requirements here. Did you look at using xarray()? It's probably not as
memory efficient since it presumably needs a separate entry for each PFN,
whereas your code below uses a single entry for a range of PFNs. But
maybe that's a worthwhile tradeoff to simplify the code and avoid some
of the messy issues I point out below. Just a thought ....
> +
> +static LIST_HEAD(hv_list_enc);
> +static DEFINE_RAW_SPINLOCK(hv_list_enc_lock);
> +
> +static int hv_list_enc_add(const u64 *pfn_list, int count)
> +{
> + struct hv_enc_pfn_region *ent;
> + unsigned long flags;
> + bool found = false;
> + u64 pfn;
> + int i;
> +
> + for (i = 0; i < count; i++) {
> + pfn = pfn_list[i];
> +
> + found = false;
> + raw_spin_lock_irqsave(&hv_list_enc_lock, flags);
> + list_for_each_entry(ent, &hv_list_enc, list) {
> + if ((ent->pfn <= pfn) && (ent->pfn + ent->count - 1 >= pfn)) {
> + /* Nothin to do - pfn is already in the list */
s/Nothin/Nothing/
> + found = true;
> + } else if (ent->pfn + ent->count == pfn) {
> + /* Grow existing region up */
> + found = true;
> + ent->count++;
> + } else if (pfn + 1 == ent->pfn) {
> + /* Grow existing region down */
> + found = true;
> + ent->pfn--;
> + ent->count++;
> + }
Observations that might be worth a comment here in the code:
After a region is grown up or down, there's no check to see if the
region is now adjacent to an existing region. Additionally, if a PFN
that is already in some region is added, it might get appended to
some other adjacent region that occurs earlier in the list, rather than
being recognized as a duplicate. Hence the PFN could be included
in two different regions.
> + };
> + raw_spin_unlock_irqrestore(&hv_list_enc_lock, flags);
> +
> + if (found)
> + continue;
> +
> + /* No adajacent region found -- creating a new one */
s/adajacent/adjacent/
> + ent = kzalloc(sizeof(struct hv_enc_pfn_region), GFP_KERNEL);
> + if (!ent)
> + return -ENOMEM;
> +
> + ent->pfn = pfn;
> + ent->count = 1;
> +
> + raw_spin_lock_irqsave(&hv_list_enc_lock, flags);
> + list_add(&ent->list, &hv_list_enc);
> + raw_spin_unlock_irqrestore(&hv_list_enc_lock, flags);
> + }
> +
> + return 0;
> +}
> +
> +static void hv_list_enc_remove(const u64 *pfn_list, int count)
> +{
> + struct hv_enc_pfn_region *ent, *t;
> + unsigned long flags;
> + u64 pfn;
> + int i;
> +
> + for (i = 0; i < count; i++) {
> + pfn = pfn_list[i];
> +
> + raw_spin_lock_irqsave(&hv_list_enc_lock, flags);
> + list_for_each_entry_safe(ent, t, &hv_list_enc, list) {
> + if (pfn == ent->pfn + count - 1) {
This should be:
if (pfn == ent->pfn + ent->count - 1) {
> + /* Removing tail pfn */
> + ent->count--;
> + if (!ent->count) {
> + list_del(&ent->list);
> + kfree(ent);
> + }
> + } else if (pfn == ent->pfn) {
> + /* Removing head pfn */
> + ent->count--;
> + ent->pfn++;
> + if (!ent->count) {
> + list_del(&ent->list);
> + kfree(ent);
> + }
Apropos my comment on hv_list_enc_add(), if a PFN does appear in
more than one region, this code removes it from all such regions.
> + }
> +
> + /*
> + * Removing PFNs in the middle of a region is not implemented; the
> + * list is currently only used for cleanup upon kexec and there's
> + * no harm done if we issue an extra unneeded hypercall making some
> + * region encrypted when it already is.
> + */
In working with Hyper-V CVMs, I have never been entirely clear on whether the
HVCALL_MODIFY_SPARSE_GPA_PAGE_HOST_VISIBILITY hypercall is idempotent.
Consequently, in other parts of the code, we've made sure not to re-encrypt
memory that is already encrypted. There may have been some issues back in the
early days of CVMs that led to me think that it is not idempotent, but I don't
remember for sure.
Do you have a particular basis for asserting that it is idempotent? I just ran an
experiment on a TDX and a SEV-SNP VM in Azure, and the behavior is idempotent
in both cases, so that's good. But both are configurations with a paravisor, which
intercepts the hypercall and then makes its own decision about whether to invoke
the hypervisor. I don't have the ability to run configurations with no paravisor, and
see whether the hypercall as implemented by the hypervisor is idempotent. Also,
there's the new OpenHCL paravisor that similarly intercepts the hypercall, and
its behavior could be different.
Lacking a spec for any of this, it's hard to know what behavior can be depended
upon. Probably should get clarity from someone at Microsoft who can check.
> + };
> + raw_spin_unlock_irqrestore(&hv_list_enc_lock, flags);
> + }
> +}
> +
> +void hv_ivm_clear_host_access(void)
> +{
> + struct hv_gpa_range_for_visibility *input;
> + struct hv_enc_pfn_region *ent;
> + unsigned long flags;
> + u64 hv_status;
> + int cur, i;
> +
> + if (!hv_is_isolation_supported())
> + return;
> +
> + raw_spin_lock_irqsave(&hv_list_enc_lock, flags);
> +
> + input = *this_cpu_ptr(hyperv_pcpu_input_arg);
> + if (!input)
> + goto unlock;
The latest hyperv-next tree has code changes in how the
per-cpu hypercall input arg is handled. Check it for examples.
> +
> + list_for_each_entry(ent, &hv_list_enc, list) {
> + for (i = 0, cur = 0; i < ent->count; i++) {
> + input->gpa_page_list[cur] = ent->pfn + i;
> + cur++;
> +
> + if (cur == HV_MAX_MODIFY_GPA_REP_COUNT || i == ent->count - 1) {
> + input->partition_id = HV_PARTITION_ID_SELF;
> + input->host_visibility = VMBUS_PAGE_NOT_VISIBLE;
> + input->reserved0 = 0;
> + input->reserved1 = 0;
> + hv_status = hv_do_rep_hypercall(
> + HVCALL_MODIFY_SPARSE_GPA_PAGE_HOST_VISIBILITY,
> + cur, 0, input, NULL);
> + WARN_ON_ONCE(!hv_result_success(hv_status));
> + cur = 0;
> + }
> + }
> +
> + };
> +
> +unlock:
> + raw_spin_unlock_irqrestore(&hv_list_enc_lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(hv_ivm_clear_host_access);
> +
> /*
> * hv_mark_gpa_visibility - Set pages visible to host via hvcall.
> *
> @@ -475,6 +619,7 @@ static int hv_mark_gpa_visibility(u16 count, const u64 pfn[],
> struct hv_gpa_range_for_visibility *input;
> u64 hv_status;
> unsigned long flags;
> + int ret;
>
> /* no-op if partition isolation is not enabled */
> if (!hv_is_isolation_supported())
> @@ -486,6 +631,14 @@ static int hv_mark_gpa_visibility(u16 count, const u64 pfn[],
> return -EINVAL;
> }
>
> + if (visibility == VMBUS_PAGE_NOT_VISIBLE) {
> + hv_list_enc_remove(pfn, count);
> + } else {
> + ret = hv_list_enc_add(pfn, count);
> + if (ret)
> + return ret;
> + }
What's the strategy if there's a failure from the hypercall
further down in this function? The list could then be out-of-sync
with what the paravisor/hypervisor thinks.
> +
> local_irq_save(flags);
> input = *this_cpu_ptr(hyperv_pcpu_input_arg);
>
> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
> index abc4659f5809..6a988001e46f 100644
> --- a/arch/x86/include/asm/mshyperv.h
> +++ b/arch/x86/include/asm/mshyperv.h
> @@ -263,10 +263,12 @@ static inline int hv_snp_boot_ap(u32 apic_id, unsigned long
> start_ip,
> void hv_vtom_init(void);
> void hv_ivm_msr_write(u64 msr, u64 value);
> void hv_ivm_msr_read(u64 msr, u64 *value);
> +void hv_ivm_clear_host_access(void);
> #else
> static inline void hv_vtom_init(void) {}
> static inline void hv_ivm_msr_write(u64 msr, u64 value) {}
> static inline void hv_ivm_msr_read(u64 msr, u64 *value) {}
> +static inline void hv_ivm_clear_host_access(void) {}
> #endif
>
> static inline bool hv_is_synic_msr(unsigned int reg)
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 2ed5a1e89d69..2e891e108218 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -2784,6 +2784,7 @@ static void hv_kexec_handler(void)
> /* Make sure conn_state is set as hv_synic_cleanup checks for it */
> mb();
> cpuhp_remove_state(hyperv_cpuhp_online);
At this point, all vCPUs are still running. Changing the state of decrypted pages
to encrypted has the potential to upset code running on those other vCPUs.
They might try to access a page that has become encrypted using a PTE that
indicates decrypted. And changing a page from decrypted to encrypted changes
the memory contents of the page that would be seen by the other vCPU.
Either situation could cause a panic, and ruin the kexec().
It seems to me that it would be safer to do hv_ivm_clear_host_access()
at the beginning of hyperv_cleanup(), before clearing the guest OS ID
and the hypercall page. But maybe there's a reason that doesn't work
that I'm missing.
> + hv_ivm_clear_host_access();
> };
>
> static void hv_crash_handler(struct pt_regs *regs)
> @@ -2799,6 +2800,7 @@ static void hv_crash_handler(struct pt_regs *regs)
> cpu = smp_processor_id();
> hv_stimer_cleanup(cpu);
> hv_synic_disable_regs(cpu);
Same here about waiting until only one vCPU is running.
> + hv_ivm_clear_host_access();
> };
>
> static int hv_synic_suspend(void)
> --
> 2.50.0
^ permalink raw reply
* Re: [PATCH] mshv: Add support for a new parent partition configuration
From: Easwar Hariharan @ 2025-08-19 17:29 UTC (permalink / raw)
To: Wei Liu
Cc: easwar.hariharan, Nuno Das Neves, linux-hyperv, linux-kernel,
linux-arch, kys, haiyangz, mhklinux, decui, arnd
In-Reply-To: <aKSyzopAGQhM61B0@liuwe-devbox-ubuntu-v2.tail21d00.ts.net>
On 8/19/2025 10:22 AM, Wei Liu wrote:
> On Tue, Aug 19, 2025 at 09:17:27AM -0700, Easwar Hariharan wrote:
>> On 8/19/2025 12:29 AM, Nuno Das Neves wrote:
>>> Detect booting as an "L1VH" partition. This is a new scenario very
>>> similar to root partition where the mshv_root driver can be used to
>>> create and manage guest partitions.
>>>
>>> It mostly works the same as root partition, but there are some
>>> differences in how various features are handled. hv_l1vh_partition()
>>> is introduced to handle these cases. Add hv_parent_partition()
>>> which returns true for either case, replacing some hv_root_partition()
>>> checks.
>>>
>>> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
>>
>> Seems the plurality of subject prefixes for drivers/hv files has been "Drivers: hv"
>> so far, including the 2 commits for drivers/hv/mshv*. Are you planning to change
>> the standard for mshv driver going forward?
>
> IMO it is okay to have a different prefix to call out the commits that
> are relevant to the mshv driver. This eases the burden for anyone
> porting the changes to a different kernel tree. We may also touch many
> different parts of the codebase (though not in this particular patch).
>
> Wei
It's fine either way for me, I was trying to understand if it was an oversight or
intentional.
- Easwar (he/him)
^ permalink raw reply
* Re: [PATCH] mshv: Add support for a new parent partition configuration
From: Wei Liu @ 2025-08-19 17:22 UTC (permalink / raw)
To: Easwar Hariharan
Cc: Nuno Das Neves, linux-hyperv, linux-kernel, linux-arch, kys,
haiyangz, wei.liu, mhklinux, decui, arnd
In-Reply-To: <0a0c8921-9236-45fb-b047-742a34379e63@linux.microsoft.com>
On Tue, Aug 19, 2025 at 09:17:27AM -0700, Easwar Hariharan wrote:
> On 8/19/2025 12:29 AM, Nuno Das Neves wrote:
> > Detect booting as an "L1VH" partition. This is a new scenario very
> > similar to root partition where the mshv_root driver can be used to
> > create and manage guest partitions.
> >
> > It mostly works the same as root partition, but there are some
> > differences in how various features are handled. hv_l1vh_partition()
> > is introduced to handle these cases. Add hv_parent_partition()
> > which returns true for either case, replacing some hv_root_partition()
> > checks.
> >
> > Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
>
> Seems the plurality of subject prefixes for drivers/hv files has been "Drivers: hv"
> so far, including the 2 commits for drivers/hv/mshv*. Are you planning to change
> the standard for mshv driver going forward?
IMO it is okay to have a different prefix to call out the commits that
are relevant to the mshv driver. This eases the burden for anyone
porting the changes to a different kernel tree. We may also touch many
different parts of the codebase (though not in this particular patch).
Wei
^ permalink raw reply
* Re: [PATCH] mshv: Add support for a new parent partition configuration
From: Wei Liu @ 2025-08-19 16:46 UTC (permalink / raw)
To: Nuno Das Neves
Cc: linux-hyperv, linux-kernel, linux-arch, kys, haiyangz, wei.liu,
mhklinux, decui, arnd
In-Reply-To: <1755588559-29629-1-git-send-email-nunodasneves@linux.microsoft.com>
On Tue, Aug 19, 2025 at 12:29:19AM -0700, Nuno Das Neves wrote:
> Detect booting as an "L1VH" partition. This is a new scenario very
> similar to root partition where the mshv_root driver can be used to
> create and manage guest partitions.
>
> It mostly works the same as root partition, but there are some
> differences in how various features are handled. hv_l1vh_partition()
> is introduced to handle these cases. Add hv_parent_partition()
> which returns true for either case, replacing some hv_root_partition()
> checks.
>
> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Acked-by: Wei Liu <wei.liu@kernel.org>
^ permalink raw reply
* Re: [PATCH] mshv: Add support for a new parent partition configuration
From: Easwar Hariharan @ 2025-08-19 16:17 UTC (permalink / raw)
To: Nuno Das Neves
Cc: easwar.hariharan, linux-hyperv, linux-kernel, linux-arch, kys,
haiyangz, wei.liu, mhklinux, decui, arnd
In-Reply-To: <1755588559-29629-1-git-send-email-nunodasneves@linux.microsoft.com>
On 8/19/2025 12:29 AM, Nuno Das Neves wrote:
> Detect booting as an "L1VH" partition. This is a new scenario very
> similar to root partition where the mshv_root driver can be used to
> create and manage guest partitions.
>
> It mostly works the same as root partition, but there are some
> differences in how various features are handled. hv_l1vh_partition()
> is introduced to handle these cases. Add hv_parent_partition()
> which returns true for either case, replacing some hv_root_partition()
> checks.
>
> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Seems the plurality of subject prefixes for drivers/hv files has been "Drivers: hv"
so far, including the 2 commits for drivers/hv/mshv*. Are you planning to change
the standard for mshv driver going forward?
It'd be good to have a small blurb about what an L1VH partition is in the commit
message, as well as what guides which hv_root_partition() call gets replaced with
hv_parent_partition().
<snip>
Thanks,
Easwar (he/him)
^ permalink raw reply
* Re: [PATCH net-next v5] net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.
From: patchwork-bot+netdevbpf @ 2025-08-19 12:50 UTC (permalink / raw)
To: Dipayaan Roy
Cc: horms, kuba, kys, haiyangz, wei.liu, decui, andrew+netdev, davem,
edumazet, pabeni, longli, kotaranov, ast, daniel, hawk,
john.fastabend, sdf, lorenzo, michal.kubiak, ernis, shradhagupta,
shirazsaleem, rosenp, netdev, linux-hyperv, linux-rdma, bpf,
linux-kernel, ssengar, dipayanroy
In-Reply-To: <20250814140410.GA22089@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Thu, 14 Aug 2025 07:04:10 -0700 you wrote:
> This patch enhances RX buffer handling in the mana driver by allocating
> pages from a page pool and slicing them into MTU-sized fragments, rather
> than dedicating a full page per packet. This approach is especially
> beneficial on systems with large base page sizes like 64KB.
>
> Key improvements:
>
> [...]
Here is the summary with links:
- [net-next,v5] net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.
https://git.kernel.org/netdev/net-next/c/730ff06d3f5c
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH] mshv: Add support for a new parent partition configuration
From: Nuno Das Neves @ 2025-08-19 7:29 UTC (permalink / raw)
To: linux-hyperv, linux-kernel, linux-arch
Cc: kys, haiyangz, wei.liu, mhklinux, decui, arnd, Nuno Das Neves
Detect booting as an "L1VH" partition. This is a new scenario very
similar to root partition where the mshv_root driver can be used to
create and manage guest partitions.
It mostly works the same as root partition, but there are some
differences in how various features are handled. hv_l1vh_partition()
is introduced to handle these cases. Add hv_parent_partition()
which returns true for either case, replacing some hv_root_partition()
checks.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
---
drivers/hv/hv_common.c | 20 ++++++++++++--------
drivers/hv/mshv_root_main.c | 22 ++++++++++++++--------
include/asm-generic/mshyperv.h | 11 +++++++++++
3 files changed, 37 insertions(+), 16 deletions(-)
diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
index cbe4a954ad46..a6839593ca31 100644
--- a/drivers/hv/hv_common.c
+++ b/drivers/hv/hv_common.c
@@ -357,7 +357,7 @@ int __init hv_common_init(void)
hyperv_pcpu_arg = alloc_percpu(void *);
BUG_ON(!hyperv_pcpu_arg);
- if (hv_root_partition()) {
+ if (hv_parent_partition()) {
hv_synic_eventring_tail = alloc_percpu(u8 *);
BUG_ON(!hv_synic_eventring_tail);
}
@@ -506,7 +506,7 @@ int hv_common_cpu_init(unsigned int cpu)
if (msr_vp_index > hv_max_vp_index)
hv_max_vp_index = msr_vp_index;
- if (hv_root_partition()) {
+ if (hv_parent_partition()) {
synic_eventring_tail = (u8 **)this_cpu_ptr(hv_synic_eventring_tail);
*synic_eventring_tail = kcalloc(HV_SYNIC_SINT_COUNT,
sizeof(u8), flags);
@@ -532,7 +532,7 @@ int hv_common_cpu_die(unsigned int cpu)
* originally allocated memory is reused in hv_common_cpu_init().
*/
- if (hv_root_partition()) {
+ if (hv_parent_partition()) {
synic_eventring_tail = this_cpu_ptr(hv_synic_eventring_tail);
kfree(*synic_eventring_tail);
*synic_eventring_tail = NULL;
@@ -703,13 +703,17 @@ void hv_identify_partition_type(void)
* the root partition setting if also a Confidential VM.
*/
if ((ms_hyperv.priv_high & HV_CREATE_PARTITIONS) &&
- (ms_hyperv.priv_high & HV_CPU_MANAGEMENT) &&
!(ms_hyperv.priv_high & HV_ISOLATION)) {
- pr_info("Hyper-V: running as root partition\n");
- if (IS_ENABLED(CONFIG_MSHV_ROOT))
- hv_curr_partition_type = HV_PARTITION_TYPE_ROOT;
- else
+
+ if (!IS_ENABLED(CONFIG_MSHV_ROOT)) {
pr_crit("Hyper-V: CONFIG_MSHV_ROOT not enabled!\n");
+ } else if (ms_hyperv.priv_high & HV_CPU_MANAGEMENT) {
+ pr_info("Hyper-V: running as root partition\n");
+ hv_curr_partition_type = HV_PARTITION_TYPE_ROOT;
+ } else {
+ pr_info("Hyper-V: running as L1VH partition\n");
+ hv_curr_partition_type = HV_PARTITION_TYPE_L1VH;
+ }
}
}
diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
index aca3331ad516..7c710703cd96 100644
--- a/drivers/hv/mshv_root_main.c
+++ b/drivers/hv/mshv_root_main.c
@@ -37,12 +37,6 @@ MODULE_AUTHOR("Microsoft");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Microsoft Hyper-V root partition VMM interface /dev/mshv");
-/* TODO move this to mshyperv.h when needed outside driver */
-static inline bool hv_parent_partition(void)
-{
- return hv_root_partition();
-}
-
/* TODO move this to another file when debugfs code is added */
enum hv_stats_vp_counters { /* HV_THREAD_COUNTER */
#if defined(CONFIG_X86)
@@ -2190,6 +2184,15 @@ struct notifier_block mshv_reboot_nb = {
.notifier_call = mshv_reboot_notify,
};
+static int __init mshv_l1vh_partition_init(struct device *dev)
+{
+ hv_scheduler_type = HV_SCHEDULER_TYPE_CORE_SMT;
+ dev_info(dev, "Hypervisor using %s\n",
+ scheduler_type_to_string(hv_scheduler_type));
+
+ return 0;
+}
+
static void mshv_root_partition_exit(void)
{
unregister_reboot_notifier(&mshv_reboot_nb);
@@ -2224,7 +2227,7 @@ static int __init mshv_parent_partition_init(void)
struct device *dev;
union hv_hypervisor_version_info version_info;
- if (!hv_root_partition() || is_kdump_kernel())
+ if (!hv_parent_partition() || is_kdump_kernel())
return -ENODEV;
if (hv_get_hypervisor_version(&version_info))
@@ -2261,7 +2264,10 @@ static int __init mshv_parent_partition_init(void)
mshv_cpuhp_online = ret;
- ret = mshv_root_partition_init(dev);
+ if (hv_root_partition())
+ ret = mshv_root_partition_init(dev);
+ else
+ ret = mshv_l1vh_partition_init(dev);
if (ret)
goto remove_cpu_state;
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index dbbacd47ca35..f0f0eacb2eef 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -31,6 +31,7 @@
enum hv_partition_type {
HV_PARTITION_TYPE_GUEST,
HV_PARTITION_TYPE_ROOT,
+ HV_PARTITION_TYPE_L1VH,
};
struct ms_hyperv_info {
@@ -457,12 +458,22 @@ static inline bool hv_root_partition(void)
{
return hv_curr_partition_type == HV_PARTITION_TYPE_ROOT;
}
+static inline bool hv_l1vh_partition(void)
+{
+ return hv_curr_partition_type == HV_PARTITION_TYPE_L1VH;
+}
+static inline bool hv_parent_partition(void)
+{
+ return hv_root_partition() || hv_l1vh_partition();
+}
int hv_call_deposit_pages(int node, u64 partition_id, u32 num_pages);
int hv_call_add_logical_proc(int node, u32 lp_index, u32 acpi_id);
int hv_call_create_vp(int node, u64 partition_id, u32 vp_index, u32 flags);
#else /* CONFIG_MSHV_ROOT */
static inline bool hv_root_partition(void) { return false; }
+static inline bool hv_l1vh_partition(void) { return false; }
+static inline bool hv_parent_partition(void) { return false; }
static inline int hv_call_deposit_pages(int node, u64 partition_id, u32 num_pages)
{
return -EOPNOTSUPP;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 14/16] x86/fred: Play nice with invoking asm_fred_entry_from_kvm() on non-FRED hardware
From: Peter Zijlstra @ 2025-08-18 12:09 UTC (permalink / raw)
To: Xin Li
Cc: x86, kys, haiyangz, wei.liu, decui, tglx, mingo, bp, dave.hansen,
hpa, seanjc, pbonzini, ardb, kees, Arnd Bergmann, gregkh,
jpoimboe, linux-hyperv, linux-kernel, kvm, linux-efi,
samitolvanen, ojeda
In-Reply-To: <f6925ee5-bbd7-42e3-9e3b-59d2e8ec2681@zytor.com>
On Fri, Jul 25, 2025 at 09:54:32PM -0700, Xin Li wrote:
> On 7/14/2025 3:20 AM, Peter Zijlstra wrote:
> > call __fred_entry_from_kvm /* Call the C entry point */
> > - POP_REGS
> > - ERETS
> > -1:
> > +
> > +1: /*
>
> The symbol "1" is misplaced; it needs to be put after the ERETS
> instruction.
Doh, fixed.
> > + * When FRED, use ERETS to potentially clear NMIs, otherwise simply
> > + * restore the stack pointer.
> > + */
> > + ALTERNATIVE "nop; nop; mov %rbp, %rsp", \
>
> Why explicitly add two nops here?
Because the CFI information for all alternative code flows must be the
same. So by playing games with instruction offsets you can have
conflicting CFI inside the alternative.
Specifically, we have:
0: 90 nop
1: 90 nop
2: 48 89 ec mov %rbp, %rsp
0: 48 83 c4 0c add $12, %rsp
4: f2 0f 01 ca erets
This gets us CFI updates on 0, 2 and 4, without conflicts.
> ALTERNATIVE will still pad three-byte nop after the MOV instruction.
>
> > + __stringify(add $C_PTREGS_SIZE, %rsp; ERETS), \
> > + X86_FEATURE_FRED
> > +
> > /*
> > - * Objtool doesn't understand what ERETS does, this hint tells it that
> > - * yes, we'll reach here and with what stack state. A save/restore pair
> > - * isn't strictly needed, but it's the simplest form.
> > + * Objtool doesn't understand ERETS, and the cfi register state is
> > + * different from initial_func_cfi due to PUSH_REGS. Tell it the state
> > + * is similar to where UNWIND_HINT_SAVE is.
> > */
> > UNWIND_HINT_RESTORE
> > +
> > pop %rbp
> > RET
>
^ permalink raw reply
* Re: [PATCH v3 12/16] x86_64,hyperv: Use direct call to hypercall-page
From: Peter Zijlstra @ 2025-08-18 10:46 UTC (permalink / raw)
To: Michael Kelley
Cc: x86@kernel.org, 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: <SN6PR02MB4157F2108DDFBD991F5E926DD457A@SN6PR02MB4157.namprd02.prod.outlook.com>
On Tue, Jul 15, 2025 at 02:52:04PM +0000, Michael Kelley wrote:
> 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.
Sure, done. Thanks!
^ permalink raw reply
* Re: [PATCH v3 07/16] x86/kvm/emulate: Introduce EM_ASM_1SRC2
From: Peter Zijlstra @ 2025-08-18 10:37 UTC (permalink / raw)
To: Sean Christopherson
Cc: x86, kys, haiyangz, wei.liu, decui, tglx, mingo, bp, dave.hansen,
hpa, pbonzini, ardb, kees, Arnd Bergmann, gregkh, jpoimboe,
linux-hyperv, linux-kernel, kvm, linux-efi, samitolvanen, ojeda
In-Reply-To: <aIF7ZhWZxlkcpm4y@google.com>
On Wed, Jul 23, 2025 at 05:16:38PM -0700, Sean Christopherson wrote:
> For all of the KVM patches, please use
>
> KVM: x86:
>
> "x86/kvm" is used for guest-side code, and while I hope no one will conflate this
> with guest code, the consistency is helpful.
Sure.
> On Mon, Jul 14, 2025, Peter Zijlstra wrote:
> > Replace the FASTOP1SRC2*() instructions.
> >
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > ---
> > arch/x86/kvm/emulate.c | 34 ++++++++++++++++++++++++++--------
> > 1 file changed, 26 insertions(+), 8 deletions(-)
> >
> > --- a/arch/x86/kvm/emulate.c
> > +++ b/arch/x86/kvm/emulate.c
> > @@ -317,6 +317,24 @@ static int em_##op(struct x86_emulate_ct
> > ON64(case 8: __EM_ASM_1(op##q, rax); break;) \
> > EM_ASM_END
> >
> > +/* 1-operand, using "c" (src2) */
> > +#define EM_ASM_1SRC2(op, name) \
> > + EM_ASM_START(name) \
> > + case 1: __EM_ASM_1(op##b, cl); break; \
> > + case 2: __EM_ASM_1(op##w, cx); break; \
> > + case 4: __EM_ASM_1(op##l, ecx); break; \
> > + ON64(case 8: __EM_ASM_1(op##q, rcx); break;) \
> > + EM_ASM_END
> > +
> > +/* 1-operand, using "c" (src2) with exception */
> > +#define EM_ASM_1SRC2EX(op, name) \
> > + EM_ASM_START(name) \
> > + case 1: __EM_ASM_1_EX(op##b, cl); break; \
> > + case 2: __EM_ASM_1_EX(op##w, cx); break; \
> > + case 4: __EM_ASM_1_EX(op##l, ecx); break; \
> > + ON64(case 8: __EM_ASM_1(op##q, rcx); break;) \
>
> This needs to be __EM_ASM_1_EX(). Luckily, KVM-Unit-Tests actually has testcase
> for divq (somewhere in the morass of testcases). I also now have an extension to
> the fastops selftest to explicitly test all four flavors of div-by-zero; I'll get
> it posted tomorrow.
>
> (also, don't also me how long it took me to spot the copy+paste typo; I was full
> on debugging the exception fixup code before I realized my local diff looked
> "odd", *sigh*)
Urgh, sorry about that. Typically I use regex for these things, clearly
I messed up here.
Thanks and fixed!
^ permalink raw reply
* [PATCH v2] x86/hyperv: Fix kdump on Azure CVMs
From: Vitaly Kuznetsov @ 2025-08-18 9:54 UTC (permalink / raw)
To: linux-hyperv
Cc: K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, x86,
linux-kernel, Nuno Das Neves, Tianyu Lan, Michael Kelley, Li Tian,
Philipp Rudo
Azure CVM instance types featuring a paravisor hang upon kdump. The
investigation shows that makedumpfile causes a hang when it steps on a page
which was previously share with the host
(HVCALL_MODIFY_SPARSE_GPA_PAGE_HOST_VISIBILITY). The new kernel has no
knowledge of these 'special' regions (which are Vmbus connection pages,
GPADL buffers, ...). There are several ways to approach the issue:
- Convey the knowledge about these regions to the new kernel somehow.
- Unshare these regions before accessing in the new kernel (it is unclear
if there's a way to query the status for a given GPA range).
- Unshare these regions before jumping to the new kernel (which this patch
implements).
To make the procedure as robust as possible, store PFN ranges of shared
regions in a linked list instead of storing GVAs and re-using
hv_vtom_set_host_visibility(). This also allows to avoid memory allocation
on the kdump/kexec path.
The patch skips implementing weird corner case in hv_list_enc_remove()
when a PFN in the middle of a region is unshared. First, it is unlikely
that such requests happen. Second, it is not a big problem if
hv_list_enc_remove() doesn't actually remove some regions as this will
only result in an extra hypercall doing nothing upon kexec/kdump; there's
no need to be perfect.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
Changes since v1:
- fix build on ARM [kernel test robot]
---
arch/arm64/include/asm/mshyperv.h | 3 +
arch/x86/hyperv/ivm.c | 153 ++++++++++++++++++++++++++++++
arch/x86/include/asm/mshyperv.h | 2 +
drivers/hv/vmbus_drv.c | 2 +
4 files changed, 160 insertions(+)
diff --git a/arch/arm64/include/asm/mshyperv.h b/arch/arm64/include/asm/mshyperv.h
index b721d3134ab6..af11abf403b4 100644
--- a/arch/arm64/include/asm/mshyperv.h
+++ b/arch/arm64/include/asm/mshyperv.h
@@ -53,6 +53,9 @@ static inline u64 hv_get_non_nested_msr(unsigned int reg)
return hv_get_msr(reg);
}
+/* Isolated VMs are unsupported on ARM, no cleanup needed */
+static inline void hv_ivm_clear_host_access(void) {}
+
/* SMCCC hypercall parameters */
#define HV_SMCCC_FUNC_NUMBER 1
#define HV_FUNC_ID ARM_SMCCC_CALL_VAL( \
diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c
index ade6c665c97e..a6e614672836 100644
--- a/arch/x86/hyperv/ivm.c
+++ b/arch/x86/hyperv/ivm.c
@@ -462,6 +462,150 @@ void hv_ivm_msr_read(u64 msr, u64 *value)
hv_ghcb_msr_read(msr, value);
}
+/*
+ * Keep track of the PFN regions which were shared with the host. The access
+ * must be revoked upon kexec/kdump (see hv_ivm_clear_host_access()).
+ */
+struct hv_enc_pfn_region {
+ struct list_head list;
+ u64 pfn;
+ int count;
+};
+
+static LIST_HEAD(hv_list_enc);
+static DEFINE_RAW_SPINLOCK(hv_list_enc_lock);
+
+static int hv_list_enc_add(const u64 *pfn_list, int count)
+{
+ struct hv_enc_pfn_region *ent;
+ unsigned long flags;
+ bool found = false;
+ u64 pfn;
+ int i;
+
+ for (i = 0; i < count; i++) {
+ pfn = pfn_list[i];
+
+ found = false;
+ raw_spin_lock_irqsave(&hv_list_enc_lock, flags);
+ list_for_each_entry(ent, &hv_list_enc, list) {
+ if ((ent->pfn <= pfn) && (ent->pfn + ent->count - 1 >= pfn)) {
+ /* Nothin to do - pfn is already in the list */
+ found = true;
+ } else if (ent->pfn + ent->count == pfn) {
+ /* Grow existing region up */
+ found = true;
+ ent->count++;
+ } else if (pfn + 1 == ent->pfn) {
+ /* Grow existing region down */
+ found = true;
+ ent->pfn--;
+ ent->count++;
+ }
+ };
+ raw_spin_unlock_irqrestore(&hv_list_enc_lock, flags);
+
+ if (found)
+ continue;
+
+ /* No adajacent region found -- creating a new one */
+ ent = kzalloc(sizeof(struct hv_enc_pfn_region), GFP_KERNEL);
+ if (!ent)
+ return -ENOMEM;
+
+ ent->pfn = pfn;
+ ent->count = 1;
+
+ raw_spin_lock_irqsave(&hv_list_enc_lock, flags);
+ list_add(&ent->list, &hv_list_enc);
+ raw_spin_unlock_irqrestore(&hv_list_enc_lock, flags);
+ }
+
+ return 0;
+}
+
+static void hv_list_enc_remove(const u64 *pfn_list, int count)
+{
+ struct hv_enc_pfn_region *ent, *t;
+ unsigned long flags;
+ u64 pfn;
+ int i;
+
+ for (i = 0; i < count; i++) {
+ pfn = pfn_list[i];
+
+ raw_spin_lock_irqsave(&hv_list_enc_lock, flags);
+ list_for_each_entry_safe(ent, t, &hv_list_enc, list) {
+ if (pfn == ent->pfn + count - 1) {
+ /* Removing tail pfn */
+ ent->count--;
+ if (!ent->count) {
+ list_del(&ent->list);
+ kfree(ent);
+ }
+ } else if (pfn == ent->pfn) {
+ /* Removing head pfn */
+ ent->count--;
+ ent->pfn++;
+ if (!ent->count) {
+ list_del(&ent->list);
+ kfree(ent);
+ }
+ }
+
+ /*
+ * Removing PFNs in the middle of a region is not implemented; the
+ * list is currently only used for cleanup upon kexec and there's
+ * no harm done if we issue an extra unneeded hypercall making some
+ * region encrypted when it already is.
+ */
+ };
+ raw_spin_unlock_irqrestore(&hv_list_enc_lock, flags);
+ }
+}
+
+void hv_ivm_clear_host_access(void)
+{
+ struct hv_gpa_range_for_visibility *input;
+ struct hv_enc_pfn_region *ent;
+ unsigned long flags;
+ u64 hv_status;
+ int cur, i;
+
+ if (!hv_is_isolation_supported())
+ return;
+
+ raw_spin_lock_irqsave(&hv_list_enc_lock, flags);
+
+ input = *this_cpu_ptr(hyperv_pcpu_input_arg);
+ if (!input)
+ goto unlock;
+
+ list_for_each_entry(ent, &hv_list_enc, list) {
+ for (i = 0, cur = 0; i < ent->count; i++) {
+ input->gpa_page_list[cur] = ent->pfn + i;
+ cur++;
+
+ if (cur == HV_MAX_MODIFY_GPA_REP_COUNT || i == ent->count - 1) {
+ input->partition_id = HV_PARTITION_ID_SELF;
+ input->host_visibility = VMBUS_PAGE_NOT_VISIBLE;
+ input->reserved0 = 0;
+ input->reserved1 = 0;
+ hv_status = hv_do_rep_hypercall(
+ HVCALL_MODIFY_SPARSE_GPA_PAGE_HOST_VISIBILITY,
+ cur, 0, input, NULL);
+ WARN_ON_ONCE(!hv_result_success(hv_status));
+ cur = 0;
+ }
+ }
+
+ };
+
+unlock:
+ raw_spin_unlock_irqrestore(&hv_list_enc_lock, flags);
+}
+EXPORT_SYMBOL_GPL(hv_ivm_clear_host_access);
+
/*
* hv_mark_gpa_visibility - Set pages visible to host via hvcall.
*
@@ -475,6 +619,7 @@ static int hv_mark_gpa_visibility(u16 count, const u64 pfn[],
struct hv_gpa_range_for_visibility *input;
u64 hv_status;
unsigned long flags;
+ int ret;
/* no-op if partition isolation is not enabled */
if (!hv_is_isolation_supported())
@@ -486,6 +631,14 @@ static int hv_mark_gpa_visibility(u16 count, const u64 pfn[],
return -EINVAL;
}
+ if (visibility == VMBUS_PAGE_NOT_VISIBLE) {
+ hv_list_enc_remove(pfn, count);
+ } else {
+ ret = hv_list_enc_add(pfn, count);
+ if (ret)
+ return ret;
+ }
+
local_irq_save(flags);
input = *this_cpu_ptr(hyperv_pcpu_input_arg);
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index abc4659f5809..6a988001e46f 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -263,10 +263,12 @@ static inline int hv_snp_boot_ap(u32 apic_id, unsigned long start_ip,
void hv_vtom_init(void);
void hv_ivm_msr_write(u64 msr, u64 value);
void hv_ivm_msr_read(u64 msr, u64 *value);
+void hv_ivm_clear_host_access(void);
#else
static inline void hv_vtom_init(void) {}
static inline void hv_ivm_msr_write(u64 msr, u64 value) {}
static inline void hv_ivm_msr_read(u64 msr, u64 *value) {}
+static inline void hv_ivm_clear_host_access(void) {}
#endif
static inline bool hv_is_synic_msr(unsigned int reg)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 2ed5a1e89d69..2e891e108218 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -2784,6 +2784,7 @@ static void hv_kexec_handler(void)
/* Make sure conn_state is set as hv_synic_cleanup checks for it */
mb();
cpuhp_remove_state(hyperv_cpuhp_online);
+ hv_ivm_clear_host_access();
};
static void hv_crash_handler(struct pt_regs *regs)
@@ -2799,6 +2800,7 @@ static void hv_crash_handler(struct pt_regs *regs)
cpu = smp_processor_id();
hv_stimer_cleanup(cpu);
hv_synic_disable_regs(cpu);
+ hv_ivm_clear_host_access();
};
static int hv_synic_suspend(void)
--
2.50.0
^ permalink raw reply related
* Re: [PATCH] mm/numa: Rename memory_add_physaddr_to_nid to memory_get_phys_to_nid
From: Pratyush Brahma @ 2025-08-18 8:34 UTC (permalink / raw)
To: David Hildenbrand
Cc: Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Rafael J. Wysocki, Len Brown, Dan Williams, Vishal Verma,
Dave Jiang, Ira Weiny, Oscar Salvador, Greg Kroah-Hartman,
Danilo Krummrich, Davidlohr Bueso, Jonathan Cameron,
Alison Schofield, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Pankaj Gupta, Michael S. Tsirkin, Jason Wang,
Xuan Zhuo, Eugenio Pérez, Juergen Gross, Stefano Stabellini,
Oleksandr Tyshchenko, Andrew Morton, Mike Rapoport, linuxppc-dev,
linux-kernel, linux-s390, linux-acpi, nvdimm, linux-mm, linux-cxl,
linux-hyperv, virtualization, xen-devel
In-Reply-To: <63082884-1fe2-4740-8e6a-e1d06aa5e239@redhat.com>
On Mon, Aug 18, 2025 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
>
> On 18.08.25 10:27, Pratyush Brahma wrote:
> > On Mon, Aug 18, 2025 at 12:29 PM David Hildenbrand <david@redhat.com> wrote:
> >>
> >> On 18.08.25 08:41, pratyush.brahma@oss.qualcomm.com wrote:
> >>> From: Pratyush Brahma <pratyush.brahma@oss.qualcomm.com>
> >>>
> >>> The function `memory_add_physaddr_to_nid` seems a misnomer.
> >>> It does not to "add" a physical address to a NID mapping,
> >>> but rather it gets the NID associated with a given physical address.
> >>
> >> You probably misunderstood what the function is used for: memory hotplug
> >> aka "memory_add".
> > Thanks for your feedback. I get the part about memory hotplug here but
> > using memory_add still seems a little odd as it doesn't truly reflect
> > what this api is doing.
> > However, I agree that my current suggestion
> > may not be the perfect choice for the name, so I'm open to suggestions.
> >
> > Perhaps, something like "memory_add_get_nid_by_phys" may work here?
>
> I don't think this name is really any better and worth the churn :(
>
Sure. Thanks for taking a look. Will drop this.
> --
> Cheers
>
> David / dhildenb
>
Thanks & Regards
Pratyush
^ permalink raw reply
* Re: [PATCH] mm/numa: Rename memory_add_physaddr_to_nid to memory_get_phys_to_nid
From: David Hildenbrand @ 2025-08-18 8:31 UTC (permalink / raw)
To: Pratyush Brahma
Cc: Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Rafael J. Wysocki, Len Brown, Dan Williams, Vishal Verma,
Dave Jiang, Ira Weiny, Oscar Salvador, Greg Kroah-Hartman,
Danilo Krummrich, Davidlohr Bueso, Jonathan Cameron,
Alison Schofield, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Pankaj Gupta, Michael S. Tsirkin, Jason Wang,
Xuan Zhuo, Eugenio Pérez, Juergen Gross, Stefano Stabellini,
Oleksandr Tyshchenko, Andrew Morton, Mike Rapoport, linuxppc-dev,
linux-kernel, linux-s390, linux-acpi, nvdimm, linux-mm, linux-cxl,
linux-hyperv, virtualization, xen-devel
In-Reply-To: <CALzOmR0C8BFY+-u-_aprVeAhq4uPOQa+f2L5m+yZH+=XZ2cv_w@mail.gmail.com>
On 18.08.25 10:27, Pratyush Brahma wrote:
> On Mon, Aug 18, 2025 at 12:29 PM David Hildenbrand <david@redhat.com> wrote:
>>
>> On 18.08.25 08:41, pratyush.brahma@oss.qualcomm.com wrote:
>>> From: Pratyush Brahma <pratyush.brahma@oss.qualcomm.com>
>>>
>>> The function `memory_add_physaddr_to_nid` seems a misnomer.
>>> It does not to "add" a physical address to a NID mapping,
>>> but rather it gets the NID associated with a given physical address.
>>
>> You probably misunderstood what the function is used for: memory hotplug
>> aka "memory_add".
> Thanks for your feedback. I get the part about memory hotplug here but
> using memory_add still seems a little odd as it doesn't truly reflect
> what this api is doing.
> However, I agree that my current suggestion
> may not be the perfect choice for the name, so I'm open to suggestions.
>
> Perhaps, something like "memory_add_get_nid_by_phys" may work here?
I don't think this name is really any better and worth the churn :(
--
Cheers
David / dhildenb
^ permalink raw reply
* Re: [PATCH] mm/numa: Rename memory_add_physaddr_to_nid to memory_get_phys_to_nid
From: Pratyush Brahma @ 2025-08-18 8:27 UTC (permalink / raw)
To: David Hildenbrand
Cc: Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Rafael J. Wysocki, Len Brown, Dan Williams, Vishal Verma,
Dave Jiang, Ira Weiny, Oscar Salvador, Greg Kroah-Hartman,
Danilo Krummrich, Davidlohr Bueso, Jonathan Cameron,
Alison Schofield, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Pankaj Gupta, Michael S. Tsirkin, Jason Wang,
Xuan Zhuo, Eugenio Pérez, Juergen Gross, Stefano Stabellini,
Oleksandr Tyshchenko, Andrew Morton, Mike Rapoport, linuxppc-dev,
linux-kernel, linux-s390, linux-acpi, nvdimm, linux-mm, linux-cxl,
linux-hyperv, virtualization, xen-devel
In-Reply-To: <d7cdb65d-c241-478c-aa01-bc1a5f188e4f@redhat.com>
On Mon, Aug 18, 2025 at 12:29 PM David Hildenbrand <david@redhat.com> wrote:
>
> On 18.08.25 08:41, pratyush.brahma@oss.qualcomm.com wrote:
> > From: Pratyush Brahma <pratyush.brahma@oss.qualcomm.com>
> >
> > The function `memory_add_physaddr_to_nid` seems a misnomer.
> > It does not to "add" a physical address to a NID mapping,
> > but rather it gets the NID associated with a given physical address.
>
> You probably misunderstood what the function is used for: memory hotplug
> aka "memory_add".
Thanks for your feedback. I get the part about memory hotplug here but
using memory_add still seems a little odd as it doesn't truly reflect
what this api is doing.
However, I agree that my current suggestion
may not be the perfect choice for the name, so I'm open to suggestions.
Perhaps, something like "memory_add_get_nid_by_phys" may work here?
>
> This patch is making matters worse by stripping that detail, unfortunately.
>
>
> --
> Cheers
>
> David / dhildenb
>
Thanks and Regards
Pratyush
^ permalink raw reply
* Re: [PATCH] uio_hv_generic: Let userspace take care of interrupt mask
From: Naman Jain @ 2025-08-18 8:24 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui,
Michael Kelley, linux-hyperv, linux-kernel, John Starks
In-Reply-To: <2025081810-faculty-ceramics-42eb@gregkh>
On 8/18/2025 12:55 PM, Greg Kroah-Hartman wrote:
> On Mon, Aug 18, 2025 at 12:18:46PM +0530, Naman Jain wrote:
>> Remove the logic to set interrupt mask by default in uio_hv_generic
>> driver as the interrupt mask value is supposed to be controlled
>> completely by the user space. If the mask bit gets changed
>> by the driver, concurrently with user mode operating on the ring,
>> the mask bit may be set when it is supposed to be clear, and the
>> user-mode driver will miss an interrupt which will cause a hang.
>>
>> For eg- when the driver sets inbound ring buffer interrupt mask to 1,
>> the host does not interrupt the guest on the UIO VMBus channel.
>> However, setting the mask does not prevent the host from putting a
>> message in the inbound ring buffer. So let’s assume that happens,
>> the host puts a message into the ring buffer but does not interrupt.
>>
>> Subsequently, the user space code in the guest sets the inbound ring
>> buffer interrupt mask to 0, saying “Hey, I’m ready for interrupts”.
>> User space code then calls pread() to wait for an interrupt.
>> Then one of two things happens:
>>
>> * The host never sends another message. So the pread() waits forever.
>> * The host does send another message. But because there’s already a
>> message in the ring buffer, it doesn’t generate an interrupt.
>> This is the correct behavior, because the host should only send an
>> interrupt when the inbound ring buffer transitions from empty to
>> not-empty. Adding an additional message to a ring buffer that is not
>> empty is not supposed to generate an interrupt on the guest.
>> Since the guest is waiting in pread() and not removing messages from
>> the ring buffer, the pread() waits forever.
>>
>> This could be easily reproduced in hv_fcopy_uio_daemon if we delay
>> setting interrupt mask to 0.
>>
>> Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1,
>> there’s a race condition. Once user space empties the inbound ring
>> buffer, but before user space sets interrupt_mask to 0, the host could
>> put another message in the ring buffer but it wouldn’t interrupt.
>> Then the next pread() would hang.
>>
>> Fix these by removing all instances where interrupt_mask is changed,
>> while keeping the one in set_event() unchanged to enable userspace
>> control the interrupt mask by writing 0/1 to /dev/uioX.
>>
>> Suggested-by: John Starks <jostarks@microsoft.com>
>> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
>> ---
>> drivers/uio/uio_hv_generic.c | 7 +------
>> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> What commit id does this fix?
This is supposed to fix the first commit that introduced this driver -
95096f2fbd10 ("uio-hv-generic: new userspace i/o driver for VMBus").
Will add the Fix tag in next version.
Thanks,
Naman
^ permalink raw reply
* Re: [PATCH] x86/hyperv: Fix kdump on Azure CVMs
From: Vitaly Kuznetsov @ 2025-08-18 7:57 UTC (permalink / raw)
To: kernel test robot, linux-hyperv
Cc: oe-kbuild-all, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, x86, linux-kernel, Nuno Das Neves, Tianyu Lan,
Michael Kelley, Li Tian, Philipp Rudo
In-Reply-To: <202508161430.0GC3nT8J-lkp@intel.com>
kernel test robot <lkp@intel.com> writes:
> Hi Vitaly,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on tip/x86/core]
> [also build test ERROR on linus/master v6.17-rc1]
> [cannot apply to next-20250815]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url: https://github.com/intel-lab-lkp/linux/commits/Vitaly-Kuznetsov/x86-hyperv-Fix-kdump-on-Azure-CVMs/20250815-214053
> base: tip/x86/core
> patch link: https://lore.kernel.org/r/20250815133725.1591863-1-vkuznets%40redhat.com
> patch subject: [PATCH] x86/hyperv: Fix kdump on Azure CVMs
> config: arm64-randconfig-003-20250816 (https://download.01.org/0day-ci/archive/20250816/202508161430.0GC3nT8J-lkp@intel.com/config)
> compiler: aarch64-linux-gcc (GCC) 8.5.0
Rats, I completely forgot about ARM, will add a stub to
arch/arm64/include/asm/mshyperv.h in v2.
--
Vitaly
^ permalink raw reply
* Re: [PATCH] uio_hv_generic: Let userspace take care of interrupt mask
From: Greg Kroah-Hartman @ 2025-08-18 7:25 UTC (permalink / raw)
To: Naman Jain
Cc: K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui,
Michael Kelley, linux-hyperv, linux-kernel, John Starks
In-Reply-To: <20250818064846.271294-1-namjain@linux.microsoft.com>
On Mon, Aug 18, 2025 at 12:18:46PM +0530, Naman Jain wrote:
> Remove the logic to set interrupt mask by default in uio_hv_generic
> driver as the interrupt mask value is supposed to be controlled
> completely by the user space. If the mask bit gets changed
> by the driver, concurrently with user mode operating on the ring,
> the mask bit may be set when it is supposed to be clear, and the
> user-mode driver will miss an interrupt which will cause a hang.
>
> For eg- when the driver sets inbound ring buffer interrupt mask to 1,
> the host does not interrupt the guest on the UIO VMBus channel.
> However, setting the mask does not prevent the host from putting a
> message in the inbound ring buffer. So let’s assume that happens,
> the host puts a message into the ring buffer but does not interrupt.
>
> Subsequently, the user space code in the guest sets the inbound ring
> buffer interrupt mask to 0, saying “Hey, I’m ready for interrupts”.
> User space code then calls pread() to wait for an interrupt.
> Then one of two things happens:
>
> * The host never sends another message. So the pread() waits forever.
> * The host does send another message. But because there’s already a
> message in the ring buffer, it doesn’t generate an interrupt.
> This is the correct behavior, because the host should only send an
> interrupt when the inbound ring buffer transitions from empty to
> not-empty. Adding an additional message to a ring buffer that is not
> empty is not supposed to generate an interrupt on the guest.
> Since the guest is waiting in pread() and not removing messages from
> the ring buffer, the pread() waits forever.
>
> This could be easily reproduced in hv_fcopy_uio_daemon if we delay
> setting interrupt mask to 0.
>
> Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1,
> there’s a race condition. Once user space empties the inbound ring
> buffer, but before user space sets interrupt_mask to 0, the host could
> put another message in the ring buffer but it wouldn’t interrupt.
> Then the next pread() would hang.
>
> Fix these by removing all instances where interrupt_mask is changed,
> while keeping the one in set_event() unchanged to enable userspace
> control the interrupt mask by writing 0/1 to /dev/uioX.
>
> Suggested-by: John Starks <jostarks@microsoft.com>
> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
> ---
> drivers/uio/uio_hv_generic.c | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
What commit id does this fix?
^ permalink raw reply
* Re: [PATCH] mm/numa: Rename memory_add_physaddr_to_nid to memory_get_phys_to_nid
From: David Hildenbrand @ 2025-08-18 6:58 UTC (permalink / raw)
To: pratyush.brahma, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Rafael J. Wysocki, Len Brown, Dan Williams, Vishal Verma,
Dave Jiang, Ira Weiny, Oscar Salvador, Greg Kroah-Hartman,
Danilo Krummrich, Davidlohr Bueso, Jonathan Cameron,
Alison Schofield, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Pankaj Gupta, Michael S. Tsirkin, Jason Wang,
Xuan Zhuo, Eugenio Pérez, Juergen Gross, Stefano Stabellini,
Oleksandr Tyshchenko, Andrew Morton, Mike Rapoport
Cc: linuxppc-dev, linux-kernel, linux-s390, linux-acpi, nvdimm,
linux-mm, linux-cxl, linux-hyperv, virtualization, xen-devel
In-Reply-To: <20250818-numa_memblks-v1-1-9eb29ade560a@oss.qualcomm.com>
On 18.08.25 08:41, pratyush.brahma@oss.qualcomm.com wrote:
> From: Pratyush Brahma <pratyush.brahma@oss.qualcomm.com>
>
> The function `memory_add_physaddr_to_nid` seems a misnomer.
> It does not to "add" a physical address to a NID mapping,
> but rather it gets the NID associated with a given physical address.
You probably misunderstood what the function is used for: memory hotplug
aka "memory_add".
This patch is making matters worse by stripping that detail, unfortunately.
--
Cheers
David / dhildenb
^ permalink raw reply
* [PATCH] uio_hv_generic: Let userspace take care of interrupt mask
From: Naman Jain @ 2025-08-18 6:48 UTC (permalink / raw)
To: Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Michael Kelley
Cc: linux-hyperv, linux-kernel, namjain, John Starks
Remove the logic to set interrupt mask by default in uio_hv_generic
driver as the interrupt mask value is supposed to be controlled
completely by the user space. If the mask bit gets changed
by the driver, concurrently with user mode operating on the ring,
the mask bit may be set when it is supposed to be clear, and the
user-mode driver will miss an interrupt which will cause a hang.
For eg- when the driver sets inbound ring buffer interrupt mask to 1,
the host does not interrupt the guest on the UIO VMBus channel.
However, setting the mask does not prevent the host from putting a
message in the inbound ring buffer. So let’s assume that happens,
the host puts a message into the ring buffer but does not interrupt.
Subsequently, the user space code in the guest sets the inbound ring
buffer interrupt mask to 0, saying “Hey, I’m ready for interrupts”.
User space code then calls pread() to wait for an interrupt.
Then one of two things happens:
* The host never sends another message. So the pread() waits forever.
* The host does send another message. But because there’s already a
message in the ring buffer, it doesn’t generate an interrupt.
This is the correct behavior, because the host should only send an
interrupt when the inbound ring buffer transitions from empty to
not-empty. Adding an additional message to a ring buffer that is not
empty is not supposed to generate an interrupt on the guest.
Since the guest is waiting in pread() and not removing messages from
the ring buffer, the pread() waits forever.
This could be easily reproduced in hv_fcopy_uio_daemon if we delay
setting interrupt mask to 0.
Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1,
there’s a race condition. Once user space empties the inbound ring
buffer, but before user space sets interrupt_mask to 0, the host could
put another message in the ring buffer but it wouldn’t interrupt.
Then the next pread() would hang.
Fix these by removing all instances where interrupt_mask is changed,
while keeping the one in set_event() unchanged to enable userspace
control the interrupt mask by writing 0/1 to /dev/uioX.
Suggested-by: John Starks <jostarks@microsoft.com>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
drivers/uio/uio_hv_generic.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c
index f19efad4d6f8..3f8e2e27697f 100644
--- a/drivers/uio/uio_hv_generic.c
+++ b/drivers/uio/uio_hv_generic.c
@@ -111,7 +111,6 @@ static void hv_uio_channel_cb(void *context)
struct hv_device *hv_dev;
struct hv_uio_private_data *pdata;
- chan->inbound.ring_buffer->interrupt_mask = 1;
virt_mb();
/*
@@ -183,8 +182,6 @@ hv_uio_new_channel(struct vmbus_channel *new_sc)
return;
}
- /* Disable interrupts on sub channel */
- new_sc->inbound.ring_buffer->interrupt_mask = 1;
set_channel_read_mode(new_sc, HV_CALL_ISR);
ret = hv_create_ring_sysfs(new_sc, hv_uio_ring_mmap);
if (ret) {
@@ -227,9 +224,7 @@ hv_uio_open(struct uio_info *info, struct inode *inode)
ret = vmbus_connect_ring(dev->channel,
hv_uio_channel_cb, dev->channel);
- if (ret == 0)
- dev->channel->inbound.ring_buffer->interrupt_mask = 1;
- else
+ if (ret)
atomic_dec(&pdata->refcnt);
return ret;
--
2.34.1
^ permalink raw reply related
* [PATCH] mm/numa: Rename memory_add_physaddr_to_nid to memory_get_phys_to_nid
From: pratyush.brahma @ 2025-08-18 6:41 UTC (permalink / raw)
To: Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Rafael J. Wysocki, Len Brown, Dan Williams, Vishal Verma,
Dave Jiang, Ira Weiny, David Hildenbrand, Oscar Salvador,
Greg Kroah-Hartman, Danilo Krummrich, Davidlohr Bueso,
Jonathan Cameron, Alison Schofield, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Pankaj Gupta,
Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko,
Andrew Morton, Mike Rapoport
Cc: linuxppc-dev, linux-kernel, linux-s390, linux-acpi, nvdimm,
linux-mm, linux-cxl, linux-hyperv, virtualization, xen-devel,
Pratyush Brahma
From: Pratyush Brahma <pratyush.brahma@oss.qualcomm.com>
The function `memory_add_physaddr_to_nid` seems a misnomer.
It does not to "add" a physical address to a NID mapping,
but rather it gets the NID associated with a given physical address.
Improve the semantic clarity of the API by renaming to a more
descriptive name.
Signed-off-by: Pratyush Brahma <pratyush.brahma@oss.qualcomm.com>
---
arch/powerpc/include/asm/sparsemem.h | 4 ++--
arch/powerpc/mm/mem.c | 4 ++--
arch/s390/include/asm/sparsemem.h | 4 ++--
drivers/acpi/acpi_memhotplug.c | 2 +-
drivers/acpi/nfit/core.c | 2 +-
drivers/base/memory.c | 2 +-
drivers/cxl/pmem.c | 2 +-
drivers/dax/cxl.c | 2 +-
drivers/hv/hv_balloon.c | 6 +++---
drivers/nvdimm/virtio_pmem.c | 2 +-
drivers/virtio/virtio_mem.c | 2 +-
drivers/xen/balloon.c | 2 +-
include/linux/numa.h | 6 +++---
include/linux/numa_memblks.h | 4 ++--
mm/numa.c | 6 +++---
mm/numa_memblks.c | 4 ++--
16 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/include/asm/sparsemem.h b/arch/powerpc/include/asm/sparsemem.h
index d072866842e4229159fcb6635745fd19a2788413..cdb5594616c8e32ab8ae3d209d0b2df20f3564f6 100644
--- a/arch/powerpc/include/asm/sparsemem.h
+++ b/arch/powerpc/include/asm/sparsemem.h
@@ -14,8 +14,8 @@
#ifdef CONFIG_MEMORY_HOTPLUG
extern int remove_section_mapping(unsigned long start, unsigned long end);
-extern int memory_add_physaddr_to_nid(u64 start);
-#define memory_add_physaddr_to_nid memory_add_physaddr_to_nid
+extern int memory_get_phys_to_nid(u64 start);
+#define memory_get_phys_to_nid memory_get_phys_to_nid
#ifdef CONFIG_NUMA
extern int hot_add_scn_to_nid(unsigned long scn_addr);
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 3ddbfdbfa9413a17d8321885724ce432d967005a..5665b2e2fc68df8634613c11706e1a9158a3a616 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -54,11 +54,11 @@ EXPORT_SYMBOL(__phys_mem_access_prot);
static DEFINE_MUTEX(linear_mapping_mutex);
#ifdef CONFIG_NUMA
-int memory_add_physaddr_to_nid(u64 start)
+int memory_get_phys_to_nid(u64 start)
{
return hot_add_scn_to_nid(start);
}
-EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);
+EXPORT_SYMBOL_GPL(memory_get_phys_to_nid);
#endif
int __weak create_section_mapping(unsigned long start, unsigned long end,
diff --git a/arch/s390/include/asm/sparsemem.h b/arch/s390/include/asm/sparsemem.h
index 668dfc5de538742269af1b25151372506105fd4d..744c67dce4c106d063cb5436b37412045da0fd2a 100644
--- a/arch/s390/include/asm/sparsemem.h
+++ b/arch/s390/include/asm/sparsemem.h
@@ -7,11 +7,11 @@
#ifdef CONFIG_NUMA
-static inline int memory_add_physaddr_to_nid(u64 addr)
+static inline int memory_get_phys_to_nid(u64 addr)
{
return 0;
}
-#define memory_add_physaddr_to_nid memory_add_physaddr_to_nid
+#define memory_get_phys_to_nid memory_get_phys_to_nid
static inline int phys_to_target_node(u64 start)
{
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index d0c1a71007d0a3054608bec8fddc8e86bdffb78b..6f968243ffc3cc5864e73b914d1bf67748e30e66 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -183,7 +183,7 @@ static int acpi_memory_enable_device(struct acpi_memory_device *mem_device)
continue;
/* We want a single node for the whole memory group */
if (node < 0)
- node = memory_add_physaddr_to_nid(info->start_addr);
+ node = memory_get_phys_to_nid(info->start_addr);
total_length += info->length;
}
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index ae035b93da087812dee6ec47d9ef4aa97dc8e7bc..04c3ab311e4d5923aef50252efabd193c5fb7850 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -2630,7 +2630,7 @@ static int acpi_nfit_register_region(struct acpi_nfit_desc *acpi_desc,
/* Fallback to address based numa information if node lookup failed */
if (ndr_desc->numa_node == NUMA_NO_NODE) {
- ndr_desc->numa_node = memory_add_physaddr_to_nid(spa->address);
+ ndr_desc->numa_node = memory_get_phys_to_nid(spa->address);
dev_info(acpi_desc->dev, "changing numa node from %d to %d for nfit region [%pa-%pa]",
NUMA_NO_NODE, ndr_desc->numa_node, &res.start, &res.end);
}
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 5c6c1d6bb59f1241a5f42a3396be1a8e2058c965..f657520855408804761afec379e3c0b2a238b239 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -599,7 +599,7 @@ static ssize_t probe_store(struct device *dev, struct device_attribute *attr,
if (ret)
return ret;
- nid = memory_add_physaddr_to_nid(phys_addr);
+ nid = memory_get_phys_to_nid(phys_addr);
ret = __add_memory(nid, phys_addr,
MIN_MEMORY_BLOCK_SIZE * sections_per_block,
MHP_NONE);
diff --git a/drivers/cxl/pmem.c b/drivers/cxl/pmem.c
index e197883690efc11f60c31bd56aeb5695665d422b..471aed4e11241948e994d0b9d53600c147e38fb0 100644
--- a/drivers/cxl/pmem.c
+++ b/drivers/cxl/pmem.c
@@ -410,7 +410,7 @@ static int cxl_pmem_region_probe(struct device *dev)
ndr_desc.res = res;
ndr_desc.provider_data = cxlr_pmem;
- ndr_desc.numa_node = memory_add_physaddr_to_nid(res->start);
+ ndr_desc.numa_node = memory_get_phys_to_nid(res->start);
ndr_desc.target_node = phys_to_target_node(res->start);
if (ndr_desc.target_node == NUMA_NO_NODE) {
ndr_desc.target_node = ndr_desc.numa_node;
diff --git a/drivers/dax/cxl.c b/drivers/dax/cxl.c
index 13cd94d32ff7a1d70af7821c1aecd7490302149d..35843791872ba466f571c022e1484816368a1198 100644
--- a/drivers/dax/cxl.c
+++ b/drivers/dax/cxl.c
@@ -15,7 +15,7 @@ static int cxl_dax_region_probe(struct device *dev)
struct dev_dax_data data;
if (nid == NUMA_NO_NODE)
- nid = memory_add_physaddr_to_nid(cxlr_dax->hpa_range.start);
+ nid = memory_get_phys_to_nid(cxlr_dax->hpa_range.start);
dax_region = alloc_dax_region(dev, cxlr->id, &cxlr_dax->hpa_range, nid,
PMD_SIZE, IORESOURCE_DAX_KMEM);
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 2b4080e51f97c30e7adb06faa56b1403bc08b53c..8878aac6da9cd3bd6f499eae2588e989b7219af3 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -725,7 +725,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned long size,
reinit_completion(&dm_device.ol_waitevent);
- nid = memory_add_physaddr_to_nid(PFN_PHYS(start_pfn));
+ nid = memory_get_phys_to_nid(PFN_PHYS(start_pfn));
ret = add_memory(nid, PFN_PHYS((start_pfn)),
HA_BYTES_IN_CHUNK, MHP_MERGE_RESOURCE);
@@ -1701,8 +1701,8 @@ static int hot_add_enabled(void)
{
/*
* Disable hot add on ARM64, because we currently rely on
- * memory_add_physaddr_to_nid() to get a node id of a hot add range,
- * however ARM64's memory_add_physaddr_to_nid() always return 0 and
+ * memory_get_phys_to_nid() to get a node id of a hot add range,
+ * however ARM64's memory_get_phys_to_nid() always return 0 and
* DM_MEM_HOT_ADD_REQUEST doesn't have the NUMA node information for
* add_memory().
*/
diff --git a/drivers/nvdimm/virtio_pmem.c b/drivers/nvdimm/virtio_pmem.c
index 2396d19ce5496974f8b93b54cc8c95e48dda103d..df6a3fd552d11a577d85708f80e7558ea83839d2 100644
--- a/drivers/nvdimm/virtio_pmem.c
+++ b/drivers/nvdimm/virtio_pmem.c
@@ -100,7 +100,7 @@ static int virtio_pmem_probe(struct virtio_device *vdev)
ndr_desc.res = &res;
- ndr_desc.numa_node = memory_add_physaddr_to_nid(res.start);
+ ndr_desc.numa_node = memory_get_phys_to_nid(res.start);
ndr_desc.target_node = phys_to_target_node(res.start);
if (ndr_desc.target_node == NUMA_NO_NODE) {
ndr_desc.target_node = ndr_desc.numa_node;
diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index 1688ecd69a0445d5c21d108a9a1d60577f96d7ac..6154f03a12c3efa65728f626e43b6270245d439c 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -2858,7 +2858,7 @@ static int virtio_mem_init(struct virtio_mem *vm)
/* Determine the nid for the device based on the lowest address. */
if (vm->nid == NUMA_NO_NODE)
- vm->nid = memory_add_physaddr_to_nid(vm->addr);
+ vm->nid = memory_get_phys_to_nid(vm->addr);
dev_info(&vm->vdev->dev, "start address: 0x%llx", vm->addr);
dev_info(&vm->vdev->dev, "region size: 0x%llx", vm->region_size);
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 2de37dcd75566fc1a03b75232cbe17fc0f53909d..93ca270ddd516ec11bc3f096eb518b9789d92664 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -284,7 +284,7 @@ static enum bp_state reserve_additional_memory(void)
if (!resource)
goto err;
- nid = memory_add_physaddr_to_nid(resource->start);
+ nid = memory_get_phys_to_nid(resource->start);
#ifdef CONFIG_XEN_HAVE_PVMMU
/*
diff --git a/include/linux/numa.h b/include/linux/numa.h
index e6baaf6051bcff6c23308d3b67f790053fbd29dc..ed65a20f39718a5a3157f6f9db60561f4418b000 100644
--- a/include/linux/numa.h
+++ b/include/linux/numa.h
@@ -33,8 +33,8 @@ int numa_nearest_node(int node, unsigned int state);
int nearest_node_nodemask(int node, nodemask_t *mask);
-#ifndef memory_add_physaddr_to_nid
-int memory_add_physaddr_to_nid(u64 start);
+#ifndef memory_get_phys_to_nid
+int memory_get_phys_to_nid(u64 start);
#endif
#ifndef phys_to_target_node
@@ -54,7 +54,7 @@ static inline int nearest_node_nodemask(int node, nodemask_t *mask)
return NUMA_NO_NODE;
}
-static inline int memory_add_physaddr_to_nid(u64 start)
+static inline int memory_get_phys_to_nid(u64 start)
{
return 0;
}
diff --git a/include/linux/numa_memblks.h b/include/linux/numa_memblks.h
index 991076cba7c5016d845eb40a2f9887f73fa83862..37cc0987e738f8aa2eb5c8f1ca2c94394def4780 100644
--- a/include/linux/numa_memblks.h
+++ b/include/linux/numa_memblks.h
@@ -53,8 +53,8 @@ static inline int numa_emu_cmdline(char *str)
#ifdef CONFIG_NUMA_KEEP_MEMINFO
extern int phys_to_target_node(u64 start);
#define phys_to_target_node phys_to_target_node
-extern int memory_add_physaddr_to_nid(u64 start);
-#define memory_add_physaddr_to_nid memory_add_physaddr_to_nid
+extern int memory_get_phys_to_nid(u64 start);
+#define memory_get_phys_to_nid memory_get_phys_to_nid
#endif /* CONFIG_NUMA_KEEP_MEMINFO */
#endif /* CONFIG_NUMA_MEMBLKS */
diff --git a/mm/numa.c b/mm/numa.c
index 7d5e06fe5bd4a2790b83dd7dbe646617f6476d8c..f7b5ac8aea608368b75c606970187eb147ddf427 100644
--- a/mm/numa.c
+++ b/mm/numa.c
@@ -40,14 +40,14 @@ void __init alloc_offline_node_data(int nid)
/* Stub functions: */
-#ifndef memory_add_physaddr_to_nid
-int memory_add_physaddr_to_nid(u64 start)
+#ifndef memory_get_phys_to_nid
+int memory_get_phys_to_nid(u64 start)
{
pr_info_once("Unknown online node for memory at 0x%llx, assuming node 0\n",
start);
return 0;
}
-EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);
+EXPORT_SYMBOL_GPL(memory_get_phys_to_nid);
#endif
#ifndef phys_to_target_node
diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c
index 541a99c4071a67e5b0ef66f4136dee268a880003..346039bd933390fb014931fc61ccd2f96a773c37 100644
--- a/mm/numa_memblks.c
+++ b/mm/numa_memblks.c
@@ -580,7 +580,7 @@ int phys_to_target_node(u64 start)
}
EXPORT_SYMBOL_GPL(phys_to_target_node);
-int memory_add_physaddr_to_nid(u64 start)
+int memory_get_phys_to_nid(u64 start)
{
int nid = meminfo_to_nid(&numa_meminfo, start);
@@ -588,6 +588,6 @@ int memory_add_physaddr_to_nid(u64 start)
nid = numa_meminfo.blk[0].nid;
return nid;
}
-EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);
+EXPORT_SYMBOL_GPL(memory_get_phys_to_nid);
#endif /* CONFIG_NUMA_KEEP_MEMINFO */
---
base-commit: 479058002c32b77acac43e883b92174e22c4be2d
change-id: 20250814-numa_memblks-b54a878820de
Best regards,
--
Pratyush Brahma <pratyush.brahma@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH] x86/hyperv: Fix kdump on Azure CVMs
From: kernel test robot @ 2025-08-16 7:22 UTC (permalink / raw)
To: Vitaly Kuznetsov, linux-hyperv
Cc: oe-kbuild-all, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, x86, linux-kernel, Nuno Das Neves, Tianyu Lan,
Michael Kelley, Li Tian, Philipp Rudo
In-Reply-To: <20250815133725.1591863-1-vkuznets@redhat.com>
Hi Vitaly,
kernel test robot noticed the following build errors:
[auto build test ERROR on tip/x86/core]
[also build test ERROR on linus/master v6.17-rc1]
[cannot apply to next-20250815]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Vitaly-Kuznetsov/x86-hyperv-Fix-kdump-on-Azure-CVMs/20250815-214053
base: tip/x86/core
patch link: https://lore.kernel.org/r/20250815133725.1591863-1-vkuznets%40redhat.com
patch subject: [PATCH] x86/hyperv: Fix kdump on Azure CVMs
config: arm64-randconfig-003-20250816 (https://download.01.org/0day-ci/archive/20250816/202508161430.0GC3nT8J-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 8.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250816/202508161430.0GC3nT8J-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/202508161430.0GC3nT8J-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/hv/vmbus_drv.c: In function 'hv_kexec_handler':
>> drivers/hv/vmbus_drv.c:2786:2: error: implicit declaration of function 'hv_ivm_clear_host_access' [-Werror=implicit-function-declaration]
hv_ivm_clear_host_access();
^~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/hv_ivm_clear_host_access +2786 drivers/hv/vmbus_drv.c
2778
2779 static void hv_kexec_handler(void)
2780 {
2781 hv_stimer_global_cleanup();
2782 vmbus_initiate_unload(false);
2783 /* Make sure conn_state is set as hv_synic_cleanup checks for it */
2784 mb();
2785 cpuhp_remove_state(hyperv_cpuhp_online);
> 2786 hv_ivm_clear_host_access();
2787 };
2788
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* RE: [PATCH] hyperv: Add missing field to hv_output_map_device_interrupt
From: Michael Kelley @ 2025-08-15 20:46 UTC (permalink / raw)
To: Nuno Das Neves, Wei Liu
Cc: linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
kys@microsoft.com, haiyangz@microsoft.com, decui@microsoft.com
In-Reply-To: <4ebde68b-1e39-4650-9f57-500843fa8aea@linux.microsoft.com>
From: Nuno Das Neves <nunodasneves@linux.microsoft.com> Sent: Friday, August 15, 2025 10:11 AM
>
> On 8/14/2025 2:16 PM, Wei Liu wrote:
> > On Thu, Aug 14, 2025 at 06:57:22PM +0000, Michael Kelley wrote:
> >> From: Nuno Das Neves <nunodasneves@linux.microsoft.com> Sent: Wednesday, August 13, 2025 11:21 AM
> >>>
> >>> This field is unused, but the correct structure size is needed
> >>> when computing the amount of space for the output argument to
> >>> reside, so that it does not cross a page boundary.
> >>>
> >>> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
> >>> ---
> >>> include/hyperv/hvhdk_mini.h | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/include/hyperv/hvhdk_mini.h b/include/hyperv/hvhdk_mini.h
> >>> index 42e7876455b5..858f6a3925b3 100644
> >>> --- a/include/hyperv/hvhdk_mini.h
> >>> +++ b/include/hyperv/hvhdk_mini.h
> >>> @@ -301,6 +301,7 @@ struct hv_input_map_device_interrupt {
> >>> /* HV_OUTPUT_MAP_DEVICE_INTERRUPT */
> >>> struct hv_output_map_device_interrupt {
> >>> struct hv_interrupt_entry interrupt_entry;
> >>> + u64 ext_status_deprecated[5];
> >>
> >> Your email identifying the problem said that without this
> >> change, struct hv_output_map_device_interrupt is 0x10
> >> bytes in size, which matches what I calculate from the definition.
> >> This change adds 0x28 bytes, making the struct size now 0x38
> >> bytes. But your other email said Hyper-V expects the size to be
> >> 0x58 bytes. Is array size "5" correct, or is there some other
> >> cause of the discrepancy?
> >>
>
> Ah, it looks like the *input* struct size (0x50) plus the size of
> 1 cpu bank is 0x58. The output struct size should indeed be 0x38.
>
> I got them mixed up somehow when writing the email.
> >
> > FWIW the array size 5 here is correct.
> >
OK -- thanks. Just wanted to be sure everything was right.
FWIW,
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
^ permalink raw reply
* Re: [PATCH] hyperv: Add missing field to hv_output_map_device_interrupt
From: Nuno Das Neves @ 2025-08-15 17:11 UTC (permalink / raw)
To: Wei Liu, Michael Kelley
Cc: linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
kys@microsoft.com, haiyangz@microsoft.com, decui@microsoft.com
In-Reply-To: <aJ5SOFR8HNqPxBKN@liuwe-devbox-ubuntu-v2.tail21d00.ts.net>
On 8/14/2025 2:16 PM, Wei Liu wrote:
> On Thu, Aug 14, 2025 at 06:57:22PM +0000, Michael Kelley wrote:
>> From: Nuno Das Neves <nunodasneves@linux.microsoft.com> Sent: Wednesday, August 13, 2025 11:21 AM
>>>
>>> This field is unused, but the correct structure size is needed
>>> when computing the amount of space for the output argument to
>>> reside, so that it does not cross a page boundary.
>>>
>>> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
>>> ---
>>> include/hyperv/hvhdk_mini.h | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/include/hyperv/hvhdk_mini.h b/include/hyperv/hvhdk_mini.h
>>> index 42e7876455b5..858f6a3925b3 100644
>>> --- a/include/hyperv/hvhdk_mini.h
>>> +++ b/include/hyperv/hvhdk_mini.h
>>> @@ -301,6 +301,7 @@ struct hv_input_map_device_interrupt {
>>> /* HV_OUTPUT_MAP_DEVICE_INTERRUPT */
>>> struct hv_output_map_device_interrupt {
>>> struct hv_interrupt_entry interrupt_entry;
>>> + u64 ext_status_deprecated[5];
>>
>> Your email identifying the problem said that without this
>> change, struct hv_output_map_device_interrupt is 0x10
>> bytes in size, which matches what I calculate from the definition.
>> This change adds 0x28 bytes, making the struct size now 0x38
>> bytes. But your other email said Hyper-V expects the size to be
>> 0x58 bytes. Is array size "5" correct, or is there some other
>> cause of the discrepancy?
>>
Ah, it looks like the *input* struct size (0x50) plus the size of
1 cpu bank is 0x58. The output struct size should indeed be 0x38.
I got them mixed up somehow when writing the email.
>
> FWIW the array size 5 here is correct.
>
> Wei
>
>> Michael
>>
>>> } __packed;
>>>
>>> /* HV_INPUT_UNMAP_DEVICE_INTERRUPT */
>>> --
>>> 2.34.1
>>
>>
^ 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