kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heiko Carstens <hca@linux.ibm.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Claudio Imbrenda <imbrenda@linux.ibm.com>,
	Janosch Frank <frankja@linux.vnet.ibm.com>,
	David Hildenbrand <david@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	kvm@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH] KVM: s390: generate kvm hypercall functions
Date: Wed, 14 Jul 2021 13:21:50 +0200	[thread overview]
Message-ID: <YO7Izgq+WodlmMcm@osiris> (raw)
In-Reply-To: <ad7dfe27-cc38-5832-6d43-01b6014d841a@de.ibm.com>

On Wed, Jul 14, 2021 at 12:03:20PM +0200, Christian Borntraeger wrote:
> > > didn't we want to get rid of asm register allocations?
> > > this would have been a nice time to do such a cleanup
> > 
> > I see only two ways to get rid them, both are suboptimal, therefore I
> > decided to keep them at very few places; one of them this one.
> > 
> > Alternatively to this approach it would be possible to:
> > 
> > a) write the function entirely in assembler (instead of inlining it).
> 
> I would like to keep this as is, unless we know that this could break.
> Maybe we should add something like nokasan or whatever?

That would only make sense if the function would not be inlined. For
that we have e.g. __no_kasan_or_inline. But then I'd rather prefer
__always_inline. But that wouldn't solve any problems, if you see any.

From my point of view this should be safe wrt instrumentation. There
are only scalar assignments without memory accesses or anything else
the could be instrumented. If even that wouldn't work then "register
asm" would be completely useless. Even though, given all the potential
pitfalls, it is very close to being useless.

So if you want to go that route (noinstr, or whatever), then we need
those functions in a way that they can't be inlined. But keep in mind
that we also have e.g. call_on_stack() with a similar construct which
I'd like to keep inlined for performance reasons.

Let me know if you want any changes to the hypercall code.

      reply	other threads:[~2021-07-14 11:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-13 14:57 [PATCH] KVM: s390: generate kvm hypercall functions Heiko Carstens
2021-07-13 15:41 ` Christian Borntraeger
2021-07-13 15:52   ` Heiko Carstens
2021-07-13 15:59     ` Christian Borntraeger
2021-07-13 16:15       ` Heiko Carstens
2021-07-13 18:06 ` Christian Borntraeger
2021-07-14  9:38 ` Claudio Imbrenda
2021-07-14  9:50   ` Heiko Carstens
2021-07-14 10:03     ` Christian Borntraeger
2021-07-14 11:21       ` Heiko Carstens [this message]

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=YO7Izgq+WodlmMcm@osiris \
    --to=hca@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.vnet.ibm.com \
    --cc=imbrenda@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;
as well as URLs for NNTP newsgroup(s).