From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>,
"George Dunlap" <George.Dunlap@eu.citrix.com>
Subject: [PATCH 0/3] x86: shim building adjustments
Date: Mon, 14 Sep 2020 14:37:18 +0200 [thread overview]
Message-ID: <5d86a23c-5dea-8697-9ba1-900d35b99695@suse.com> (raw)
The first change is simply addressing a build issue noticed by
Andrew. The build breakage goes beyond this specific combination
though - PV_SHIM_EXCLUSIVE plus HVM is similarly an issue. This
is what the last patch tries to take care of, in a shape already
on irc noticed to be controversial. I'm submitting the change
nevertheless because for the moment there looks to be a majority
in favor of going this route. One argument not voiced there yet:
What good does it do to allow a user to enable HVM when then on
the resulting hypervisor they still can't run HVM guests (for
the hypervisor still being a dedicated PV shim one). On top of
this, the alternative approach is likely going to get ugly.
1: fix build with PV_SHIM_EXCLUSIVE and SHADOW_PAGING
2: adjust Kconfig defaults
3: don't permit HVM and PV_SHIM_EXCLUSIVE at the same time
Jan
next reply other threads:[~2020-09-14 12:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-14 12:37 Jan Beulich [this message]
2020-09-14 12:38 ` [PATCH 1/3] x86/shim: fix build with PV_SHIM_EXCLUSIVE and SHADOW_PAGING Jan Beulich
2020-09-14 16:44 ` Roger Pau Monné
2020-09-15 8:00 ` Jan Beulich
2020-09-14 12:39 ` [PATCH 2/3] x86/shim: adjust Kconfig defaults Jan Beulich
2020-09-15 10:49 ` Roger Pau Monné
2020-09-15 12:15 ` Jan Beulich
2020-09-14 12:39 ` [PATCH 3/3] x86/shim: don't permit HVM and PV_SHIM_EXCLUSIVE at the same time Jan Beulich
2020-09-15 11:02 ` Roger Pau Monné
2020-09-15 12:19 ` Jan Beulich
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-all 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=5d86a23c-5dea-8697-9ba1-900d35b99695@suse.com \
--to=jbeulich@suse.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=roger.pau@citrix.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.