From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from esa3.hc3370-68.iphmx.com (esa3.hc3370-68.iphmx.com [216.71.145.155]) by mx.groups.io with SMTP id smtpd.web08.13030.1611071562664655966 for ; Tue, 19 Jan 2021 07:52:43 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@citrix.com header.s=securemail header.b=a3CESiSB; spf=pass (domain: citrix.com, ip: 216.71.145.155, mailfrom: anthony.perard@citrix.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1611071562; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=zGgBwsi4p5FyA2vaxH2uW9hggNEBCHSFZHK5BydXLd0=; b=a3CESiSBCYrlLkBhnGn1sdgKHSUbUIjRmYrP5trFSRLgv+qVRgl/u+Q7 m9O6ihThumVzStYA9R3TuBBVzEyJ+VlHPI1Vupf2N1HTAJAB9CqqM/J5g zgrTAReNd0B/nBAQ968F3C8jm4ioEN1FB70ODJyUMFuqdgPXTiEtn3M9M 4=; Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: uB9BvnCeXG/ji9vPUkoeqf6xQHvQvn8a72B2/0pwPnKdh7N1bXK7kJt50eQuGwRgZiILXIs9LO sl64O2PcrBtJRZat3LssubpL9QDC5kLtJRg+qlFKYYrWPcJtkdLHykDe0DpzlYrL9BheNqjLYG k5lUU1u1UDcJjct6uqr7oWD/kAkBMktLmXTyCDS1RcMPnXJaoFohD3LVAsjF8a4c9ErTuUVYpW vclZdToa/w3v2OLcZfwnXhsG4VtQnEd16261wLgfVU+ysUAX8KRdLtBgzT3Ey1tH+D9ym3VjtU 8N0= X-SBRS: 5.1 X-MesageID: 35384794 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.79,359,1602561600"; d="scan'208";a="35384794" Date: Tue, 19 Jan 2021 15:52:38 +0000 From: "Anthony PERARD" To: , CC: , Igor Druzhinin , , , Subject: Re: [edk2-devel] [PATCH] OvmfPkg/XenPlatformPei: Use CPUID to get physical address width on Xen Message-ID: References: <1610509335-23314-1-git-send-email-igor.druzhinin@citrix.com> <2a806f26-04f7-a96b-522c-118ac94df8c0@xen.org> <0d7ad7aa-cfa9-5f2c-26e3-6b371737f6bc@redhat.com> MIME-Version: 1.0 In-Reply-To: <0d7ad7aa-cfa9-5f2c-26e3-6b371737f6bc@redhat.com> Return-Path: anthony.perard@citrix.com Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline On Tue, Jan 19, 2021 at 03:49:34PM +0100, Laszlo Ersek wrote: > On 01/19/21 10:37, Julien Grall wrote: > > Hi Igor, > > > > On 13/01/2021 03:42, Igor Druzhinin wrote: > >> We faced a problem with passing through a PCI device with 64GB BAR to > >> UEFI guest. The BAR is expectedly programmed into 64-bit PCI aperture at > >> 64G address which pushes physical address space to 37 bits. That is above > >> 36-bit width that OVMF exposes currently to a guest without tweaking > >> PcdPciMmio64Size knob. > >> > >> The reverse calculation using this knob was inhereted from QEMU-KVM > >> platform > >> code where it serves the purpose of finding max accessible physical > >> address without necessary trusting emulated CPUID physbits value (that > >> could > >> be different from host physbits). On Xen we expect to use CPUID policy > >> to level the data correctly to prevent situations with guest physbits > > >> host physbits e.g. across migrations. > >> > >> The next aspect raising concern - resource consumption for DXE IPL > >> page tables > >> and time required to map the whole address space in case of using CPUID > >> bits directly. That could be mitigated by enabling support for 1G pages > >> in DXE IPL configuration. 1G pages are available on most CPUs produced in > >> the last 10 years and those without don't have many phys bits. > >> > >> Remove all the redundant code now (including PcdPciMmio64.. handling > >> that's > >> not used on Xen anyway) and grab physbits directly from CPUID that should > >> be what baremetal UEFI systems do. > >> > >> Signed-off-by: Igor Druzhinin > > > > Reviewed-by: Julien Grall > > I'm going to hold this patch until Anthony responds in this thread as well: This new patch is fine, I didn't notice that it was a replacement for the previous one. Reviewed-by: Anthony PERARD Thanks, -- Anthony PERARD