Re: [PATCH v3 03/11] vpci/header: Move register assignments from init_bars

[Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>]

Hi, Roger!

On 27.10.21 13:17, Oleksandr Andrushchenko wrote:
> Hi, Roger!
>
> On 13.10.21 16:51, Roger Pau Monné wrote:
>> On Thu, Sep 30, 2021 at 10:52:15AM +0300, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
>>>
>>> This is in preparation for dynamic assignment of the vPCI register
>>> handlers depending on the domain: hwdom or guest.
>>> The need for this step is that it is easier to have all related 
>>> functionality
>>> put at one place. When the subsequent patches add decisions on which
>>> handlers to install, e.g. hwdom or guest handlers, then this is easily
>>> achievable.
>> Won't it be possible to select the handlers to install in init_bars
>> itself?
> It is possible
>> Splitting it like that means you need to iterate over the numbers of
>> BARs twice (one in add_bar_handlers and one in init_bars), which makes
>> it more likely to introduce errors or divergences.
>>
>> Decoupling the filling of vpci_bar data with setting the handlers
>> seems slightly confusing.
> Ok, I won't introduce add_bar_handlers, thus rendering this patch useless.
> I'll drop it and re-work the upcoming patches with this respect
On the other hand after thinking a bit more.
What actually init_bars do?
1. Runs once per each pdev (__init?)
2. Sizes the BARs and detects their type, sets up pdev->vpci->header BAR values
3. Adds register handlers.

For DomU we only need 3), so we can setup guest handlers.
So, from this POV either we need to have a yet another add_bar_handlers
or similar for at least the guests and the case when pdev is assigned back to 
hwdom.

So this can be a reason to defend the current approach with add_bar_handlers.

Or? Do you have an idea how to do that some other way?
>
> Thank you,
> Oleksandr