On Mon, Nov 22, 2021 at 11:28:25AM +0200, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko <[email protected]> > > Use a named range set instead of an anonymous one, but do not print it > while dumping range sets for a domain. > > Suggested-by: Jan Beulich <[email protected]> > Signed-off-by: Oleksandr Andrushchenko <[email protected]> > --- > xen/drivers/vpci/header.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c > index 40ff79c33f8f..82a3e50d6053 100644 > --- a/xen/drivers/vpci/header.c > +++ b/xen/drivers/vpci/header.c > @@ -206,12 +206,16 @@ static void defer_map(struct domain *d, struct pci_dev > *pdev, > static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool > rom_only) > { > struct vpci_header *header = &pdev->vpci->header; > - struct rangeset *mem = rangeset_new(NULL, NULL, 0); > + struct rangeset *mem; > + char str[32]; > struct pci_dev *tmp, *dev = NULL; > const struct vpci_msix *msix = pdev->vpci->msix; > unsigned int i; > int rc; > > + snprintf(str, sizeof(str), "%pp", &pdev->sbdf); > + mem = rangeset_new(NULL, str, RANGESETF_no_print);
You are still not adding the rangeset to the domain list, as the first parameter passed here in NULL instead of a domain struct. Given the current short living of the rangesets I'm not sure it makes much sense to link them to the domain ATM, but I guess this is kind of a preparatory change as other patches you have will have the rangesets permanent as long as the device is assigned to a domain. Likely the above reasoning (or the appropriate one) should be added to the commit message. Thanks, Roger.
