From: Paolo Bonzini <pbonzini@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>,
KVM <kvm@vger.kernel.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
Alexander Graf <agraf@suse.de>,
Cornelia Huck <cornelia.huck@de.ibm.com>,
Jens Freimann <jfrei@linux.vnet.ibm.com>,
Ekaterina Tumanova <tumanova@linux.vnet.ibm.com>
Subject: Re: [PATCH/RFC 5/9] KVM: s390: introduce post handlers for STSI
Date: Mon, 16 Mar 2015 12:55:48 +0100 [thread overview]
Message-ID: <5506C4C4.3050507@redhat.com> (raw)
In-Reply-To: <1426495905-17531-6-git-send-email-borntraeger@de.ibm.com>
On 16/03/2015 09:51, Christian Borntraeger wrote:
> From: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com>
>
> The Store System Information (STSI) instruction currently collects all
> information it relays to the caller in the kernel. Some information,
> however, is only available in user space. An example of this is the
> guest name: The kernel always sets "KVMGuest", but user space knows the
> actual guest name.
>
> This patch introduces a new exit, KVM_EXIT_S390_STSI, guarded by a
> capability that can be enabled by user space if it wants to be able to
> insert such data. User space will be provided with the target buffer
> and the requested STSI function code.
>
> Reviewed-by: Eric Farman <farman@linux.vnet.ibm.com>
> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Signed-off-by: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
> Documentation/virtual/kvm/api.txt | 28 ++++++++++++++++++++++++++++
> arch/s390/include/asm/kvm_host.h | 1 +
> arch/s390/kvm/kvm-s390.c | 5 +++++
> arch/s390/kvm/priv.c | 16 +++++++++++++++-
> include/uapi/linux/kvm.h | 11 +++++++++++
> 5 files changed, 60 insertions(+), 1 deletion(-)
This is okay, but it made me curious about s390 specifics because it's
different from the x86 equivalent. The x86 info is always 16-byte (4
times 32 bit) and the selectors are few (roughly 30), and it is passed
to the kernel at init time via KVM_SET_CPUID2. How many selectors are
there on s390, and how big is the info that can be written?
Paolo
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index f03178d..74d18b6 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -3304,3 +3304,31 @@ Returns: 0 on success, negative value on error
> Allows use of the vector registers introduced with z13 processor, and
> provides for the synchronization between host and user space. Will
> return -EINVAL if the machine does not support vectors.
> +
> +7.4 KVM_CAP_S390_USER_STSI
> +
> +Architectures: s390
> +Parameters: none
> +
> +This capability allows post-handlers for the STSI instruction. After
> +initial handling in the kernel, KVM exits to user space with
> +KVM_EXIT_S390_STSI to allow user space to insert further data.
> +
> +Before exiting to userspace, kvm handlers should fill in s390_stsi field of
> +vcpu->run:
> +struct {
> + __u64 addr;
> + __u8 ar;
> + __u8 reserved;
> + __u8 fc;
> + __u8 sel1;
> + __u16 sel2;
> +} s390_stsi;
> +
> +@addr - guest address of STSI SYSIB
> +@fc - function code
> +@sel1 - selector 1
> +@sel2 - selector 2
> +@ar - access register number
> +
> +KVM handlers should exit to userspace with rc = -EREMOTE.
> diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
> index 347a333..2356a8c 100644
> --- a/arch/s390/include/asm/kvm_host.h
> +++ b/arch/s390/include/asm/kvm_host.h
> @@ -565,6 +565,7 @@ struct kvm_arch{
> int use_vectors;
> int user_cpu_state_ctrl;
> int user_sigp;
> + int user_stsi;
> struct s390_io_adapter *adapters[MAX_S390_IO_ADAPTERS];
> wait_queue_head_t ipte_wq;
> int ipte_lock_count;
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 92855e2..1f5baf4 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -178,6 +178,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> case KVM_CAP_VM_ATTRIBUTES:
> case KVM_CAP_MP_STATE:
> case KVM_CAP_S390_USER_SIGP:
> + case KVM_CAP_S390_USER_STSI:
> r = 1;
> break;
> case KVM_CAP_S390_MEM_OP:
> @@ -280,6 +281,10 @@ static int kvm_vm_ioctl_enable_cap(struct kvm *kvm, struct kvm_enable_cap *cap)
> kvm->arch.use_vectors = MACHINE_HAS_VX;
> r = MACHINE_HAS_VX ? 0 : -EINVAL;
> break;
> + case KVM_CAP_S390_USER_STSI:
> + kvm->arch.user_stsi = 1;
> + r = 0;
> + break;
> default:
> r = -EINVAL;
> break;
> diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c
> index 5f26425..211102c 100644
> --- a/arch/s390/kvm/priv.c
> +++ b/arch/s390/kvm/priv.c
> @@ -488,6 +488,16 @@ static void handle_stsi_3_2_2(struct kvm_vcpu *vcpu, struct sysinfo_3_2_2 *mem)
> ASCEBC(mem->vm[0].cpi, 16);
> }
>
> +static void insert_stsi_usr_data(struct kvm_vcpu *vcpu, u64 addr, u8 fc,
> + u8 sel1, u16 sel2)
> +{
> + vcpu->run->exit_reason = KVM_EXIT_S390_STSI;
> + vcpu->run->s390_stsi.addr = addr;
> + vcpu->run->s390_stsi.fc = fc;
> + vcpu->run->s390_stsi.sel1 = sel1;
> + vcpu->run->s390_stsi.sel2 = sel2;
> +}
> +
> static int handle_stsi(struct kvm_vcpu *vcpu)
> {
> int fc = (vcpu->run->s.regs.gprs[0] & 0xf0000000) >> 28;
> @@ -547,11 +557,15 @@ static int handle_stsi(struct kvm_vcpu *vcpu)
> rc = kvm_s390_inject_prog_cond(vcpu, rc);
> goto out;
> }
> + if (vcpu->kvm->arch.user_stsi) {
> + insert_stsi_usr_data(vcpu, operand2, fc, sel1, sel2);
> + rc = -EREMOTE;
> + }
> trace_kvm_s390_handle_stsi(vcpu, fc, sel1, sel2, operand2);
> free_page(mem);
> kvm_s390_set_psw_cc(vcpu, 0);
> vcpu->run->s.regs.gprs[0] = 0;
> - return 0;
> + return rc;
> out_no_data:
> kvm_s390_set_psw_cc(vcpu, 3);
> out:
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 74bbd9a..279ffd2 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -172,6 +172,7 @@ struct kvm_pit_config {
> #define KVM_EXIT_S390_TSCH 22
> #define KVM_EXIT_EPR 23
> #define KVM_EXIT_SYSTEM_EVENT 24
> +#define KVM_EXIT_S390_STSI 25
>
> /* For KVM_EXIT_INTERNAL_ERROR */
> /* Emulate instruction failed. */
> @@ -309,6 +310,15 @@ struct kvm_run {
> __u32 type;
> __u64 flags;
> } system_event;
> + /* KVM_EXIT_S390_STSI */
> + struct {
> + __u64 addr;
> + __u8 ar;
> + __u8 reserved;
> + __u8 fc;
> + __u8 sel1;
> + __u16 sel2;
> + } s390_stsi;
> /* Fix the size of the union. */
> char padding[256];
> };
> @@ -780,6 +790,7 @@ struct kvm_ppc_smmu_info {
> #define KVM_CAP_S390_USER_SIGP 106
> #define KVM_CAP_S390_VECTOR_REGISTERS 107
> #define KVM_CAP_S390_MEM_OP 108
> +#define KVM_CAP_S390_USER_STSI 109
>
> #ifdef KVM_CAP_IRQ_ROUTING
>
>
next prev parent reply other threads:[~2015-03-16 12:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-16 8:51 [PATCH/RFC 0/9] Next bunch of KVM/s390x changes for next Christian Borntraeger
2015-03-16 8:51 ` [PATCH/RFC 1/9] KVM: s390: Spelling s/intance/instance/ Christian Borntraeger
2015-03-16 8:51 ` [PATCH/RFC 2/9] KVM: s390: cleanup jump lables in kvm_arch_init_vm Christian Borntraeger
2015-03-16 12:43 ` Cornelia Huck
2015-03-16 8:51 ` [PATCH/RFC 3/9] KVM: s390: Fix low-address protection for real addresses Christian Borntraeger
2015-03-16 12:48 ` Cornelia Huck
2015-03-16 8:51 ` [PATCH/RFC 4/9] KVM: s390: Add MEMOP ioctls for reading/writing guest memory Christian Borntraeger
2015-03-16 12:16 ` Cornelia Huck
2015-03-16 12:23 ` Christian Borntraeger
2015-03-19 0:23 ` Marcelo Tosatti
2015-03-16 8:51 ` [PATCH/RFC 5/9] KVM: s390: introduce post handlers for STSI Christian Borntraeger
2015-03-16 11:55 ` Paolo Bonzini [this message]
2015-03-16 12:18 ` Christian Borntraeger
2015-03-16 12:22 ` Paolo Bonzini
2015-03-16 8:51 ` [PATCH/RFC 6/9] KVM: s390: Guest's memory access functions get access registers Christian Borntraeger
2015-03-16 13:12 ` Cornelia Huck
2015-03-16 8:51 ` [PATCH/RFC 7/9] KVM: s390: Optimize paths where get_vcpu_asce() is invoked Christian Borntraeger
2015-03-16 13:13 ` Cornelia Huck
2015-03-16 8:51 ` [PATCH/RFC 8/9] KVM: s390: Add access register mode Christian Borntraeger
2015-03-16 8:51 ` [PATCH/RFC 9/9] KVM: s390: Create ioctl for Getting/Setting guest storage keys Christian Borntraeger
2015-03-16 13:07 ` Cornelia Huck
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=5506C4C4.3050507@redhat.com \
--to=pbonzini@redhat.com \
--cc=agraf@suse.de \
--cc=borntraeger@de.ibm.com \
--cc=cornelia.huck@de.ibm.com \
--cc=jfrei@linux.vnet.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=tumanova@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).