From: Paul Mackerras <paulus@ozlabs.org>
To: Claudio Carvalho <cclaudio@linux.ibm.com>
Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>,
Michael Anderson <andmike@linux.ibm.com>,
Ram Pai <linuxram@us.ibm.com>,
kvm-ppc@vger.kernel.org, Bharata B Rao <bharata@linux.ibm.com>,
linuxppc-dev@ozlabs.org,
Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>,
Thiago Bauermann <bauermann@linux.ibm.com>,
Anshuman Khandual <khandual@linux.vnet.ibm.com>
Subject: Re: [PATCH v3 3/9] powerpc: Introduce FW_FEATURE_ULTRAVISOR
Date: Sat, 15 Jun 2019 17:36:00 +1000 [thread overview]
Message-ID: <20190615073600.GA24709@blackberry> (raw)
In-Reply-To: <20190606173614.32090-4-cclaudio@linux.ibm.com>
On Thu, Jun 06, 2019 at 02:36:08PM -0300, Claudio Carvalho wrote:
> This feature tells if the ultravisor firmware is available to handle
> ucalls.
Everything in this patch that depends on CONFIG_PPC_UV should just
depend on CONFIG_PPC_POWERNV instead. The reason is that every host
kernel needs to be able to do the ultracall to set partition table
entry 0, in case it ends up being run on a machine with an ultravisor.
Otherwise we will have the situation where a host kernel may crash
early in boot just because the machine it's booted on happens to have
an ultravisor running. The crash will be a particularly nasty one
because it will happen before we have probed the machine type and
initialized the console; therefore it will just look like the machine
hangs for no discernable reason.
We also need to think about how to provide a way for petitboot to know
whether the kernel it is booting knows how to do a ucall to set its
partition table entry. One suggestion would be to modify
vmlinux.lds.S to add a new PT_NOTE entry in the program header of the
binary with (say) a 64-bit doubleword which is a bitmap indicating
capabilities of the binary. We would define the first bit as
indicating that the kernel knows how to run under an ultravisor.
When running under an ultravisor, petitboot could then look for the
PT_NOTE and the ultravisor-capable bit in it, and if the PT_NOTE is
not there or the bit is zero, put up a dialog warning the user that
the kernel will probably crash early in boot, and asking for explicit
confirmation that the user wants to proceed.
Paul.
next prev parent reply other threads:[~2019-06-15 7:39 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-06 17:36 [PATCH v3 0/9] kvmppc: Paravirtualize KVM to support ultravisor Claudio Carvalho
2019-06-06 17:36 ` [PATCH v3 1/9] KVM: PPC: Ultravisor: Add PPC_UV config option Claudio Carvalho
2019-06-07 20:11 ` Leonardo Bras
2019-06-10 12:18 ` Claudio Carvalho
2019-06-06 17:36 ` [PATCH v3 2/9] KVM: PPC: Ultravisor: Introduce the MSR_S bit Claudio Carvalho
2019-06-06 17:36 ` [PATCH v3 3/9] powerpc: Introduce FW_FEATURE_ULTRAVISOR Claudio Carvalho
2019-06-15 7:36 ` Paul Mackerras [this message]
2019-07-01 14:12 ` Claudio Carvalho
2019-06-06 17:36 ` [PATCH v3 4/9] KVM: PPC: Ultravisor: Add generic ultravisor call handler Claudio Carvalho
2019-06-15 7:37 ` Paul Mackerras
2019-06-17 2:06 ` Paul Mackerras
2019-06-17 23:51 ` Ram Pai
2019-06-18 11:47 ` Segher Boessenkool
2019-06-18 15:25 ` Ram Pai
2019-06-06 17:36 ` [PATCH v3 5/9] KVM: PPC: Ultravisor: Use UV_WRITE_PATE ucall to register a PATE Claudio Carvalho
2019-06-15 7:38 ` Paul Mackerras
2019-06-06 17:36 ` [PATCH v3 6/9] KVM: PPC: Ultravisor: Restrict flush of the partition tlb cache Claudio Carvalho
2019-06-06 19:39 ` Murilo Opsfelder Araújo
2019-06-06 21:55 ` Paul Mackerras
2019-06-06 17:36 ` [PATCH v3 7/9] KVM: PPC: Ultravisor: Restrict LDBAR access Claudio Carvalho
2019-06-07 4:48 ` Madhavan Srinivasan
2019-06-07 12:34 ` Claudio Carvalho
2019-06-15 7:43 ` Paul Mackerras
2019-06-16 1:10 ` Ram Pai
2019-06-06 17:36 ` [PATCH v3 8/9] KVM: PPC: Ultravisor: Enter a secure guest Claudio Carvalho
2019-06-15 7:45 ` Paul Mackerras
2019-06-06 17:36 ` [PATCH v3 9/9] KVM: PPC: Ultravisor: Check for MSR_S during hv_reset_msr Claudio Carvalho
2019-06-15 7:47 ` Paul Mackerras
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=20190615073600.GA24709@blackberry \
--to=paulus@ozlabs.org \
--cc=andmike@linux.ibm.com \
--cc=bauermann@linux.ibm.com \
--cc=bharata@linux.ibm.com \
--cc=cclaudio@linux.ibm.com \
--cc=khandual@linux.vnet.ibm.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=linuxram@us.ibm.com \
--cc=maddy@linux.vnet.ibm.com \
--cc=sukadev@linux.vnet.ibm.com \
/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;
as well as URLs for NNTP newsgroup(s).