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. Jan
