From mboxrd@z Thu Jan 1 00:00:00 1970 From: Segher Boessenkool Date: Tue, 18 Jun 2019 11:47:01 +0000 Subject: Re: [PATCH v3 4/9] KVM: PPC: Ultravisor: Add generic ultravisor call handler Message-Id: <20190618114701.GH7313@gate.crashing.org> List-Id: References: <20190606173614.32090-1-cclaudio@linux.ibm.com> <20190606173614.32090-5-cclaudio@linux.ibm.com> <20190617020632.yywfoqwfinjxs3pb@oak.ozlabs.ibm.com> In-Reply-To: <20190617020632.yywfoqwfinjxs3pb@oak.ozlabs.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Paul Mackerras Cc: Madhavan Srinivasan , Michael Anderson , Ram Pai , Claudio Carvalho , kvm-ppc@vger.kernel.org, Bharata B Rao , linuxppc-dev@ozlabs.org, Sukadev Bhattiprolu , Thiago Bauermann , Anshuman Khandual Hi Paul, On Mon, Jun 17, 2019 at 12:06:32PM +1000, Paul Mackerras wrote: > The thing we need to consider is that when SMFCTRL[E] = 0, a ucall > instruction becomes a hcall (that is, sc 2 is executed as if it was > sc 1). In that case, the first argument to the ucall will be > interpreted as the hcall number. Mostly that will happen not to be a > valid hcall number, but sometimes it might unavoidably be a valid but > unintended hcall number. Shouldn't a caller of the ultravisor *know* that it is talking to the ultravisor in the first place? And not to the hypervisor. Segher