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 Jung Bauermann <bauerman@linux.ibm.com>,
Anshuman Khandual <khandual@linux.vnet.ibm.com>
Subject: Re: [RFC PATCH v2 08/10] KVM: PPC: Ultravisor: Return to UV for hcalls from SVM
Date: Mon, 20 May 2019 06:17:00 +0000 [thread overview]
Message-ID: <20190520061700.GC21382@blackberry> (raw)
In-Reply-To: <20190518142524.28528-9-cclaudio@linux.ibm.com>
On Sat, May 18, 2019 at 11:25:22AM -0300, Claudio Carvalho wrote:
> From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
>
> All hcalls from a secure VM go to the ultravisor from where they are
> reflected into the HV. When we (HV) complete processing such hcalls,
> we should return to the UV rather than to the guest kernel.
This paragraph in the patch description, and the comment in
book3s_hv_rmhandlers.S, are confusing and possibly misleading in
focussing on returns from hcalls, when the change is needed for any
sort of entry to the guest from the hypervisor, whether it is a return
from an hcall, a return from a hypervisor interrupt, or the first time
that a guest vCPU is run.
This paragraph needs to explain that to enter a secure guest, we have
to go through the ultravisor, therefore we do a ucall when we are
entering a secure guest.
[snip]
> +/*
> + * The hcall we just completed was from Ultravisor. Use UV_RETURN
> + * ultra call to return to the Ultravisor. Results from the hcall
> + * are already in the appropriate registers (r3:12), except for
> + * R6,7 which we used as temporary registers above. Restore them,
> + * and set R0 to the ucall number (UV_RETURN).
> + */
This needs to say something like "We are entering a secure guest, so
we have to invoke the ultravisor to do that. If we are returning from
a hcall, the results are already ...".
> +ret_to_ultra:
> + lwz r6, VCPU_CR(r4)
> + mtcr r6
> + LOAD_REG_IMMEDIATE(r0, UV_RETURN)
> + ld r7, VCPU_GPR(R7)(r4)
> + ld r6, VCPU_GPR(R6)(r4)
> + ld r4, VCPU_GPR(R4)(r4)
> + sc 2
>
> /*
> * Enter the guest on a P9 or later system where we have exactly
> --
> 2.20.1
Paul.
WARNING: multiple messages have this Message-ID (diff)
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 Jung Bauermann <bauerman@linux.ibm.com>,
Anshuman Khandual <khandual@linux.vnet.ibm.com>
Subject: Re: [RFC PATCH v2 08/10] KVM: PPC: Ultravisor: Return to UV for hcalls from SVM
Date: Mon, 20 May 2019 16:17:00 +1000 [thread overview]
Message-ID: <20190520061700.GC21382@blackberry> (raw)
In-Reply-To: <20190518142524.28528-9-cclaudio@linux.ibm.com>
On Sat, May 18, 2019 at 11:25:22AM -0300, Claudio Carvalho wrote:
> From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
>
> All hcalls from a secure VM go to the ultravisor from where they are
> reflected into the HV. When we (HV) complete processing such hcalls,
> we should return to the UV rather than to the guest kernel.
This paragraph in the patch description, and the comment in
book3s_hv_rmhandlers.S, are confusing and possibly misleading in
focussing on returns from hcalls, when the change is needed for any
sort of entry to the guest from the hypervisor, whether it is a return
from an hcall, a return from a hypervisor interrupt, or the first time
that a guest vCPU is run.
This paragraph needs to explain that to enter a secure guest, we have
to go through the ultravisor, therefore we do a ucall when we are
entering a secure guest.
[snip]
> +/*
> + * The hcall we just completed was from Ultravisor. Use UV_RETURN
> + * ultra call to return to the Ultravisor. Results from the hcall
> + * are already in the appropriate registers (r3:12), except for
> + * R6,7 which we used as temporary registers above. Restore them,
> + * and set R0 to the ucall number (UV_RETURN).
> + */
This needs to say something like "We are entering a secure guest, so
we have to invoke the ultravisor to do that. If we are returning from
a hcall, the results are already ...".
> +ret_to_ultra:
> + lwz r6, VCPU_CR(r4)
> + mtcr r6
> + LOAD_REG_IMMEDIATE(r0, UV_RETURN)
> + ld r7, VCPU_GPR(R7)(r4)
> + ld r6, VCPU_GPR(R6)(r4)
> + ld r4, VCPU_GPR(R4)(r4)
> + sc 2
>
> /*
> * Enter the guest on a P9 or later system where we have exactly
> --
> 2.20.1
Paul.
next prev parent reply other threads:[~2019-05-20 6:17 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-18 14:25 [RFC PATCH v2 00/10] kvmppc: Paravirtualize KVM to support ultravisor Claudio Carvalho
2019-05-18 14:25 ` Claudio Carvalho
2019-05-18 14:25 ` [RFC PATCH v2 01/10] KVM: PPC: Ultravisor: Add PPC_UV config option Claudio Carvalho
2019-05-18 14:25 ` Claudio Carvalho
2019-05-18 14:25 ` [RFC PATCH v2 02/10] KVM: PPC: Ultravisor: Introduce the MSR_S bit Claudio Carvalho
2019-05-18 14:25 ` Claudio Carvalho
2019-05-18 14:25 ` [RFC PATCH v2 03/10] powerpc: Introduce FW_FEATURE_ULTRAVISOR Claudio Carvalho
2019-05-18 14:25 ` Claudio Carvalho
2019-05-18 14:25 ` [RFC PATCH v2 04/10] KVM: PPC: Ultravisor: Add generic ultravisor call handler Claudio Carvalho
2019-05-18 14:25 ` Claudio Carvalho
2019-05-18 14:25 ` [RFC PATCH v2 05/10] KVM: PPC: Ultravisor: Use UV_WRITE_PATE ucall to register a PATE Claudio Carvalho
2019-05-18 14:25 ` Claudio Carvalho
2019-05-18 14:25 ` [RFC PATCH v2 06/10] KVM: PPC: Ultravisor: Restrict flush of the partition tlb cache Claudio Carvalho
2019-05-18 14:25 ` Claudio Carvalho
2019-05-18 14:25 ` [RFC PATCH v2 07/10] KVM: PPC: Ultravisor: Restrict LDBAR access Claudio Carvalho
2019-05-18 14:25 ` Claudio Carvalho
2019-05-20 5:43 ` Paul Mackerras
2019-05-20 5:43 ` Paul Mackerras
2019-05-21 5:24 ` Madhavan Srinivasan
2019-05-30 22:51 ` Claudio Carvalho
2019-05-18 14:25 ` [RFC PATCH v2 08/10] KVM: PPC: Ultravisor: Return to UV for hcalls from SVM Claudio Carvalho
2019-05-18 14:25 ` Claudio Carvalho
2019-05-20 6:17 ` Paul Mackerras [this message]
2019-05-20 6:17 ` Paul Mackerras
2019-05-18 14:25 ` [RFC PATCH v2 09/10] KVM: PPC: Book3S HV: Fixed for running secure guests Claudio Carvalho
2019-05-18 14:25 ` Claudio Carvalho
2019-05-20 6:40 ` Paul Mackerras
2019-05-20 6:40 ` Paul Mackerras
2019-05-18 14:25 ` [RFC PATCH v2 10/10] KVM: PPC: Ultravisor: Check for MSR_S during hv_reset_msr Claudio Carvalho
2019-05-18 14:25 ` Claudio Carvalho
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=20190520061700.GC21382@blackberry \
--to=paulus@ozlabs.org \
--cc=andmike@linux.ibm.com \
--cc=bauerman@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 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.