[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.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?
>
> Jan
>
Thank you,
Oleksandr

 


Rackspace

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