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

Re: [Xen-devel] [PATCH v2 05/10] AMD/IOMMU: introduce 128-bit IRTE non-guest-APIC IRTE format


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <JBeulich@xxxxxxxx>
  • Date: Tue, 16 Jul 2019 06:39:22 +0000
  • Accept-language: en-US
  • 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=PqPOuuF372mYEX8n8h60jK8D0WrbiKw3ezLptdbuvxY=; b=Pe7PLKxpMLHqJAnl/6RctVWeuPz4u+WOsqDcla37gusUqeSsVR1he/SYkSBv6maW0KtscpslT9NeUO4nm1+9BGFNsUIzAx+YcemEp0n3zRvGNcWYz0zCXGRomYjwyJFwj5Ozui3Eyuif+EL8xG7t08kPdRgTKV5jQirouZisWMQs7aSLXpBHbbdn5Kh1UEO1U6+PFnonO/VqBc5CckFekHF/K4BbzU/4g49A/yISnFjkUbu21RuthXUzpV+iaEGR0QeWWuQp6+dM1asHe8bzDBeVLU/pVcxQ9I20sZqERTUs6jvPJMVuDxZUTSygwLX2msEFFBeYrEH3r0I+kjlyag==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Re8ZaCdxdgc06uiOo8KDiy1xdQ4AenrqLTJP5xGoTlZz3XCEH1nTkNxpqxz3MO7hSRtnu8Hxp1lXCQ3Lm3gSuaHWvixeBC+QuGBnW0JA2a1W5LK4Vv35C4CYAOMICKfHfbQdQ6WgDjpvSzglcqPvl9iGUVeC+DwPa97bT3053tmZ9PoQY29mssATSazAb3m6QuU6uDbfgVEbaYMt4t6LcGIm1tUuUwD35chLShUZQnXc6OLSy6/8QJMyRwh3GzXeMrVXjNrm1f5aM0ljqw7VvcV0Ap+kEFUU4o42r44u0IjgJ3PucR2cJZcV2epgbwFqB7a3K/mTKGxOyiZs/VJDoA==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=JBeulich@xxxxxxxx;
  • Cc: Brian Woods <brian.woods@xxxxxxx>, Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
  • Delivery-date: Tue, 16 Jul 2019 06:40:05 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVMO2UOHmA7j9ffkazg1PUO76EkKbM4IGA
  • Thread-topic: [PATCH v2 05/10] AMD/IOMMU: introduce 128-bit IRTE non-guest-APIC IRTE format

On 02.07.2019 16:41, Andrew Cooper wrote:
> On 27/06/2019 16:21, Jan Beulich wrote:
>> --- a/xen/drivers/passthrough/amd/iommu_intr.c
>> +++ b/xen/drivers/passthrough/amd/iommu_intr.c
>> @@ -40,12 +40,45 @@ union irte32 {
>>
>> -#define INTREMAP_TABLE_ORDER    1
>> +union irte_cptr {
>> +    const void *ptr;
>> +    const union irte32 *ptr32;
>> +    const union irte128 *ptr128;
>> +} __transparent__;
>> +
>> +#define INTREMAP_TABLE_ORDER (irte_mode == irte32 ? 1 : 3)
> 
> This is problematic for irte_mode == irteUNK.  As this "constant" is
> used in exactly two places, I'd suggest a tiny static function along the
> same lines as {get,update}_intremap_entry(), which can sensibly prevent
> code looking for a size before irte_mode is set up.

This was indeed a problem, and requires quite a bit of further rework:
Things only worked (almost) correctly because for irteUNK we'd also set
up a table fitting 128-bit entries. The issue is that
amd_iommu_update_ivrs_mapping_acpi() gets called (in the original code
immediately) ahead of amd_iommu_setup_ioapic_remapping(), yet so far it
is the latter what establishes irte_mode.

I'm now trying to figure whether / how far it would be feasible to go
by per-IOMMU settings rather than the global mode indicator. But that
in turn requires setting GAEn earlier. Another option (or maybe an
additional requirement) is to hand through the "xt" flag to further
functions.

Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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