Re: [Xen-devel] Ping: Re: [PATCH 2/3] VT-d: correct dma_msi_set_affinity()

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 15/12/16 09:54, Jan Beulich wrote:
>>>> On 09.12.16 at 09:47, <JBeulich@xxxxxxxx> wrote:
>>>>> On 08.12.16 at 18:33, <andrew.cooper3@xxxxxxxxxx> 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.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel