Re: [PATCH 4/4] AMD IOMMU: untie remap and vector maps

[George Dunlap <george.dunlap@eu.citrix.com>]

On 28/03/13 13:09, Jan Beulich wrote:
>>>> On 28.03.13 at 13:37, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>> On Tue, Mar 26, 2013 at 9:05 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>> With the specific IRTEs used for an interrupt no longer depending on
>>> the vector, there's no need to tie the remap sharing model to the
>>> vector sharing one.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Unfortunately I'm having a bit of trouble "paging in" the technical
>> details of why this change was necessary.  I thought that the
>> limitation had to do with the remapping table itself.  Are you saying
>> that if interrupt X maps to pcpu 0 vector 5, and interrupt Y maps to
>> pcpu 2 vector 5, that even if X and Y are in the same table, they will
>> still go to the right place?  Could you give me a brief explanation of
>> why that is?  (I don't know what IRTE is, and Google is not helpful.)
> Previously the remapping table was indexed by vector (combined
> with delivery mode, for whatever reason). That way, a particular
> vector, no matter which CPU it would have been meant to go to
> caused the same IRTE (Interrupt Remapping Table Entry) to be
> selected, and with it the same destination ID.
>
> By not using the vector for indexing anymore, a vector allocated
> in CPU A's space connects with IRTE x with destination ID set to
> (or including, when in cluster or flat mode) whereas CPU B's
> identical vector connects to a different IRTE (even when using a
> single global remapping table), properly set to the destination ID
> for (or including) that CPU.

OK -- well assuming that to be the case:

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>