On 19.11.2021 15:09, Oleksandr Andrushchenko wrote: > On 19.11.21 15:57, Jan Beulich wrote: >> On 19.11.2021 14:41, Oleksandr Andrushchenko wrote: >>> On 19.11.21 15:16, Jan Beulich wrote: >>>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote: >>>>> @@ -95,10 +102,25 @@ int vpci_add_handlers(struct pci_dev *pdev) >>>>> INIT_LIST_HEAD(&pdev->vpci->handlers); >>>>> spin_lock_init(&pdev->vpci->lock); >>>>> >>>>> + header = &pdev->vpci->header; >>>>> + for ( i = 0; i < ARRAY_SIZE(header->bars); i++ ) >>>>> + { >>>>> + struct vpci_bar *bar = &header->bars[i]; >>>>> + >>>>> + bar->mem = rangeset_new(NULL, NULL, 0); >>>> I don't recall why an anonymous range set was chosen back at the time >>>> when vPCI was first implemented, but I think this needs to be changed >>>> now that DomU-s get supported. Whether you do so right here or in a >>>> prereq patch is secondary to me. It may be desirable to exclude them >>>> from rangeset_domain_printk() (which would likely require a new >>>> RANGESETF_* flag), but I think such resources should be associated >>>> with their domains. >>> What would be the proper name for such a range set then? >>> "vpci_bar"? >> E.g. bb:dd.f:BARn > Hm, indeed > I can only see a single flag RANGESETF_prettyprint_hex which tells > *how* to print, but I can't see any limitation in *what* to print. > So, do you mean I want some logic to be implemented in > rangeset_domain_printk so it knows that this entry needs to be skipped > while printing? RANGESETF_skip_print?
Yes, albeit I'd call the flag e.g. RANGESETF_no_print. Jan