qemu-devel
[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:32:32 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

Hi Jean,

On 1/9/20 12:15 PM, Jean-Philippe Brucker wrote:
> 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)

Ah OK. Sorry I missed the outcome. Congratulations!

Eric
> 
> Thanks,
> Jean
> 




reply via email to

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