From: Claudio Imbrenda <imbrenda@linux.ibm.com>
To: Janosch Frank <frankja@linux.ibm.com>
Cc: kvm@vger.kernel.org, linux-s390@vger.kernel.org,
david@redhat.com, borntraeger@linux.ibm.com
Subject: Re: [PATCH v2 3/9] KVM: s390: pv: Add query interface
Date: Fri, 11 Mar 2022 18:40:59 +0100 [thread overview]
Message-ID: <20220311184059.25161d62@p-imbrenda> (raw)
In-Reply-To: <20220310103112.2156-4-frankja@linux.ibm.com>
On Thu, 10 Mar 2022 10:31:06 +0000
Janosch Frank <frankja@linux.ibm.com> wrote:
> Some of the query information is already available via sysfs but
> having a IOCTL makes the information easier to retrieve.
if I understand correctly, this will be forward-compatible but not
backwards compatible.
you return the amount of bytes written into the buffer, but only if the
buffer was already big enough.
a newer userspace will work with an older kernel, but an older
userspace will not work with a newer kernel.
a solution would be to return the size of the struct, so userspace can
know how much of the buffer was written (if it was bigger than the
struct), or that there are unwritten bits (if the buffer was smaller).
and even if the buffer was too small, write back as much of it as
possible to userspace.
this way, an older userspace will get the information it expects.
I am also not a big fan of writing the size in the input struct (I think
returning it would be cleaner), but I do not have a strong opinion
>
> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
> ---
> arch/s390/kvm/kvm-s390.c | 76 ++++++++++++++++++++++++++++++++++++++++
> include/uapi/linux/kvm.h | 25 +++++++++++++
> 2 files changed, 101 insertions(+)
>
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 020356653d1a..67e1e445681f 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -2224,6 +2224,42 @@ static int kvm_s390_cpus_to_pv(struct kvm *kvm, u16 *rc, u16 *rrc)
> return r;
> }
>
> +/*
> + * Here we provide user space with a direct interface to query UV
> + * related data like UV maxima and available features as well as
> + * feature specific data.
> + *
> + * To facilitate future extension of the data structures we'll try to
> + * write data up to the maximum requested length.
> + */
> +static ssize_t kvm_s390_handle_pv_info(struct kvm_s390_pv_info *info)
> +{
> + ssize_t len;
> +
> + switch (info->header.id) {
> + case KVM_PV_INFO_VM: {
> + len = sizeof(info->header) + sizeof(info->vm);
> +
> + if (info->header.len_max < len)
> + return -EINVAL;
> +
> + memcpy(info->vm.inst_calls_list,
> + uv_info.inst_calls_list,
> + sizeof(uv_info.inst_calls_list));
> +
> + /* It's max cpuidm not max cpus so it's off by one */
> + info->vm.max_cpus = uv_info.max_guest_cpu_id + 1;
> + info->vm.max_guests = uv_info.max_num_sec_conf;
> + info->vm.max_guest_addr = uv_info.max_sec_stor_addr;
> + info->vm.feature_indication = uv_info.uv_feature_indications;
> +
> + return len;
> + }
> + default:
> + return -EINVAL;
> + }
> +}
> +
> static int kvm_s390_handle_pv(struct kvm *kvm, struct kvm_pv_cmd *cmd)
> {
> int r = 0;
> @@ -2360,6 +2396,46 @@ static int kvm_s390_handle_pv(struct kvm *kvm, struct kvm_pv_cmd *cmd)
> cmd->rc, cmd->rrc);
> break;
> }
> + case KVM_PV_INFO: {
> + struct kvm_s390_pv_info info = {};
> + ssize_t data_len;
> +
> + /*
> + * No need to check the VM protection here.
> + *
> + * Maybe user space wants to query some of the data
> + * when the VM is still unprotected. If we see the
> + * need to fence a new data command we can still
> + * return an error in the info handler.
> + */
> +
> + r = -EFAULT;
> + if (copy_from_user(&info, argp, sizeof(info.header)))
> + break;
> +
> + r = -EINVAL;
> + if (info.header.len_max < sizeof(info.header))
> + break;
> +
> + data_len = kvm_s390_handle_pv_info(&info);
> + if (data_len < 0) {
> + r = data_len;
> + break;
> + }
> + /*
> + * If a data command struct is extended (multiple
> + * times) this can be used to determine how much of it
> + * is valid.
> + */
> + info.header.len_written = data_len;
> +
> + r = -EFAULT;
> + if (copy_to_user(argp, &info, data_len))
> + break;
> +
> + r = 0;
> + break;
> + }
> default:
> r = -ENOTTY;
> }
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index a02bbf8fd0f6..21f19863c417 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1643,6 +1643,30 @@ struct kvm_s390_pv_unp {
> __u64 tweak;
> };
>
> +enum pv_cmd_info_id {
> + KVM_PV_INFO_VM,
> +};
> +
> +struct kvm_s390_pv_info_vm {
> + __u64 inst_calls_list[4];
> + __u64 max_cpus;
> + __u64 max_guests;
> + __u64 max_guest_addr;
> + __u64 feature_indication;
> +};
> +
> +struct kvm_s390_pv_info_header {
> + __u32 id;
> + __u32 len_max;
> + __u32 len_written;
> + __u32 reserved;
> +};
> +
> +struct kvm_s390_pv_info {
> + struct kvm_s390_pv_info_header header;
> + struct kvm_s390_pv_info_vm vm;
> +};
> +
> enum pv_cmd_id {
> KVM_PV_ENABLE,
> KVM_PV_DISABLE,
> @@ -1651,6 +1675,7 @@ enum pv_cmd_id {
> KVM_PV_VERIFY,
> KVM_PV_PREP_RESET,
> KVM_PV_UNSHARE_ALL,
> + KVM_PV_INFO,
> };
>
> struct kvm_pv_cmd {
next prev parent reply other threads:[~2022-03-11 17:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-10 10:31 [PATCH v2 0/9] kvm: s390: Add PV dump support Janosch Frank
2022-03-10 10:31 ` [PATCH v2 1/9] s390x: Add SE hdr query information Janosch Frank
2022-03-10 10:31 ` [PATCH v2 2/9] s390: uv: Add dump fields to query Janosch Frank
2022-03-10 10:31 ` [PATCH v2 3/9] KVM: s390: pv: Add query interface Janosch Frank
2022-03-11 17:40 ` Claudio Imbrenda [this message]
2022-03-14 10:02 ` Janosch Frank
2022-03-14 10:17 ` Claudio Imbrenda
2022-03-14 10:34 ` Janosch Frank
2022-03-10 10:31 ` [PATCH v2 4/9] KVM: s390: pv: Add dump support definitions Janosch Frank
2022-03-11 17:42 ` Claudio Imbrenda
2022-03-10 10:31 ` [PATCH v2 5/9] KVM: s390: pv: Add query dump information Janosch Frank
2022-03-11 17:44 ` Claudio Imbrenda
2022-03-10 10:31 ` [PATCH v2 6/9] kvm: s390: Add configuration dump functionality Janosch Frank
2022-04-27 12:14 ` Claudio Imbrenda
2022-04-27 12:58 ` Janosch Frank
2022-03-10 10:31 ` [PATCH v2 7/9] kvm: s390: Add CPU " Janosch Frank
2022-03-10 10:31 ` [PATCH v2 8/9] Documentation: virt: Protected virtual machine dumps Janosch Frank
2022-03-10 10:31 ` [PATCH v2 9/9] Documentation/virt/kvm/api.rst: Add protvirt dump/info api descriptions Janosch Frank
2022-04-27 7:07 ` [PATCH v2 0/9] kvm: s390: Add PV dump support Janosch Frank
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=20220311184059.25161d62@p-imbrenda \
--to=imbrenda@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
/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