From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH v2] AMD/intremap: Prevent use of per-device vector maps until irq logic is fixed Date: Tue, 4 Jun 2013 14:12:09 +0100 Message-ID: <51ADE7A9.2050804@eu.citrix.com> References: <6671fc79717aaaa9fd0d.1370030644@andrewcoop.uk.xensource.com> <51ACBF3702000078000DA924@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: <51ACBF3702000078000DA924@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: Andrew Cooper , Keir Fraser , Jacob Shin , Suravee Suthikulpanit , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 06/03/2013 03:07 PM, Jan Beulich wrote: >>>> On 31.05.13 at 22:04, Andrew Cooper wrote: >> In an effort to get AMD systems back to a non-regressed state, introduce a >> new >> type of vector map called per-device-global. This uses per-device vector maps >> in the IOMMU, but uses a single used_vector map for the core IRQ logic. > > So what's the reason for not simply using OPT_IRQ_VECTOR_MAP_GLOBAL > here? > >> This patch is intended to be removed as soon as the per-device logic is fixed >> correctly. > > As a last resort thing this may be acceptable, but I'd much favor to > fix this properly rather than hacking it like this. Hence I'd really like > to put up for discussion to instead use the patch[1] already posted > as preparatory for the multi-vector MSI support doing away with the > use of the vector for indexing the IRTE (and, in a second patch[2], > the enforcement of OPT_IRQ_VECTOR_MAP_PERDEV). Unfortunately this is the time of the release to do simple hacks. We can obviously back this out when we get hte multi-vector MSI suport in. > Also, overriding a command line request in the way you do is a > no-go imo - even if this would cause [theoretical] problems, we > ought to honor the request as long as we can't tell for sure that > this is going to break the specific system. That's even more so > since requesting per-device vector maps to be used on VT-d ought > to yield exactly the same effect, yet you don't override the mode > there. I agree -- we need to have a sensible default, but we also need to have a way to override behavior if it turns out to cause a problem. -George