Re: [PATCH v1 5/8] xen/pci: introduce has_vpci_bridge

[Mykyta Poturai <Mykyta_Poturai@xxxxxxxx>]

On 06.11.25 14:15, Jan Beulich wrote:> On 24.09.2025 09:59, Mykyta 
Poturai wrote:
 >> From: Stefano Stabellini <stefano.stabellini@xxxxxxx>
 >>
 >> has_vpci_bridge is a macro to check if the domain is a domU or is dom0
 >> with vPCI (pci-scan=yes) enabled.
 >
 > Hmm. Why would DomU-s, now and forever, not have (virtual) bridges? 
Wasn't them
 > gaining (virtual) bridges actually the longer-term plan?
 >

Seems like there is a misunderstanding here. Indeed it is the plan for 
DomUs to have virtual bridges and this check is designed to 
differentiate two categories of domains.
1. All DomUs + Dom0 with the virtual bridge.
2. Dom0 with HW bridge.

I will try to rephrase the commit message to be more clear.

 >> @@ -866,7 +866,7 @@ int vpci_init_header(struct pci_dev *pdev)
 >>       struct vpci_header *header = &pdev->vpci->header;
 >>       struct vpci_bar *bars = header->bars;
 >>       int rc;
 >> -    bool is_hwdom = is_hardware_domain(pdev->domain);
 >> +    bool is_hwdom = !has_vpci_bridge(pdev->domain);
 >>
 >>       ASSERT(rw_is_write_locked(&pdev->domain->pci_lock));
 >
 > For none of the changes (also further ones) it is clear (to me) why the
 > substitution is (logically) correct. For this last instance the variable
 > name also ends up wrong after the replacement.
 >> Jan

The general logic for this change is that before it we assumed that 
hwdom always uses HW bridge. Now it is not always true and hwdom can 
also use a virtual bridge, so it needs to be treated the same way as 
DomUs are.

You also mentioned on a previous series

 > Here and perhaps everywhere else I wonder: Is this really an 
appropriately
 > named predicate for the purpose / context?

Maybe you have some ideas of a better name? From what I came up with 
this seems like the best one.

-- 
Mykyta