On 25.05.2023 01:37, Stefano Stabellini wrote: > On Wed, 24 May 2023, Jan Beulich wrote: >>>> RFC: _setup_hwdom_pci_devices()' loop may want splitting: For >>>> modify_bars() to consistently respect BARs of hidden devices while >>>> setting up "normal" ones (i.e. to avoid as much as possible the >>>> "continue" path introduced here), setting up of the former may want >>>> doing first. >>> >>> But BARs of hidden devices should be mapped into dom0 physmap? >> >> Yes. > > The BARs would be mapped read-only (not read-write), right? Otherwise we > let dom0 access devices that belong to Xen, which doesn't seem like a > good idea. > > But even if we map the BARs read-only, what is the benefit of mapping > them to Dom0? If Dom0 loads a driver for it and the driver wants to > initialize the device, the driver will crash because the MMIO region is > read-only instead of read-write, right? > > How does this device hiding work for dom0? How does dom0 know not to > access a device that is present on the PCI bus but is used by Xen?
None of these are new questions - this has all been this way for PV Dom0, and so far we've limped along quite okay. That's not to say that we shouldn't improve things if we can, but that first requires ideas as to how. > The reason why I was suggesting to hide the device completely in the > past was that I assumed we had to hide the device (make it "disappear" > on the PCI bus) otherwise Dom0 would access it. Is there another way to > mark a PCI devices as "inaccessible" or "disabled"? I'm no aware of any. Jan