All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Farman <farman@linux.ibm.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	David Hildenbrand <david@redhat.com>,
	Claudio Imbrenda <imbrenda@linux.ibm.com>,
	Thomas Huth <thuth@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	kvm@vger.kernel.org, linux-s390@vger.kernel.org,
	Eric Farman <farman@linux.ibm.com>
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: <20211119213707.2363945-1-farman@linux.ibm.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://lore.kernel.org/r/20211008203112.1979843-1-farman@linux.ibm.com/
v2: https://lore.kernel.org/r/20211102194652.2685098-1-farman@linux.ibm.com/
v3: https://lore.kernel.org/r/20211110203322.1374925-1-farman@linux.ibm.com/

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


             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 \
    --in-reply-to=20211119213707.2363945-1-farman@linux.ibm.com \
    --to=farman@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=thuth@redhat.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.