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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan