Re: [PATCH v4 4/5] vpci: add SR-IOV support for PVH Dom0

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.10.2026 23:47, Jason Andryuk wrote:
> On 2026-10-15 10:08, Mykyta Poturai wrote:
>> --- a/xen/drivers/vpci/vpci.c
>> +++ b/xen/drivers/vpci/vpci.c
> 
>> @@ -486,6 +487,11 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, 
>> unsigned int size)
>>           return data;
>>       }
>>   
>> +    /* Ahead of any lock being taken, as adding a device acquires them. */
>> +    if ( unlikely(is_hardware_domain(d) && pci_vf_setup_pending(sbdf)) &&
> 
> unlikely() here breaks the tests build.  Add
>      #define unlikely
> to tools/tests/vpci/emul.h

Or better omit unlikely() here. It's not used properly anyway: Unless it's known
that the compiler will translate an && expression to a single branch, each part
of && (or || ) wants wrapping, not the entire expression.

>> --- a/xen/include/xen/vpci.h
>> +++ b/xen/include/xen/vpci.h
> 
>> @@ -145,6 +145,22 @@ struct vpci {
>>           unsigned int nbars:3;
>>       } rebar;
>>   
>> +    struct vpci_sriov {
>> +        /* PF only */
>> +        struct vpci_bar vf_bars[PCI_SRIOV_NUM_BARS];
>> +        /*
>> +         * When the VFs which are enabled but not added to Xen yet are
>> +         * guaranteed to respond to config space accesses.  Zero if there 
>> are
>> +         * none.
>> +         */
>> +        s_time_t vfs_ready;
>> +        /* Routing ID offset of the first VF, and stride between VFs. */
>> +        uint16_t offset;
>> +        uint16_t stride;
>> +        uint16_t num_vfs;
>> +        unsigned int pos;
> 
> unsigned int before uint16_t packs the structure a little better.

As per ./CODING_STYLE, the use of uint16_t may not be justified here anyway.

Jan