[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: Tue, 17 Aug 2021 10:41:39 +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=fUjPLMY7Zp1DUK4pzMKO7ucZFv7T4+r3ayStoEtfTn8=; b=I5wjbt5Igh+zMIe9ASZXgzzyzjvpE9xMcTEvQigY6QTshl/dTObR1vjkfKpuKGslPb4GYV7hLXqV8uEcHGigjVN2DUJd54Lv4FwupRPa08AUkAE05y4UqoqwDRGlX5gJZTCJzzaBmI3O3QlVFvfOiLud2zw6LU24pspMCqugNt6XWMKqhl0OM0rsdnV+KLajMUw+RXDyjt3WB/CCd143mre4s1HW1jRAN341PFry+rixOil/k7zvdPMLOlWYMnB+/SZ9LHgHGDRBk3hTHVou/A4hMM4T3V76BCNkKhbmA/NenCxYPAnHfakTgcfiOGyyX79rFzzMSNaKOzYnTBah3A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P2005vV/2o3+1S0JizQoXBYUTSy1JtiLqYXLVrTMsi6+pKN5ftbQqiXAgUzAvWro3JXh7RgvjNdQUCaFRQsKGm05kfL3cph2+xvQCNfEpZUPGzF9h2ICffzG/TlG9/u89REJz3DjuEeizdyHjjZBxZvejhihBVRloRKvRUo1vNnvW6UCHAtz9bHH4XCK4kXWT6IkKqtcz05bPXawuO2TEoBf+BHkpwxdMZazHBx+B5JtnM1hAYFms3oLixU1W57vy4xR+5txYnFSaqSYpRYMc4NE86q6yC/ciipBxm8bH81j+8UbM/1ufpJXhYTh25/YB6zYI7NVtuAOj3GHD+utlw==
  • 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: Tue, 17 Aug 2021 08:41:50 +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.
> This is most easily demonstrated with PVH dom0 and shared vs split EPT
> tables.  Split vs shared is an internal choice within Xen, and shouldn't
> cause in any change in static DMA behaviour (obviously - there is
> transient difference with logdirty but that's not relevant here).

Well, as frequently my aim is consistency: Either we exclude IO-APIC
space here uniformly (regardless of guest type), or we include it.
Yet including is impossible for PVH afaict, because there's no MFN
to map to (IOW I don't buy all aspects of the last paragraph of your
reply - there's no mapping of the IO-APIC page(s) in either kind of
page tables).

I did notice the oddity while closely inspecting the IOMMU mappings
created for Dom0 in the context of finally making use of large pages
there. Seeing it I didn't think the IO-APICs should be mapped in the
IOMMU page tables when they are _not_ mapped / mappable in the CPU
ones (see the respective iomem_deny_access() in
dom0_setup_permissions()). Hence the change actually only brings us
to what you describe in the 2nd to last paragraph of your reply

Or wait - default behavior actually is to allow r/o mappings of the
IO-APIC pages. This would suggest the IOMMU mappings should be r/o
as well (unless the rangeset addition in ioapic_init_mappings()
failed). I can certainly alter the change to this effect, at the
expense of more code and more code churn.




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