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

Re: [PATCH] IOMMU/x86: don't map IO-APICs for PV Dom0


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 25 Aug 2021 08:01:30 +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=qysnwWpWaAEYat+THO75eXDzTYF4Dld7hvJDPpzOulM=; b=Gtp+Scht2FOxHB4oKRZxWymhy0OOOz5UUaG+UP9Qzb//1FrOfqwmQ4Wetjjy5Fx+Jmb+K7kmi/iID09Kbo3tJ/p+vhQ9mIYmXZLmbSq8Tmfyi5C1HUTlTCIZhoCS2EShgcLLXiW5eVNvmU+sqOynOmpGJV7S5L++G7vhggoshrZIDK/axKpNX5CEk+1qXpU0JxVF5A8S8HUOVKkM094/UaxrSMktbvGokymL6jT3sKYVbEbXnLyHaER5601mnZCtUXAq7hjkPUf0fhcIMF56RtNW6gkkNyuRiXRa3VaPBEb0cKEcfr5cqQir+KeXusUuNdu4/vKZbHlRnmXjx0vl9w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OcZebtD+4b7Yumgy/Y0dSiYS6CtSQPq6VEN+BooNATZKhsx5Q4MtHMjDJYTr/rZMft/Itcuh80FRooVbk1O5eAW/pdqpuEyN2aFaDXuqD17Nzx0ZOE5g+P9wgCCqilw0fXlAyvXUbBpq+cWUJ5L6qIIFfQ2sHmZAqF7GK3Hsl+Ui7jQ08vaLxrA/czU+KInXzqiU/weFgrrH2XHbFVSlBjMEELFMieEXD29kkL/BwWOu98cimU13+MIrS9OKhPlc8f3IU//IOBIoGd1Ivc5WgcE2S3Ki727xXrQUFV2pAeNud44bLA+qM+niFYz+BZ+ji//ujIFAio6yGLhQZhn94A==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 25 Aug 2021 06:01:45 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 16.08.2021 20:31, Andrew Cooper wrote:
> On 16/08/2021 16:31, Jan Beulich wrote:
>> While already the case for PVH, there's no reason to treat PV
>> differently here (except of course where to take the addresses from).
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Honestly, this is already a mess but I think the change is making things
> worse rather than better.
> 
> To start with, IO-APIC windows are 1k not 4k, except that no-one added a
> "4k safe" flag because IO-APICs weren't mapped into userspace by Linux
> at the time.
> 
> More generally though, if something is safe to let dom0 map in the CPU
> pagetables, it is safe to go in the IOMMU pagetables.  Conversely, if
> it's not safe to go in one, it's not safe to go in either.
> 
> Mappings (or at least mapability) of everything/anything should be
> uniform between the CPU and IOMMU pagetables for any kind of sanity to
> prevail.

Just in case it's not obvious (it just occurred to me to mention it):
There's a similar inconsistency with all other MMIO: HVM/PVH get this
mapped in both CPU and IOMMU, while PV doesn't. If mappings were
mirrored to the IOMMU, the patch here wouldn't be necessary in its v2
form (or the form when integrated into the larger series), but instead
would be correct in this initial shape.

So if you think that's the way to go, I can restore the initial version
of this patch after adding a prereq one to mirror MMIO page mappings to
the IOMMU. There's one difficulty though: We'd need to have a way to
tell when it's safe to unmap from the IOMMU again. In case of multiple
CPU side mappings we can't unmap when the first of these mappings goes
away.

Jan




 


Rackspace

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