From: Anthony PERARD <anthony.perard@citrix.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: <edk2-devel@ml01.01.org>, <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH RFC 04/14] OvmfPkg: Introduce XenPlatformPei
Date: Tue, 10 Jan 2017 16:08:23 +0000 [thread overview]
Message-ID: <20170110160823.GE1903@perard.uk.xensource.com> (raw)
In-Reply-To: <18f5f2d0-7b42-8fdf-3342-f98b186337d8@redhat.com>
On Thu, Jan 05, 2017 at 10:59:24AM +0100, Laszlo Ersek wrote:
> On 12/08/16 16:33, Anthony PERARD wrote:
> > A copy of OvmfPkg/PlatformPei without some of QEMU specific
> > initialization, Xen does not support QemuFwCfg.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> > ---
> > OvmfPkg/XenOvmf.dsc | 2 +-
> > OvmfPkg/XenOvmf.fdf | 2 +-
> > OvmfPkg/XenPlatformPei/Cmos.c | 64 ++++
> > OvmfPkg/XenPlatformPei/Cmos.h | 56 ++++
> > OvmfPkg/XenPlatformPei/Fv.c | 100 ++++++
> > OvmfPkg/XenPlatformPei/MemDetect.c | 449 +++++++++++++++++++++++++
> > OvmfPkg/XenPlatformPei/Platform.c | 536 ++++++++++++++++++++++++++++++
> > OvmfPkg/XenPlatformPei/Platform.h | 104 ++++++
> > OvmfPkg/XenPlatformPei/Xen.c | 231 +++++++++++++
> > OvmfPkg/XenPlatformPei/Xen.h | 45 +++
> > OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 110 ++++++
> > 11 files changed, 1697 insertions(+), 2 deletions(-)
> > create mode 100644 OvmfPkg/XenPlatformPei/Cmos.c
> > create mode 100644 OvmfPkg/XenPlatformPei/Cmos.h
> > create mode 100644 OvmfPkg/XenPlatformPei/Fv.c
> > create mode 100644 OvmfPkg/XenPlatformPei/MemDetect.c
> > create mode 100644 OvmfPkg/XenPlatformPei/Platform.c
> > create mode 100644 OvmfPkg/XenPlatformPei/Platform.h
> > create mode 100644 OvmfPkg/XenPlatformPei/Xen.c
> > create mode 100644 OvmfPkg/XenPlatformPei/Xen.h
> > create mode 100644 OvmfPkg/XenPlatformPei/XenPlatformPei.inf
>
> (1) You might want to add Citrix copyright notices to new files.
>
> (2) This module is a good example where the moved Xen functionality
> (even for HVM guests) should be possible to remove from the original
> PlatformPei module. (In a later, final patch.) Is that right?
Yes, that should be possible.
> (3) In the commit message, please list the removed fw_cfg-dependent
> functionality in more detail (all of which is dynamically skipped when
> the current PlatformPei module runs on Xen):
Will do.
> - GetFirstNonAddress(): controlling the 64-bit PCI MMIO aperture via the
> (experimental) "opt/ovmf/X-PciMmio64Mb" file
>
> - GetFirstNonAddress(): honoring the hotplug DIMM area
> ("etc/reserved-memory-end") in the placement of the 64-bit PCI MMIO aperture
>
> - NoexecDxeInitialization() is removed, so PcdPropertiesTableEnable and
> PcdSetNxForStack are left constant FALSE (not set dynamically from
> "opt/ovmf/PcdXxxx")
>
> - MaxCpuCountInitialization(), PublishPeiMemory(): the max CPU count is
> not taken from the QemuFwCfgItemSmpCpuCount fw_cfg key;
> PcdCpuMaxLogicalProcessorNumber is used intact and
> PcdCpuApInitTimeOutInMicroSeconds is never changed or used.
>
> - InitializeXenPlatform(), S3Verification(): S3 is assumed disabled (not
> consulting "etc/system-states" via QemuFwCfgS3Enabled()).
>
> - InstallFeatureControlCallback(): the feature control MSR is not set
> from "etc/msr_feature_control"
>
> Also removed:
> - SMRAM/TSEG-related low mem size adjusting (PcdSmmSmramRequire is
> assumed FALSE) in PublishPeiMemory(),
> - QemuInitializeRam() entirely,
>
> (4) I think the removal of PcdSmmSmramRequire is incomplete. IMO this
> PCD should either be removed completely (all uses, including the INF
> reference), assuming a FALSE value in its place, or the PCD should not
> be touched at all. The FeaturePcdGet() call in PublishPeiMemory() --
> gating the "TSEG is chipped from the end of low RAM" stuff -- seems to
> be singled out for removal for no good reason.
Yes, I think I will remove all of if. There is not much reason to keep
something that is not tested, and I don't know if it can work on Xen. I
guess SMM can be readded later.
> (5) It would be nice to hint at the reason (which is implemented in a
> later patch) why a separate module is a good idea here. That is, why the
> expected PVH2 functionality is best not added to the current PlatformPei
> module.
Will do.
--
Anthony PERARD
next prev parent reply other threads:[~2017-01-10 16:21 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-08 15:33 [PATCH RFC 00/14] Specific platform to run OVMF in Xen PVH and HVM guests Anthony PERARD
2016-12-08 15:33 ` [PATCH RFC 01/14] OvmfPkg: Create platform XenOvmf Anthony PERARD
2017-01-04 19:14 ` Laszlo Ersek
2016-12-08 15:33 ` [PATCH RFC 02/14] OvmfPkg/XenOvmf: Update debug IO port for Xen Anthony PERARD
2017-01-04 19:23 ` Laszlo Ersek
2016-12-08 15:33 ` [PATCH RFC 03/14] OvmfPkg/XenOvmf.dsc: Introduce XenResetVector Anthony PERARD
2017-01-04 19:49 ` Laszlo Ersek
2017-01-10 15:58 ` Anthony PERARD
2016-12-08 15:33 ` [PATCH RFC 04/14] OvmfPkg: Introduce XenPlatformPei Anthony PERARD
2017-01-05 9:59 ` Laszlo Ersek
2017-01-10 16:08 ` Anthony PERARD [this message]
2016-12-08 15:33 ` [PATCH RFC 05/14] OvmfPkg/Library: add XenPciHostBridgeLib Anthony PERARD
2017-01-05 10:15 ` Laszlo Ersek
2016-12-08 15:33 ` [PATCH RFC 06/14] OvmfPkg/XenPlatformPei: Add xen PVH specific code Anthony PERARD
2017-01-05 10:30 ` Laszlo Ersek
2017-01-10 16:18 ` Anthony PERARD
2017-01-10 16:54 ` Laszlo Ersek
2016-12-08 15:33 ` [PATCH RFC 07/14] OvmfPkg/XenResetVector: Add new entry point for Xen PVH Anthony PERARD
2017-01-05 10:36 ` Laszlo Ersek
2016-12-08 15:33 ` [PATCH RFC 08/14] OvmfPkg/PlatformBootManagerLib: Workaround missing PCI bus on " Anthony PERARD
2017-01-05 10:38 ` Laszlo Ersek
2016-12-08 15:33 ` [PATCH RFC 09/14] OvmfPkg/ResetSystemLib: Add missing dependency on PciLib Anthony PERARD
2017-01-05 10:46 ` Laszlo Ersek
2016-12-08 15:33 ` [PATCH RFC 10/14] UefiCpuPkg/BaseXApicX2ApicLib: Fix initialisation on my system and Anthony PERARD
2016-12-09 6:48 ` Kinney, Michael D
2016-12-12 12:38 ` Anthony PERARD
[not found] ` <58dbbeb0-f600-ef3f-7f8c-5c110b0aa809@citrix.com>
2016-12-12 12:40 ` [Xen-devel] " Anthony PERARD
2016-12-08 15:33 ` [PATCH RFC 11/14] OvmfPkg/XenOvmf: Adding XenTimerLocalApic Anthony PERARD
2017-01-05 11:26 ` Laszlo Ersek
2016-12-08 15:33 ` [PATCH RFC 12/14] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn Anthony PERARD
2017-01-05 16:38 ` Laszlo Ersek
2016-12-08 15:33 ` [PATCH RFC 13/14] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables Anthony PERARD
2017-01-05 16:58 ` Laszlo Ersek
2016-12-08 15:33 ` [PATCH RFC 14/14] XenOvmf: Use a different RTC Anthony PERARD
2017-01-05 17:02 ` Laszlo Ersek
2017-01-04 19:52 ` [PATCH RFC 00/14] Specific platform to run OVMF in Xen PVH and HVM guests Laszlo Ersek
2017-01-10 14:55 ` Anthony PERARD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170110160823.GE1903@perard.uk.xensource.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox