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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 28/03/13 13:09, Jan Beulich wrote:
> > > > On 28.03.13 at 13:37, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:
> > On Tue, Mar 26, 2013 at 9:05 AM, Jan Beulich <JBeulich@xxxxxxxx> 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@xxxxxxxx>
> > 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@xxxxxxxxxxxxx>

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