From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: citrix.com, ip: 216.71.155.175, mailfrom: roger.pau@citrix.com) Received: from esa6.hc3370-68.iphmx.com (esa6.hc3370-68.iphmx.com [216.71.155.175]) by groups.io with SMTP; Tue, 23 Jul 2019 02:02:22 -0700 Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=roger.pau@citrix.com; spf=Pass smtp.mailfrom=roger.pau@citrix.com; spf=None smtp.helo=postmaster@mail.citrix.com Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender authenticity information available from domain of roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of roger.pau@citrix.com designates 162.221.158.21 as permitted sender) identity=mailfrom; client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83 ~all" Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender authenticity information available from domain of postmaster@mail.citrix.com) identity=helo; client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="postmaster@mail.citrix.com"; x-conformance=sidf_compatible IronPort-SDR: CwRODw5WB/rYh1tSJ3cuTVCUJ4z7FtTI05PDmGvnPuBX3EfwLTRH6tkBnDWP32a/8+9CEKW3Vm glcXnurySwbgtdCsZBlt8vwTWXsYGB/Y4dZJolsY8FUlsEdowy94WNH0vBdvmi8jDNZee7EJXk C328GoJr3B3w/T0G25Kapr1vZOiA3pKIKJdTZyM6puBzKh89dQx30e/gj7FXsHlHC0CTslb/jD 6EsFNyLoT53qhoYIkJalxCO5JfTl3k+GrO9fLYM4lXQ91lg4vAZkieQCeVn4BUPalUUeQ26M/Y OjE= X-SBRS: 2.7 X-MesageID: 3402570 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.64,298,1559534400"; d="scan'208";a="3402570" Date: Tue, 23 Jul 2019 11:02:05 +0200 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= To: Laszlo Ersek CC: Anthony PERARD , , , Ard Biesheuvel , Jordan Justen , Julien Grall , Andrew Cooper Subject: Re: [PATCH v3 09/35] OvmfPkg/OvmfXen: use a TimerLib instance that depends only on the CPU Message-ID: <20190723090205.6ksiqffrqgichbd2@Air-de-Roger> 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> <7bb00665-784b-e8d5-42cd-b34e22ada1eb@redhat.com> MIME-Version: 1.0 In-Reply-To: <7bb00665-784b-e8d5-42cd-b34e22ada1eb@redhat.com> User-Agent: NeoMutt/20180716 Return-Path: roger.pau@citrix.com X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit On Mon, Jul 22, 2019 at 09:28:20PM +0200, Laszlo Ersek wrote: > On 07/22/19 15:49, Anthony PERARD wrote: > > On Mon, Jul 15, 2019 at 04:22:19PM +0200, Roger Pau Monné 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. > > > > I'll reword that first sentence. > > > > 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. IMO passing information using such side-channels always looks attractive at first sight, until you realize at some point later that you just have ended up with a completely custom interface that duplicates ACPI. Having that said, Xen manages to get most of what it needs from static ACPI tables, but I'm not sure if OVMF could manage to do so also. Xen has quite a lot of baggage here, like using xenstore/xenbus instead of PCI, or custom 'start info pages' instead of ACPI, which we are currently trying to partially move away from when possible. Thanks, Roger.