All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dave@treblig.org>
To: Thomas Huth <thuth@redhat.com>
Cc: "Philippe Mathieu-Daudé" <philmd@linaro.org>,
	qemu-devel@nongnu.org, "Cornelia Huck" <cohuck@redhat.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	qemu-s390x@nongnu.org, devel@lists.libvirt.org,
	"Eric Farman" <farman@linux.ibm.com>,
	"Ilya Leoshkevich" <iii@linux.ibm.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Eric Blake" <eblake@redhat.com>,
	"Halil Pasic" <pasic@linux.ibm.com>,
	"Anton Johansson" <anjo@rev.ng>, qemu-arm <qemu-arm@nongnu.org>
Subject: Re: [PATCH 0/4] hw/s390x: Alias @dump-skeys -> @dump-s390-skey and deprecate
Date: Fri, 31 May 2024 14:02:58 +0000	[thread overview]
Message-ID: <ZlnYkt9sLgDbQqVT@gallifrey> (raw)
In-Reply-To: <cb4028fc-9596-47f3-9468-f8912dd48aed@redhat.com>

* Thomas Huth (thuth@redhat.com) wrote:
> On 30/05/2024 09.45, Philippe Mathieu-Daudé wrote:
> > We are trying to unify all qemu-system-FOO to a single binary.
> > In order to do that we need to remove QAPI target specific code.
> > 
> > @dump-skeys is only available on qemu-system-s390x. This series
> > rename it as @dump-s390-skey, making it available on other
> > binaries. We take care of backward compatibility via deprecation.
> > 
> > Philippe Mathieu-Daudé (4):
> >    hw/s390x: Introduce the @dump-s390-skeys QMP command
> >    hw/s390x: Introduce the 'dump_s390_skeys' HMP command
> >    hw/s390x: Deprecate the HMP 'dump_skeys' command
> >    hw/s390x: Deprecate the QMP @dump-skeys command
> 
> Why do we have to rename the command? Just for the sake of it? I think
> renaming HMP commands is maybe ok, but breaking the API in QMP is something
> you should consider twice.
> 
> And even if we decide to rename ... maybe we should discuss whether it makes
> sense to come up with a generic command instead: As far as I know, ARM also
> has something similar, called MTE. Maybe we also want to dump MTE keys one
> day? So the new command should maybe be called "dump-memory-keys" instead?

I think there are at least two different concepts; but I agree it would be
nice to keep a single command for matching concepts across different architectures;
I can't say I know the details of any, but:

  a) Page table things - I think x86 PKRU/PKEY (???) is a page table thing
    where pages marked a special way are associated with keys.
    That sounds similar to what the skeys are???

  b) Upper bit things - where you steal a few bits from the virtual address
    and then use that to associate some security; I think that's closer
    to what MTE is isn't it?

I'm not sure the two fit in the same command.

Dave

> Or should it maybe rather be an option to the existing "dump-guest-memory"
> command instead?
> 
>  Thomas
> 
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

  reply	other threads:[~2024-05-31 14:03 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-30  7:45 [PATCH 0/4] hw/s390x: Alias @dump-skeys -> @dump-s390-skey and deprecate Philippe Mathieu-Daudé
2024-05-30  7:45 ` [PATCH 1/4] hw/s390x: Introduce the @dump-s390-skeys QMP command Philippe Mathieu-Daudé
2024-05-30  7:45 ` [PATCH 2/4] hw/s390x: Introduce the 'dump_s390_skeys' HMP command Philippe Mathieu-Daudé
2024-05-30  7:45 ` [PATCH 3/4] hw/s390x: Deprecate the HMP 'dump_skeys' command Philippe Mathieu-Daudé
2024-05-30  7:45 ` [PATCH 4/4] hw/s390x: Deprecate the QMP @dump-skeys command Philippe Mathieu-Daudé
2024-05-31  4:49   ` Thomas Huth
2024-05-30  8:58 ` [PATCH 0/4] hw/s390x: Alias @dump-skeys -> @dump-s390-skey and deprecate Anton Johansson via
2024-05-31  4:47 ` Thomas Huth
2024-05-31 14:02   ` Dr. David Alan Gilbert [this message]
2024-05-31 16:23     ` Thomas Huth
2024-06-03 17:06       ` Dr. David Alan Gilbert
2024-06-03 12:18   ` Daniel P. Berrangé
2024-06-03 20:54     ` Dr. David Alan Gilbert
2024-06-04  4:58       ` Markus Armbruster
2024-06-04  9:45         ` Philippe Mathieu-Daudé
2024-06-04  9:59           ` Daniel P. Berrangé
2024-06-04 10:00           ` Markus Armbruster
2024-06-05 11:44             ` Dr. David Alan Gilbert
2024-06-10  5:20               ` Markus Armbruster
2024-06-27 16:46                 ` Dr. David Alan Gilbert
2025-03-09 18:55     ` Pierrick Bouvier
2025-03-10  6:50       ` Thomas Huth
2025-03-10  9:11         ` Daniel P. Berrangé
2025-03-10 12:30         ` Dr. David Alan Gilbert
2025-03-09 18:44 ` Philippe Mathieu-Daudé

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=ZlnYkt9sLgDbQqVT@gallifrey \
    --to=dave@treblig.org \
    --cc=alex.bennee@linaro.org \
    --cc=anjo@rev.ng \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=devel@lists.libvirt.org \
    --cc=eblake@redhat.com \
    --cc=farman@linux.ibm.com \
    --cc=iii@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=philmd@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=thuth@redhat.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 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.