KVM: arm64: vgic-v5: Random sparse fixes

Both vmd_base and vpet_base are pointers to kmalloc'd memory, and therefore cannot carry the __iomem attribute, which designates pointers to MMIO.

Drop the abusive qualifier.

Reported-by kernel test robot <[email protected]>

Closes https://lore.kernel.org/oe-kbuild-all/[email protected]/ open here

Signed-off-by Marc Zyngier <[email protected]>

---
 arch/arm64/kvm/vgic/vgic-v5-tables.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/arm64/kvm/vgic/vgic-v5-tables.h +2 -3

index b2ffbe68c05b4..89096926563f7 100644
@@ -23,8 +23,8 @@ struct vmtl2_entry {
 typedef __le64 vpe_entry;
 
 struct vgic_v5_vm_info {
-       void __iomem            *vmd_base;
-       vpe_entry __iomem       *vpet_base;
+       void                    *vmd_base;
+       vpe_entry               *vpet_base;
        void                    *vped_base;
        u8                      vpe_id_bits;
 
--

2.47.3

Resetting a pointer to 0 is not completely wrong, but sparse legitimately shouts about it integer/pointer mix.

Use NULL as expected.

Reported-by kernel test robot <[email protected]>

Closes https://lore.kernel.org/oe-kbuild-all/[email protected]/ open here

Signed-off-by Marc Zyngier <[email protected]>

---
 arch/arm64/kvm/vgic/vgic-v5-tables.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm64/kvm/vgic/vgic-v5-tables.c +1 -2

index ba8a8d5fcc2a3..d7196ed5d1bfd 100644
@@ -1066,7 +1066,7 @@ static int vgic_v5_alloc_two_level_lpi_ist(struct kvm *kvm, unsigned int id_bits
                /* Free the L1 IST again */
                vmi = xa_load(&vm_info, vm_id);
                kfree(vmi->h_lpi_ist);
-               vmi->h_lpi_ist = 0;
+               vmi->h_lpi_ist = NULL;
 
                return ret;
        }
--

2.47.3

Assigning an address calculation to a vpe_entry is poor practice, and results in sparse moaning loudly. Tidy things up by computing the physical address as such, and performing the cpu_to_le64() on that.

Whilst at it, simplify the computing of that address, avoiding the shifting back and forth, and kill the pointless GICV5_VPED_ADDR_SHIFT definition.

Signed-off-by Marc Zyngier <[email protected]>

---
 arch/arm64/kvm/vgic/vgic-v5-tables.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

arch/arm64/kvm/vgic/vgic-v5-tables.c +3 -6

index d7196ed5d1bfd..2c8d0f360506c 100644
@@ -63,7 +63,6 @@ static DEFINE_XARRAY(vm_info);
 /* Virtual PE Table Entry */
 #define GICV5_VPE_VALID                        BIT_ULL(0)
 /* Note that there is no shift for the address by design. */
-#define GICV5_VPED_ADDR_SHIFT          3ULL
 #define GICV5_VPED_ADDR                        GENMASK_ULL(55, 3)
 
 /* L2 Interrupt State Table Entry */

@@ -725,7 +724,7 @@ int vgic_v5_vmte_alloc_vpe(struct kvm_vcpu *vcpu)
        u32 vm_id = vgic_v5_vm_id(vcpu->kvm);
        u16 vpe_id = vgic_v5_vpe_id(vcpu);
        struct vgic_v5_vm_info *vmi;
-       vpe_entry tmp, *vpet_base;
+       vpe_entry *vpet_base;
        void *vped;
 
        /* Make sure we're not over what the hardware supports */

@@ -751,10 +750,9 @@ int vgic_v5_vmte_alloc_vpe(struct kvm_vcpu *vcpu)
        vped = (u8 *)vmi->vped_base +
                (size_t)vcpu->vcpu_idx * vmt_info->vped_size;
 
-       tmp = FIELD_PREP(GICV5_VPED_ADDR, virt_to_phys(vped) >> GICV5_VPED_ADDR_SHIFT);
-
        scoped_guard(raw_spinlock_irqsave, &vgic_v5_irs_lock) {
-               WRITE_ONCE(vpet_base[vpe_id], cpu_to_le64(tmp));
+               phys_addr_t paddr = virt_to_phys(vped) & GICV5_VPED_ADDR;
+               WRITE_ONCE(vpet_base[vpe_id], cpu_to_le64(paddr));
                vgic_v5_clean_inval(vpet_base + vpe_id, sizeof(vpe_entry));
        }
 
--

2.47.3

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] kvm: arm64: code and commit message mismatch regarding h_iste type --

commit a916f514228ceaaf50a5546f6df29cea59ab15f1
Author: Marc Zyngier <[email protected]>

KVM: arm64: vgic-v5: Correctly handle host ISTE __le32 conversion

This commit addresses a sparse warning by modifying the endianness conversion of the host ISTE. The intent is to define h_iste as a u32 instead of __le32, doing the conversion at the point of access.

Closes https://lore.kernel.org/oe-kbuild-all/[email protected]/ open here

Quoted 4 lines

arch/arm64/kvm/vgic/vgic-v5-tables.c +0 -0

index 2c8d0f360506c..aae5cf05f3907 100644

[ ... ]

arch/arm64/kvm/vgic/vgic-v5-tables.c static int vgic_v5_save_two_level_ist(const struct vgic_v5_ist_desc *ist, · line 1525

Quoted 8 lines

arch/arm64/kvm/vgic/vgic-v5-tables.c +1 -1

@@ -1520,7 +1520,7 @@ static int vgic_v5_save_two_level_ist(const struct vgic_v5_ist_desc *ist,
 			h_iste = *(__le32 *)(h_l2_ist_base +
 					     h_l2_index * ist->iste_size);
 
-			ret = put_user(h_iste, uaddr);
+			ret = put_user(le32_to_cpu(h_iste), uaddr);
 			if (ret)
 				return ret;

[Severity: Medium]
Is the refactoring in vgic_v5_save_two_level_ist() incomplete?

The commit message explicitly states "define h_iste as a u32", and this pattern was applied to the other three functions modified in the file. However, in vgic_v5_save_two_level_ist(), the h_iste variable retains its __le32 type at the top of the function, and the conversion is instead done inline within the put_user() call.

Does this variable also need to be redefined as a u32 to remain consistent with the commit description and the rest of the patch?

arch/arm64/kvm/vgic/vgic-v5-tables.c +0 -0

I'm queuing this on top of the existing branch.