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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.11.2025 10:49, Mykyta Poturai wrote:
> 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.

How to name it depends on the (ultimate) purpose. If, as you say, it's intended
to cover Dom0 and DomU uniformly when they have a virtual bridge, the name might
be quite okay. Then, as you said you would do, better wording may be needed,
variable names like the one mentioned above may need adjustment, and any code
paths suddenly becoming usable for DomU-s need to be audited for this being a
safe/secure thing to do (quite a few of the Dom0-only paths have been taking
some liberties so far).

Jan