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

Re: [Xen-devel] [PATCH 1/2] x86/iommu: avoid mapping the interrupt address range for hwdom

  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <JBeulich@xxxxxxxx>
  • Date: Thu, 25 Jul 2019 12:06:48 +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=s/FHfCnQ8lSbmKWI57t9yVMpA7frBuzkxcE+/ZKdf8U=; b=DGDFPCw8jfUADC7PpwAx5CGahJ8nsoB+dLoUJFnT9eQYbp8GH5Mzytfene9eVzk2wonQAyArhNu7gOw/1o+yBnRVPwmfuOMnUxnMoBkjZLnPALi1gcKzXeIIRMrGNlFXyUeW4ZmpBbWliHpaQpjUvQYxF/jOx1PsIYxtY1uzYLgS8K/pxwjg380uRITkhGOmWnUBmThY7y4qzxw7WPNxtG01lCCR24E+KfrkBSVGj7hzh9wcCoDDdhlPKevtlzx3U5CYYFVrIsu3VMNEy1AadjR2lhuQAzg9y26WgtFzBX5rfuljbcCT2Zrqi4QD+fNTnXCL4G6joR0up3Q7F68GNw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g15IIIPFNDw2R6s/lwy4L8a1OODZHl97T9YHcbx/r5TUhwFvK5Nd5KHyYiC/uKbxG6xGlH89zh2PvSCo/TBagVM4CnegOe+fVBWjejStvlnMI8Zmwm1jtKfOkNkzVWS7plEMyBC88dSq+ipZpFYYpuVNxrMdTnP4/GATPzM31XPt4GjYYBHiDcnRKS5xTXb8hXa2qlsLMVWi9ciuoPaKFpJrmOBdIi8xFfN/N6M076prGZYrxBvBJ8Kv28qPiMMXDFCL5BQ9M2ETQu4lf4Kz48Mo111Ng13eJ0JVDtZBr3hBehmmCc6cXa9FFb2Jt1vYrdnsOCc60E8OthZNXmtWMg==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=JBeulich@xxxxxxxx;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 25 Jul 2019 12:12:15 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVQW4v+Mw2bodxPUiy9HdTXv5ycabbIsgAgAAJLSmAABQCgA==
  • Thread-topic: [PATCH 1/2] x86/iommu: avoid mapping the interrupt address range for hwdom

On 25.07.2019 12:54, Roger Pau Monné  wrote:
> On Thu, Jul 25, 2019 at 10:22:17AM +0000, Jan Beulich wrote:
>> On 23.07.2019 17:48, Roger Pau Monne wrote:
>>> Current code only prevent mapping the lapic page into the guest
>>> physical memory map. Expand the range to be 0xFEEx_xxxx as described
>>> in the Intel VTd specification section 3.13 "Handling Requests to
>>> Interrupt Address Range".
>>> AMD also lists this address range in the AMD SR5690 Databook, section
>>> 2.4.4 "MSI Interrupt Handling and MSI to HT Interrupt Conversion".
>>> Requested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>> I've committed this on the basis that it shouldn't hurt, but having
>> thought about this some more I'm not really sure I see the point:
>> The IOMMU special cases accesses into this range anyway, to redirect
>> lookup to the interrupt remapping table instead of the DMA remapping
>> one. Hence any mappings inserted into this range are simply useless,
>> but shouldn't otherwise hurt.
> Intel SDM contains:
> "Software must ensure the second-level paging-structure entries are
> programmed not to remap input addresses to the interrupt address
> range. Hardware behavior is undefined for memory requests remapped to
> the interrupt address range."
> In section 3.13 (Handling Requests to Interrupt Address Range).
> Since arch_iommu_hwdom_init/hwdom_iommu_map adds entries to both the
> hap and the iommu page tables (or to hap only if shared) Xen should be
> careful to not map this range because the iommu special cases this
> range, but I'm not sure what hap does.

Hmm, in the shared-pt case this is indeed desirable in any event. I
have to admit that I didn't recall that even in the non-shared case
arch_iommu_hwdom_init() would fiddle with the HAP tables as well,
rather than just the IOMMU ones. I don't think this should remain
this way long term. Or was there a reason for this to be needed?

Xen-devel mailing list



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