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 <[email protected]> >>>>>> wrote: >>>>>> >>>>>> From: Oleksandr Andrushchenko <[email protected]> >>>>>> >>>>>> 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
