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

Re: [PATCH 07/17] IOMMU/x86: restrict IO-APIC mappings for PV Dom0


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 26 Aug 2021 14:55:31 +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=GkdarjXc8B8bFHYz96Y6As4hYdJunFAUoysTUjn4Pmk=; b=bGZp8KDtbMuoCmADpaOFifcpnj4JS83cDAYpKvffhKpAKLUunqnwLciUN9MCKJizSYyDepMGBD2uVcJh5Z8Azk80neHJNHpxwdI7ZyuEI9OcFdHR76Szx8fpT5w5W2uSCQtGMk8F2FnEakB7CnGy1FtpHZMq9v13WbGcdGvo8MQJ/5pCKXtK6A1vJh/7gwUQRNBALSdq04wQJlpWiAfTA5fTHylvQCu9iSWNxl3pnhYn9UeQEcbxOTEZrg0kBFoHHaOASP/1KxjC1/5bZvZZ+o1GWULuY7Dp5qJ9qJHVAgid1IOg/s+tBdAp0uhWU7Tx+5CPpCv3WO/8ljlUygmrZQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NRGYqXVy3CW0vOCwniPUZucaUNCb17UJSaHhIPjbfJ0e9c1S06H6n+KMzUBKl4+gdgcYbjaGcni63zKNUZmWDZsRsfTJSYnF7vYOKmc8MaQXZTttUmuuQwPXGVt9qln6JMkKmHYBnO6oI7JJ1cvEqBba4R+beHZL2V66hfYZS5LN0zQHnMpgN4e7yUfngobjR+RBTy3dSqa1l8U/mvYYgGd5zK6XZqT4mYH4dY5HIdgMGHD3KVDlZJUZgRmNBUNlwxC4Yj4+LLLsAGrgcjRkMJ6mHqtL1VILUcZRn3En5DH8N1ks0cDexDrf1ZuNNK3IVcADXZZEXWIFtORi0gWu/Q==
  • 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: Paul Durrant <paul@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 26 Aug 2021 12:56:03 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 26.08.2021 13:57, Andrew Cooper wrote:
> On 24/08/2021 15:21, Jan Beulich wrote:
>> While already the case for PVH, there's no reason to treat PV
>> differently here, though of course the addresses get taken from another
>> source in this case. Except that, to match CPU side mappings, by default
>> we permit r/o ones. This then also means we now deal consistently with
>> IO-APICs whose MMIO is or is not covered by E820 reserved regions.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Why do we give PV dom0 a mapping of the IO-APIC?  Having thought about
> it, it cannot possibly be usable.
> 
> IO-APICs use a indirect window, and Xen doesn't perform any
> write-emulation (that I can see), so the guest can't even read the data
> register and work out which register it represents.  It also can't do an
> atomic 64bit read across the index and data registers, as that is
> explicitly undefined behaviour in the IO-APIC spec.
> 
> On the other hand, we do have PHYSDEVOP_apic_{read,write} which, despite
> the name, is for the IO-APIC not the LAPIC, and I bet these hypercalls
> where introduced upon discovering that a read-only mapping of the
> IO-APIC it totally useless.
> 
> I think we can safely not expose the IO-APICs to PV dom0 at all, which
> simplifies the memory handling further.

The reason we do expose it r/o is that some ACPI implementations access
(read and write) some RTEs from AML. If we don't allow Dom0 to map the
IO-APIC, Dom0 will typically fail to boot on such systems. What we have
right now seems to be good enough for those systems, no matter that the
data they get to read makes little sense. If we learned of systems
where this isn't sufficient, we'd have to implement more complete read
emulation (i.e. latching writes to the window register while still
discarding writes to the data register).

If we produced a not-present PTE instead of a r/o one for such mapping
requests, I'm afraid we'd actually further complicate memory handling,
because we'd then need to consider for emulation also n/p #PF, not just
writes to r/o mappings.

This said - I'd also be fine with consistently not mapping the IO-APICs
in the IOMMU page tables. It was you to request CPU and IOMMU mappings
to match. What I want to do away with is the present mixture, derived
from the E820 type covering the IO-APIC space.

Jan




 


Rackspace

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