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

Re: [PATCH for-4.18 v2] x86/pvh: fix identity mapping of low 1MB


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 16 Oct 2023 16:51:35 +0200
  • 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=e2Bl8+R+zQ9Oc93xbqXDApgOEMu2IKkIH1S+p0mCo88=; b=UfIEG/yH0raLJPcEqjqZqR73WIwxCPc548uK0kOltyHtohE1QkJFKdUha5L+cFduGuRy+GKw/cztOdN5UkZBBe3w0oiS8DbdCumgOoW6FUXvU3s5zznMOtm+01hZGEGdwTCg28IuOQ2YFxbiuOlaD/dELHHqlrV8/VEHFX565oxlQ7U5fVf59lYevEX1zjxKYPdNUj/pb/lXMG16wexHOsqAR7XaquJurs6yvzq5VcMawZH5PO81jZjvIGdR87q/pilQ+5ktSYykzHwXaHH3vhWGYRI8U+iq/CzhfeQAXp7ku5pDZalmwEQQ1Mv/JF10lvyMhlV3HNJxRL8Jr/tOMA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OJc63Litq7Xx+4MKOmJyRGWfXHb/XNG//Jt326EFL7wu+VYovIPyS+sidxfw9zf+h1C+H9FWe6oK1x6A0ihVwiQM0GDIHWcu9ywqjwTJLf1/xqf9H0gn0U4aSfq/VM+Z1ddt30M5e2H+bFTQ0e8XdsHCUMj0J6I+Pq0LM9JfGjreHDw9D/JI9G042G3Pc0dINL0vREtIDWYHffUNCkzRLlWBUpyh6uZfS1HGujqbKC6nfR+f58tLCiVbs3nfrDThONT+vM6oj4XCXw8eSZmX32pqMvb33KN3niM54yJzsOXJdw8hFBVszOUOBy+O6Gx8HayhTk2UOdhm1jUifVpMhg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Henry Wang <Henry.Wang@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Paul Durrant <paul@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 16 Oct 2023 14:51:55 +0000
  • Ironport-data: A9a23:feG0baDgDZhWihVW/+niw5YqxClBgxIJ4kV8jS/XYbTApDwg0jwDx 2NMD2vXOPiIYmHwLtogPtmw8UMFusfTmNEwQQY4rX1jcSlH+JHPbTi7wuUcHAvJd5GeExg3h yk6QoOdRCzhZiaE/n9BCpC48D8kk/nOH+KgYAL9EngZbRd+Tys8gg5Ulec8g4p56fC0GArIs t7pyyHlEAbNNwVcbCRMsMpvlDs15K6p4WtB4ARnDRx2lAS2e0c9Xcp3yZ6ZdxMUcqEMdsamS uDKyq2O/2+x13/B3fv8z94X2mVTKlLjFVDmZkh+AsBOsTAbzsAG6Y4pNeJ0VKtio27hc+ada jl6ncfYpQ8BZsUgkQmGOvVSO3kW0aZuoNcrLZUj2CA6IoKvn3bEmp1T4E8K0YIwxOhPBXsN0 9chETEtTiughNPs5r+Rc7w57igjBJGD0II3nFhFlGicJ9B2BJfJTuPN+MNS2yo2ioZWB/HCa sEFaD1pKhPdfxlIPVRRA5U79AuqriCnL3sE9xTI9exuvTm7IA9ZidABNPLPfdOHX4NNl1uwr WPa5WXpRBodMbRzzBLcqCz12r+ewnOTtIQ6EeS8xqRGgQKv/0cpDzBIdla9p/m8sxvrMz5YA wlOksY0loAw/kG2Stj2XzWjvWWJ+BUbXrJ4M+A88hDL9aPS7C6QHG1CRTlEAPQ5sOcmSDps0 UWG9/vxDCFrmK2YTzSa7Lj8hSO/P20ZIHEPYQcATBAZ+J/zrYcrlBXNQ91/VqmvgbXI9SrYx jmLqG00geUVhMtSjqGjpwmZ0nSru4TDSRMz6kPPRGW54whlZYmjIYu19Vzc6vUGJ4GcJrWcg EU5dwGlxLhmJfmweOalGY3hwJnBCy65DQDh
  • Ironport-hdrordr: A9a23:Ao3FoaM42G3soMBcTvujsMiBIKoaSvp037BL7SxMoHluGfBw+P rAoB1273HJYVQqOE3I6OrgBEDoexq1n/NICO8qTNWftWLdyQiVxe9ZnOzf6gylNyri9vNMkY dMGpIObuEY1GIK6PoSNjPId+od/A==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Mon, Oct 16, 2023 at 04:07:22PM +0200, Jan Beulich wrote:
