Re: [PATCH v5 06/14] vpci/header: implement guest BAR register handlers

[Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>]

Hi, Jan!

On 03.02.22 14:44, Jan Beulich wrote:
> On 03.02.2022 13:36, Oleksandr Andrushchenko wrote:
>> Hi, Bertrand!
>>
>> On 26.11.21 14:19, Oleksandr Andrushchenko wrote:
>>> Hi, Bertrand!
>>>
>>> On 25.11.21 18:28, Bertrand Marquis wrote:
>>>> Hi Oleksandr,
>>>>
>>>>> On 25 Nov 2021, at 11:02, Oleksandr Andrushchenko <andr2000@xxxxxxxxx> 
>>>>> wrote:
>>>>>
>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
>>>>>
>>>>> Add relevant vpci register handlers when assigning PCI device to a domain
>>>>> and remove those when de-assigning. This allows having different
>>>>> handlers for different domains, e.g. hwdom and other guests.
>>>>>
>>>>> Emulate guest BAR register values: this allows creating a guest view
>>>>> of the registers and emulates size and properties probe as it is done
>>>>> during PCI device enumeration by the guest.
>>>>>
>>>>> ROM BAR is only handled for the hardware domain and for guest domains
>>>>> there is a stub: at the moment PCI expansion ROM handling is supported
>>>>> for x86 only and it might not be used by other architectures without
>>>>> emulating x86. Other use-cases may include using that expansion ROM before
>>>>> Xen boots, hence no emulation is needed in Xen itself. Or when a guest
>>>>> wants to use the ROM code which seems to be rare.
>>>> In the generic code, bars for ioports are actually skipped (check code 
>>>> before
>>>> in header.c, in case of ioports there is a continue) and no handler is 
>>>> registered for them.
>>>> The consequence will be that a guest will access hardware when reading 
>>>> those BARs.
>>> Yes, this seems to be a valid point
>> So, with the approach we have developed these days we will ignore all writes
>> and return ~0 for reads for all unhandled ops, e.g. those which do not have 
>> explicit
>> register handlers employed. Thus, this case will fall into unhandled clause.
> Except that I guess BARs are special in that reads may not return ~0,
> or else the low bits carry a meaning we don't want to convey. Unused
> BARs need to be hard-wired to 0, I think.
So, you mean we should have 2 sets of BAR handlers for guests:
1. normal emulation (these are implemented in this patch)
2. all other BARs: read 0/ignore write for all other BARs, including ROM, IO 
etc.

Is this what you mean?
> Jan
>
Thank you,
Oleksandr