From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ram Pai Date: Tue, 18 Jun 2019 15:25:35 +0000 Subject: Re: Re: [PATCH v3 4/9] KVM: PPC: Ultravisor: Add generic ultravisor call handler Message-Id: <20190618152535.GD10806@ram.ibm.com> List-Id: References: <20190606173614.32090-1-cclaudio@linux.ibm.com> <20190606173614.32090-5-cclaudio@linux.ibm.com> <20190617020632.yywfoqwfinjxs3pb@oak.ozlabs.ibm.com> <20190618114701.GH7313@gate.crashing.org> In-Reply-To: <20190618114701.GH7313@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Segher Boessenkool Cc: Madhavan Srinivasan , Michael Anderson , Claudio Carvalho , kvm-ppc@vger.kernel.org, Bharata B Rao , linuxppc-dev@ozlabs.org, Sukadev Bhattiprolu , Thiago Bauermann , Anshuman Khandual On Tue, Jun 18, 2019 at 06:47:01AM -0500, Segher Boessenkool wrote: > 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. It may or may not. But if it knows and still decides to make the ucall, the hypervisor must gracefully handle it. We can't control who makes a ucall. A normal process within the VM could make a ucall too. Or a normal process running on top of the hypervisor could make a ucall. RP