[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.