On Thu, Jan 09, 2020 at 12:01:26PM +0100, Auger Eric wrote: > Hi, > > On 1/9/20 11:40 AM, Jean-Philippe Brucker wrote: > > 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. > OK. May be worth adding in the spec later. > > By the way what is the plan for the vote?
The ballot closed and the spec is accepted for virtio-v1.2-cs01, with the condition that the stale statement about padding is removed (https://lists.oasis-open.org/archives/virtio-dev/201911/msg00083.html) Thanks, Jean
