[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: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Thu, 26 Aug 2021 12:57:48 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=6OIeHmCXGd3cZETkQYZCD/HejpGdbKLaSceHvX0G5AI=; b=PEaz9Eq1tBde7umfm7Xcvk2bFL+b0EUUUzTU5G0kTTNEswN6QOrc/SA6w/hloNWy6AaDuQWd468FL1SrwjUBS3+6ytUD3cyRt+jAoGk4h2ylJKgP3brONrFlk5TdRWDeq57QKR4o6HymPVZ8G64mxwyIyKJPO3WfTwF0YDCDcqBjRu8hEDxis9ZoRaxK+V2dRmpPKZR6LK2MV3pfV5g3+Kqik8oOCefMoc+ZRFxNPcx3K11xi+zxWoaKvDHLJe73F3a/Kej/GVTvVG71tEAUPL4hOsLM17GbP5UiA+rVid1MwdL0z6pWrS3ShogUSy56mKGBZ66pnEkWqo2ZSAx8TQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fNtDMpEj/HWoFZ+ygrYRyjMfLHtbKlrjuEs3AZ9oqlEnV+TgXucSsiSyeiAIDs5emmZPgS+yPU/Pnu5/nX2GkUIIWt0LQctCVtvQNgZvEA+HlqoaemFOhawap9mE1rOOCUs5xBw3KRXkiJlZtKNE8E3feOjrqeIewOZtoVz3n+MOqpKEXbITKvd2qfZNm5auamEb4hhXR8nqzUcG+YiNUUVGcI7t8R61H5Xda/oVrynzHerPElSUtlcG0pv+xJhrRwhGW4BXbUvIBNDQobkat/kEN5oeeSuYmAUzI8sWRpIJ3HOixLrm5KFn3mfD6Ulqwyyt6uS0Gc5vUfUfE2a7WA==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Paul Durrant <paul@xxxxxxx>
  • Delivery-date: Thu, 26 Aug 2021 11:58:02 +0000
  • Ironport-hdrordr: A9a23:vbvRyaMtjAzJbcBcT1b155DYdb4zR+YMi2TDiHofdfUFSKClfp 6V8cjztSWUtN4QMEtQ/OxoS5PwPk80kqQFnbX5XI3SITUO3VHHEGgM1/qb/9SNIVyYygcZ79 YbT0EcMqyBMbEZt7eC3ODQKb9Jq7PmgcPY99s2jU0dKT2CA5sQnjuRYTzrdHGeKjM2Z6bRWK Dsnfau8FGbCAoqh4mAdzU4dtmGg+eOuIPtYBYACRJiwA6SjQmw4Lq/NxSDxB8RXx5G3L9nqA H+4kLEz5Tml8v+5g7X1mfV4ZgTsNz9yuFbDMjJrsQOMD3jhiuheYwkcbyfuzIepv2p9T8R4Z bxiiZlG/42x2Laf2mzrxeo8w780Aw243un8lOciWuLm72zeBsKT+56wa5JeBrQ7EQt+Ptm1r hQ4m6fv51LSTvdgSXU/bHzJlJXv3vxhUBnvf8YjnRZX4dbQqRWt5Yj8ERcF4pFND7m6bogDP JlAKjnlbZrmGuhHjXkV1RUsZiRtixZJGbAfqFCgL3V79FupgE686NCr/Zv2EvpnfkGOup5D+ etCNUhqFgBdL5OUUtHPpZ0fSKAMB2Fffv9ChPmHb3ZLtBxB5vske+83Fxn3pDmRHQ3pKFC7q gpFmko7VIPRw==
  • Ironport-sdr: YI3Hl2UGxYjr8dNhEb+1v/auC0rvJOhvHgSnaL/SBXc30YrfBFwNNOO8tGSD1FQPiMCH7uOJsa fiWyjWF7Jh5SlHdHWzKHhQOJ6/C0XiH+2lueWcwhD2BnMhQbZLX3MTPFwac8GPUoytZpShP5cC 1fQa/WL18s9ewdeXc3s+CIV+qGfdjfxqEMucAqN9Q/QPXIWhSdraiNJikVg1Ef6QmDRYFMwLfz cT1+jgdXS1ydCdoE+rZ2YVd9Vea3iVxodWkqo5xlHOUlqrGMnAm5H3WElBHFh5IE2eeVTdYkpU BnJmNUxNtObMfnFisDPovI7B
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.

~Andrew




 


Rackspace

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