[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH for-5.0 v11 08/20] virtio-iommu: Implement translate
From: |
Auger Eric |
Subject: |
Re: [PATCH for-5.0 v11 08/20] virtio-iommu: Implement translate |
Date: |
Thu, 9 Jan 2020 12:01:26 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 |
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?
Thanks
Eric
>
> 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
>
>
- Re: [PATCH for-5.0 v11 08/20] virtio-iommu: Implement translate, Jean-Philippe Brucker, 2020/01/06
- Re: [PATCH for-5.0 v11 08/20] virtio-iommu: Implement translate, Peter Xu, 2020/01/06
- Re: [PATCH for-5.0 v11 08/20] virtio-iommu: Implement translate, Jean-Philippe Brucker, 2020/01/07
- Re: [PATCH for-5.0 v11 08/20] virtio-iommu: Implement translate, Auger Eric, 2020/01/08
- Re: [PATCH for-5.0 v11 08/20] virtio-iommu: Implement translate, Jean-Philippe Brucker, 2020/01/09
- Re: [PATCH for-5.0 v11 08/20] virtio-iommu: Implement translate, Auger Eric, 2020/01/09
- Re: [PATCH for-5.0 v11 08/20] virtio-iommu: Implement translate, Jean-Philippe Brucker, 2020/01/09
- Re: [PATCH for-5.0 v11 08/20] virtio-iommu: Implement translate,
Auger Eric <=
- Re: [PATCH for-5.0 v11 08/20] virtio-iommu: Implement translate, Jean-Philippe Brucker, 2020/01/09
- Re: [PATCH for-5.0 v11 08/20] virtio-iommu: Implement translate, Auger Eric, 2020/01/09