Hi Jan, > On 12 Oct 2021, at 11:20, Jan Beulich <[email protected]> wrote: > > On 12.10.2021 12:06, Oleksandr Andrushchenko wrote: >> On 12.10.21 13:01, Jan Beulich wrote: >>> On 12.10.2021 11:38, Oleksandr Andrushchenko wrote: >>>> On 12.10.21 12:32, Jan Beulich wrote: >>>>> The minimal thing I'd suggest (or maybe you're doing this already) >>>>> would be to expose such BARs to the guest as r/o zero, rather than >>>>> letting their port nature "shine through". >>>> If we have the same, but baremetal then which entity disallows >>>> those BARs to shine? >>> I'm sorry, but I don't understand what you're trying to say. >>> >>>> I mean that if guest wants to crash... why >>>> should we stop it and try emulating something special for it? >>> This isn't about a guest "wanting to crash", but a driver potentially >>> getting mislead into thinking that it can driver a device a certain >>> way. >> Well, for the guest, as we do not advertise IO in the emulated host >> bridge, the driver won't be able to allocate any IO at all. Thus, even >> if we have a BAR with PCI_BASE_ADDRESS_SPACE_IO bit set, the >> driver won't get anything. So, I think this is equivalent to a baremetal >> use-case where we have no IO supported by the host bridge and >> a device with IO BAR. > > Oh, now I follow. Fair enough.
So there is no comment remaining on this patch ? Would it possible to get an ack on it ? Thanks Bertrand > > Jan
