From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Mon, 22 Jul 2019 12:28:23 -0700 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D7FA43DD47; Mon, 22 Jul 2019 19:28:22 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-23.ams2.redhat.com [10.36.117.23]) by smtp.corp.redhat.com (Postfix) with ESMTP id 208765B681; Mon, 22 Jul 2019 19:28:20 +0000 (UTC) Subject: Re: [PATCH v3 09/35] OvmfPkg/OvmfXen: use a TimerLib instance that depends only on the CPU To: Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Cc: devel@edk2.groups.io, xen-devel@lists.xenproject.org, Ard Biesheuvel , Jordan Justen , Julien Grall , Andrew Cooper References: <20190704144233.27968-1-anthony.perard@citrix.com> <20190704144233.27968-10-anthony.perard@citrix.com> <20190715142219.m2t67v2dcyabqp2p@MacBook-Air-de-Roger.local> <20190722134912.GF1208@perard.uk.xensource.com> From: "Laszlo Ersek" Message-ID: <7bb00665-784b-e8d5-42cd-b34e22ada1eb@redhat.com> Date: Mon, 22 Jul 2019 21:28:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190722134912.GF1208@perard.uk.xensource.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 22 Jul 2019 19:28:22 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 07/22/19 15:49, Anthony PERARD wrote: > On Mon, Jul 15, 2019 at 04:22:19PM +0200, Roger Pau Monn=C3=A9 wrote: >> On Thu, Jul 04, 2019 at 03:42:07PM +0100, Anthony PERARD wrote: >>> ACPI Timer does not work in a PVH guest, but local APIC works on both >> >> This is not accurate. It's not that the ACPI timer doesn't work, it's >> just that it's not present. The PM_TMR_BLK should be set to 0 to >> indicate the lack of PM timer support, or else there's something >> broken. >=20 > I'll reword that first sentence. >=20 > OVMF doesn't look at the PM_TMR_BLK value when initializing that timer, > it only looks at the PCI host bridge device ID because OVMF is built > with QEMU in mind and there are only two possibles choices, QEMU is > running with a piix or q35 machine type, I think. We should split this statement in two. :) OVMF doesn't look at ACPI payload because it is a design goal to keep the guest firmware un-enlightened about such ACPI contents that arrive from the hypervisor. Parsing ACPI in firmware always looks attractive until someone actually writes the code, and then it always ends in misery -- at the latest when people realize they have to parse AML. Parsing ACPI is only feasible when you have a full-blown ACPICA (or similar) subsystem, and edk2 doesn't. Therefore, OVMF looks at either hardware, or specialized paravirt information channels such as fw_cfg files, that are easy to parse by design. Second, within the above design guidelines (i.e. "don't try to parse ACPI", and "cook your paravirt info if you want the firmware to eat it"), OVMF looks at such artifacts to steer its behavior for which patches have been submitted & merged. OVMF is integrated with Xen to the extent of patches merged from the Xen community. Thus, in my opinion, "OVMF is built with QEMU in mind" is a stretch -- perhaps it is so in *my* mind personally, but that's just me. We have designated reviewers for Xen-related code, and this series certainly builds OVMF with Xen in mind. :) If we reworded the statement, e.g. as "the present code targets QEMU and is unsuitable when running on Xen", then I would not object. Thanks! Laszlo >>> PVH and HVM. >>> >>> Note that the use of SecPeiDxeTimerLibCpu might be an issue with a >>> driver of type DXE_RUNTIME_DRIVER. I've attemptde to find out which o= f >> ^ attempted >>> the DXE_RUNTIME_DRIVER uses the TimerLib at runtime. I've done that b= y >>> replacing the TimerLib evaluation in >>> [LibraryClasses.common.DXE_RUNTIME_DRIVER] by a different one and >>> check every module that uses it (with the --report-file=3Dreport buil= d >> ^ checking >>> option). >>> >>> ResetSystemRuntimeDxe is calling the TimerLib API at runtime to do th= e >>> operation "EfiResetCold", so this may never complete if the OS have >>> disabled the Local APIC Timer. >> >> Thanks, Roger. >=20 > Thanks, >=20