qemu-arm
[Top][All Lists]
Advanced

[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
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]