From: Eric Farman <firstname.lastname@example.org> To: Christian Borntraeger <email@example.com>, Janosch Frank <firstname.lastname@example.org>, David Hildenbrand <email@example.com>, Claudio Imbrenda <firstname.lastname@example.org>, Thomas Huth <email@example.com> Cc: Heiko Carstens <firstname.lastname@example.org>, Vasily Gorbik <email@example.com>, firstname.lastname@example.org, email@example.com, Eric Farman <firstname.lastname@example.org> Subject: [RFC PATCH v4 0/2] s390x: Improvements to SIGP handling [KVM] Date: Fri, 19 Nov 2021 22:37:05 +0100 [thread overview] Message-ID: <email@example.com> (raw) Here is an update to the handling of SIGP between kernel and userspace. As before, I'm looking at problems encountered when a SIGP order that is processed in the kernel (for example, SIGP SENSE) is run concurrently with another one is processed in userspace (for example, SIGP STOP). Being able to provide an honest answer in the SIGP SENSE as to whether the targeted VCPU is/not stopped is important to provide a consistent answer while a guest OS is bringing its configuration online. Furthermore, there is a desire to be architecturally correct in this space, where the Principles of Operation states lists of orders that should return a CC2 (BUSY) when any of another list of orders is being processed on the targeted CPU. This version goes back to something similar to v2, in that there's only a single IOCTL created. But unlike v2, userspace handles both the "set" and "reset" sides of the equation, specifying the operations in the payload sent via the IOCTL. With this, I started considering that the kernel itself could mark the cpu busy/ready as it relates to SIGP, such that a !USER_SIGP userspace would be happy with matters too, but haven't quite gotten that working to my liking. I'll send the QEMU series shortly, which takes advantage of this. Thoughts? Previous RFCs: v1: https://firstname.lastname@example.org/ v2: https://email@example.com/ v3: https://firstname.lastname@example.org/ Eric Farman (2): Capability/IOCTL/Documentation KVM: s390: Introduce a USER_BUSY capability and IOCTL Documentation/virt/kvm/api.rst | 22 ++++++++++++++++++ arch/s390/include/asm/kvm_host.h | 2 ++ arch/s390/kvm/kvm-s390.c | 40 ++++++++++++++++++++++++++++++++ arch/s390/kvm/kvm-s390.h | 15 ++++++++++++ arch/s390/kvm/sigp.c | 3 +++ include/uapi/linux/kvm.h | 16 +++++++++++++ 6 files changed, 98 insertions(+) -- 2.25.1
next reply other threads:[~2021-11-19 21:37 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-19 21:37 Eric Farman [this message] 2021-11-19 21:37 ` [RFC PATCH v4 1/2] Capability/IOCTL/Documentation Eric Farman 2021-11-19 21:37 ` [RFC PATCH v4 2/2] KVM: s390: Introduce a USER_BUSY capability and IOCTL Eric Farman
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [RFC PATCH v4 0/2] s390x: Improvements to SIGP handling [KVM]' \ /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
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.