On 15/12/16 14:16, Jan Beulich wrote:
>>>> On 15.12.16 at 13:52, <andrew.coop...@citrix.com> wrote:
>> On 15/12/16 09:54, Jan Beulich wrote:
>>>>>> On 09.12.16 at 09:47, <jbeul...@suse.com> wrote:
>>>>>>> On 08.12.16 at 18:33, <andrew.coop...@citrix.com> wrote:
>>>>> On 08/12/16 16:01, Jan Beulich wrote:
>>>>>> That commit ("VT-d: use msi_compose_msg()) together with 15aa6c6748
>>>>> Which commit?
>>>> Oops - initially I had intended the title to include the hash: 83cd2038fe.
>>>> I've adjusted the text.
>>>>
>>>>>> ("amd iommu: use base platform MSI implementation") introducing the use
>>>>>> of a per-CPU scratch CPU mask went too far: dma_msi_set_affinity() may,
>>>>>> at least in theory, be called in interrupt context, and hence the use
>>>>>> of that scratch variable is not correct.
>>>>>>
>>>>>> Since the function overwrites the destination information anyway,
>>>>>> allow msi_compose_msg() to be called with a NULL CPU mask, avoiding the
>>>>>> use of that scratch variable.
>>>>> Which function overwrites what? I can't see dma_msi_set_affinity()
>>>>> doing anything to clobber msg.dest32, so I don't understand why this
>>>>> change is correct.
>>>> msg.dest32 simply isn't being used. msg is local to that function, so
>>>> all that matters is which fields the function consumes. Is uses only
>>>> address and data, and updates address to properly specify the
>>>> intended destination. To guard against stale data (in
>>>> iommu->msi.msg), it may be reasonable to nevertheless set dest32
>>>> before storing msg into that field.
>>> Any further thoughts here? Do I need to resend with that one line
>>> added?
>> msg is tiny. I'd suggest just initialising to 0 at the start of the
>> function.
> Why? msi_compose_msg() does exactly that as its very first action.
Perhaps it would be easier to post a v2 of just this patch. I can't
work out which one line you are referring to.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
