Re: [PATCH v4 06/11] vpci/header: handle p2m range sets per BAR

[Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>]

On 22.11.21 10:24, Jan Beulich wrote:
> 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.
Then I see two patches here: one which introduces a generic RANGESETF_no_print
flag and the second one converting anonymous range set used by vPCI
>
> Jan
>
Thank you,
Oleksandr