[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] VT-d: Tylersburg errata apply to further steppings

  • To: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 3 Aug 2021 15:44:10 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XGSXQmza9CTdD4S04Q9EqGGjwV4arTNEsfAY1ryr2TE=; b=emyT//9zq6y8fRA1cfbImzADXCbDaOJjuAxw+2N0baIZv/w/UnuN/mOcO6/6MAhV33A3XeZnclrnHBoiYGAGy3BmcED4ysE5srhL0PO9PmR5U+7Ul80GsDx/nm2by88ptKwZG8LhflfGyatOl9mhDPjsBN8XpADaxKj0hycKNv++xBDb5ChPsgHCVewJ/zGmGCWdxiOJO7njaZwwrtTrz9pkpeAPfADEMGHlL0y/wT5Jy7k+q8IqMU23l8UNd9zV3z5jfjk/ZR/mqIZ4mlj4/rATQuVf5V49Da4QVQ1x2pYc9TmTdw1uVi1V3wqxp1tu0elnUHQGUwJZ6zETybMVSQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GJY0EREU/BONleY41U7DLCZL0dO0BUi7NDGSBkfSM2qoYVXf/gudMyHgyOndAZLwhzHTxygnY3whbqcYasC912dPY2IJuFHsTNSX9265oM9ck2pswem430hUQdA8BufSusTkoOEvNwwJm4UEGF1p/3VNOmhfo5c+/qMaETBz3nr8SdpDFGZiHmqN1YqUzHpwKqZy/xL25taoY/6mteULXHietI2WFGRbPuudVT8vWWtZf8nlAxfa7jbH+ZyZUOIWoKKk5vWPXmsZ+cOrYzaXyeNDB1yzdCkxz6TWdkxYeGmn1EN0ti24YWHNZJbc0/HwW1M5Sjd76rMP6E27bTc46w==
  • Authentication-results: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Delivery-date: Tue, 03 Aug 2021 13:44:23 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 03.08.2021 15:30, Marek Marczykowski-Górecki wrote:
> On Tue, Aug 03, 2021 at 03:16:14PM +0200, Jan Beulich wrote:
>> On 03.08.2021 15:12, Marek Marczykowski-Górecki wrote:
>>> On Tue, Aug 03, 2021 at 03:06:50PM +0200, Jan Beulich wrote:
>>>> On 03.08.2021 15:01, Marek Marczykowski-Górecki wrote:
>>>>> Ok, then, just setting iommu_intremap=false should do the right thing,
>>>> ... if "iommu=force" is in use (but not otherwise), ...
>>> But that's the purpose of iommu=force, no?
>>> With "iommu=force": strictly require IOMMU
>>> Without "iommu=force": use IOMMU on best-effort basis
>>> It makes sense to refuse the boot if intremap is broken in the first
>>> case. But also, it makes sense to allow using IOMMU without intremp in
>>> the second case.
>> I agree with both statements. What I disagree with is that the latter
>> happens by default (instead of only upon admin override), including
>> the case of intremap being unavailable in the first place.
> "upon admin override" - do I read the code right, that iommu=no-intremap
> will actually achieve this effect?

In the case of this quirk - yes, as the call to the checking function is
gated by a check of iommu_intremap. But by "admin override" I meant a
per-guest attribute, not a host-wide one that isn't explicitly meant to
cover all guests.

> Will that allow to use IOMMU without
> interrupt remapping on a hardware where it's broken? In that case, maybe
> at least add this info to the log message?

You mean to suggest the use of this option? I'd rather not, to be honest.
I don't think options like this should be suggested to be used. I'd
prefer if we had less of such options, i.e. if they went away after some
initial integration phase.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.