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 <[email protected]> >>> >>> 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