> On 16.10.2023 15:51, Roger Pau Monné wrote:
> > On Mon, Oct 16, 2023 at 03:32:54PM +0200, Jan Beulich wrote:
> >> On 13.10.2023 10:56, Roger Pau Monne wrote:
> >>> The mapping of memory regions below the 1MB mark was all done by the PVH 
> >>> dom0
> >>> builder code, causing the region to be avoided by the arch specific IOMMU
> >>> hardware domain initialization code.  That lead to the IOMMU being enabled
> >>> without reserved regions in the low 1MB identity mapped in the p2m for PVH
> >>> hardware domains.  Firmware which happens to be missing RMRR/IVMD ranges
> >>> describing E820 reserved regions in the low 1MB would transiently trigger 
> >>> IOMMU
> >>> faults until the p2m is populated by the PVH dom0 builder:
> >>>
> >>> AMD-Vi: IO_PAGE_FAULT: 0000:00:13.1 d0 addr 00000000000eb380 flags 0x20 RW
> >>> AMD-Vi: IO_PAGE_FAULT: 0000:00:13.1 d0 addr 00000000000eb340 flags 0
> >>> AMD-Vi: IO_PAGE_FAULT: 0000:00:13.2 d0 addr 00000000000ea1c0 flags 0
> >>> AMD-Vi: IO_PAGE_FAULT: 0000:00:14.5 d0 addr 00000000000eb480 flags 0x20 RW
> >>> AMD-Vi: IO_PAGE_FAULT: 0000:00:12.0 d0 addr 00000000000eb080 flags 0x20 RW
> >>> AMD-Vi: IO_PAGE_FAULT: 0000:00:14.5 d0 addr 00000000000eb400 flags 0
> >>> AMD-Vi: IO_PAGE_FAULT: 0000:00:12.0 d0 addr 00000000000eb040 flags 0
> >>>
> >>> Those errors have been observed on the osstest pinot{0,1} boxes (AMD 
> >>> Fam15h
> >>> Opteron(tm) Processor 3350 HE).
> >>>
> >>> Mostly remove the special handling of the low 1MB done by the PVH dom0 
> >>> builder,
> >>> leaving just the data copy between RAM regions.  Otherwise rely on the 
> >>> IOMMU
> >>> arch init code to create any identity mappings for reserved regions in 
> >>> that
> >>> range (like it already does for reserved regions elsewhere).
> >>>
> >>> Note there's a small difference in behavior, as holes in the low 1MB will 
> >>> no
> >>> longer be identity mapped to the p2m.
> >>
> >> I certainly like the simplification, but I'm concerned by this: The BDA
> >> is not normally reserved, yet may want accessing by Dom0 (to see the real
> >> machine contents). We do access that first page of memory ourselves, so
> >> I expect OSes may do so as well (even if the specific aspect I'm thinking
> >> of - the warm/cold reboot field - is under Xen's control).
> > 
> > The BDA on the systems I've checked falls into a RAM area on the
> > memory map, but if you think it can be problematic I could arrange for
> > arch_iommu_hwdom_init() to also identity map holes in the low 1MB.
> 
> Hmm, this again is a case where I'd wish CPU and IOMMU mappings could
> be different. I don't see reasons to try I/O to such holes, but I can
> see reasons for CPU accesses (of more or less probing kind).

Hm, while I agree devices have likely no reason to access holes (there
or elsewhere) I don't see much benefit of having this differentiation,
it's easier to just map everything for accesses from both device and
CPU rather than us having to decide (and maybe get wrong) whether
ranges should only be accessed by the CPU.

> > Keep in mind this is only for PVH, it won't affect PV.
> 
> Of course.

Would you be willing to Ack it?

Thanks, Roger.



 


Rackspace

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