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

[Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>]

On 03.02.22 14:50, Jan Beulich wrote:
> On 03.02.2022 13:48, Oleksandr Andrushchenko wrote:
>> 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?
> I think that's what we're going to need, yes.
Ok, then I'll stuff that into this patch v6
> Jan
>
Thank you,
Oleksandr