On Thu, Jan 09, 2020 at 09:58:49AM +0100, Auger Eric wrote: > >> I share Peter's concern about having a different default policy than x86. > > > > Yes I'd say just align with whatever policy is already in place. Do you > > think we could add a command-line option to let people disable > > default-bypass, though? That would be a convenient way to make the IOMMU > > protection airtight for those who need it. > Yes I could easily add a device option to disable the default bypass. > > Shall we change the meaning of the F_BYPASS feature then? If exposed by > the device, the device does bypass by default, otherwise it doesn't. > This would be controlled by the device option.
For a device that doesn't do bypass by default, the driver wouldn't have the ability to enable bypass (feature bit not offered, not negotiable). > The driver then could have means to overwrite this behavior once loaded? Let's keep the bypass feature bit for this. If the bit is offered, the driver chooses to enable or disable it. If the bit is not offered or not negotiated, then the behavior is deny. If the bit is offered and negotiated then the behavior is allow. We can say that before features negotiation (latched at features register write, I think, in practice?) the behavior is platform dependent. The current wording about bypass intends to discourage unsafe choices but makes a strong statement only about the device behavior after features negotiation. We could add a second feature bit specifically for the boot bypass behavior. It wouldn't be useful to the OS (the driver doesn't have a choice) but could present a bit in config space that allows a firmware to disable boot-bypass in a way that is sticky across reset. So when the OS resets the device after taking it over, it doesn't accidentally enable bypass. I wouldn't bother though. If a FW/bootloader is able to support virtio-iommu, the user might as well instantiate the device with the default-deny option. Thanks, Jean
