From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH 4/4] AMD IOMMU: untie remap and vector maps Date: Thu, 28 Mar 2013 13:40:52 +0000 Message-ID: <51544864.8070308@eu.citrix.com> References: <51516FA502000078000C86E1@nat28.tlf.novell.com> <515172E302000078000C8719@nat28.tlf.novell.com> <51544F3702000078000C9419@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51544F3702000078000C9419@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Jacob Shin , Xiantao Zhang , Suravee Suthikulpanit , xen-devel List-Id: xen-devel@lists.xenproject.org On 28/03/13 13:09, Jan Beulich wrote: >>>> On 28.03.13 at 13:37, George Dunlap wrote: >> On Tue, Mar 26, 2013 at 9:05 AM, Jan Beulich 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 >> 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