Re: [PATCH 09/17] xev/hvm: Add HVMOP_get|set_ecam_space hypercalls

[Thierry Escande <thierry.escande@xxxxxxxxxx>]

On 4/28/26 16:00, Roger Pau Monné wrote:
> On Fri, Mar 13, 2026 at 04:35:03PM +0000, Thierry Escande wrote:
>> This patch adds 2 HVMOP hypercalls, HVMOP_get|set_ecam_space, used to
>> set and get the base address and size of the PCIe ECAM space as
>> configured by hvmloader.
>>
>> Signed-off-by: Thierry Escande <thierry.escande@xxxxxxxxxx>
>> ---
>>  xen/arch/x86/hvm/hvm.c            | 52 +++++++++++++++++++++++++++++++
>>  xen/arch/x86/include/asm/domain.h |  4 +++
>>  xen/include/public/hvm/hvm_op.h   | 11 +++++++
>>  3 files changed, 67 insertions(+)
>>
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index 4d37a93c57..a46dfa955d 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -5195,6 +5195,58 @@ long do_hvm_op(unsigned long op, 
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>          rc = current->hcall_compat ? compat_altp2m_op(arg) : 
>> do_altp2m_op(arg);
>>          break;
>>  
>> +    case HVMOP_set_ecam_space: {
>> +        xen_hvm_ecam_space_t ecam;
>> +        struct domain *d;
>> +
>> +        if ( copy_from_guest( &ecam, guest_handle_cast(arg, 
>> xen_hvm_ecam_space_t), 1 ) )
>                                 ^ extra space, here and at the
>                                   closing parenthesis.
> 
> Line length is also past the 80 character limit, same below in
> HVMOP_get_ecam_space.

Ok.

> 
>> +            return -EFAULT;
> 
> This operation (and the matching get variant) needs an XSM check.

I'm not familiar with XSM. Does that imply to add a new flask hook ?
Extend an existing one ?

> 
>> +
>> +        d = rcu_lock_domain_by_any_id(ecam.domid);
>> +        if ( d == NULL )
>> +            return -ESRCH;
>> +
>> +        if ( d->arch.ecam_addr ) {
> 
> Coding style, opening braces should be on a new line.
> 
>> +            rcu_unlock_domain(d);
>> +            return -EFAULT;
> 
> This would better return -EBUSY
> 
>> +        }
> 
> You also need to check the padding fields are 0.
> 
>> +
>> +        if ( (ecam.size >> 28) || (!ecam.addr) ) {
>                                      ^ the parenthesis here are
>                                      unneeded.
> 
>> +            rcu_unlock_domain(d);
>> +            return -EINVAL;
>> +        }
>> +
>> +        d->arch.ecam_addr = ecam.addr;
>> +        d->arch.ecam_size = ecam.size;
> 
> I'm a bit worried about a domain being able to set it's own ECAM hole,
> assessing all the side-effects of this might be complex.

Would it be related to the XSM check you mentioned earlier to avoid the
guest to use the set hypercall?

> 
> Won't the code here better check the region passed in the hypercall is
> indeed not mapped in the p2m, so that trapping of ECAM accesses works
> as expected?

Well, it is mapped as p2m_mmio_dm. Do you mean adding a check to make
sure it's mapped correctly or not mapped?

> 
> Also, how does the ECAM hole get setup on native?  I assume there are
> some magic registers in the PCI config space of a platform device that
> the firmware uses to position the ECAM space?

ASAIU, the guest kernel gets the MMCONFIG area info via the ACPI MFCG
table and checks if the range is reserved in the 820 table. If ACPI is
disabled, it uses the PCI_MCH_PCIEXBAR register (0x60) of the bdf 000.

> 
> Are those trapped by QEMU, in which case won't it be better to do it
> the native way (iow: with the config space registers), and let QEMU
> forward it to Xen?  It would then be QEMU the one to call
> HVMOP_set_ecam_space (or whatever hypercall we end up using).

Yes, setting the PCI_MCH_PCIEXBAR register lands in Qemu. So it is
possible to do the hypercall from Qemu. I didn't do it that way to
(lazily) avoid big changes in Qemu. And that would also be better if the
guest modifies the PCI_MCH_PCIEXBAR register for whatever reason.

> 
>> +
>> +        rcu_unlock_domain(d);
>> +        break;
>> +    }
>> +
>> +    case HVMOP_get_ecam_space: {
>> +        xen_hvm_ecam_space_t ecam;
>> +        struct domain *d;
>> +
>> +        if ( copy_from_guest( &ecam, guest_handle_cast(arg, 
>> xen_hvm_ecam_space_t), 1 ) )
>> +            return -EFAULT;
>> +
>> +        d = rcu_lock_domain_by_any_id(ecam.domid);
>> +        if ( d == NULL )
>> +            return -ESRCH;
>> +
>> +        if ( ! d->arch.ecam_addr || ! d->arch.ecam_size ) {
>> +            rcu_unlock_domain(d);
>> +            return -EINVAL;
>> +        }
>> +
>> +        ecam.addr = d->arch.ecam_addr;
>> +        ecam.size = d->arch.ecam_size;
>> +        rc = __copy_to_guest(arg, &ecam, 1) ? -EFAULT : 0;
>> +
>> +        rcu_unlock_domain(d);
>> +        break;
>> +    }
>> +
>>      default:
>>          rc = -ENOSYS;
>>          break;
>> diff --git a/xen/arch/x86/include/asm/domain.h 
>> b/xen/arch/x86/include/asm/domain.h
>> index ad7f6adb2c..24ec33fc4d 100644
>> --- a/xen/arch/x86/include/asm/domain.h
>> +++ b/xen/arch/x86/include/asm/domain.h
>> @@ -476,6 +476,10 @@ struct arch_domain
>>  
>>      /* Emulated devices enabled bitmap. */
>>      uint32_t emulation_flags;
>> +
>> +    /* PCI ECAM space emulation */
>> +    uint64_t ecam_addr;
>> +    uint32_t ecam_size;
> 
> This fields would better be in hvm_domain struct, and there you
> already have the mmcfg_regions list, which we should aim to use for
> the q35 introduced ECAM region.

Ok.

> 
>>  } __cacheline_aligned;
>>  
>>  #ifdef CONFIG_HVM
>> diff --git a/xen/include/public/hvm/hvm_op.h 
>> b/xen/include/public/hvm/hvm_op.h
>> index e22adf0319..c84febc37c 100644
>> --- a/xen/include/public/hvm/hvm_op.h
>> +++ b/xen/include/public/hvm/hvm_op.h
>> @@ -166,6 +166,17 @@ struct xen_hvm_get_mem_type {
>>  typedef struct xen_hvm_get_mem_type xen_hvm_get_mem_type_t;
>>  DEFINE_XEN_GUEST_HANDLE(xen_hvm_get_mem_type_t);
>>  
>> +#define HVMOP_set_ecam_space    16
>> +#define HVMOP_get_ecam_space    17
>> +struct xen_hvm_ecam_space {
>> +    domid_t  domid;
>> +    uint16_t pad[3]; /* align next field on 8-byte boundary */
>> +    uint64_t addr;
>> +    uint32_t size;
> 
> There's also a trailing uint32_t padding here on 64bit builds I think?
> 
> FWIW, you could do:
> 
>     domid_t  domid;
>     uint16_t pad;
>     uint32_t size
>     uint64_t addr;
> 
> As that would reduce the padding in the struct?

Indeed, that seems better.

Regards,


--
Thierry Escande | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech