Re: [PATCH 0/4] hw/s390x: Alias @dump-skeys -> @dump-s390-skey and deprecate

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Thomas Huth (thuth@xxxxxxxxxx) wrote:
> On 31/05/2024 16.02, Dr. David Alan Gilbert wrote:
> > * Thomas Huth (thuth@xxxxxxxxxx) 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???
> 
> Sounds a little bit similar, but s390 storage keys are independent from page
> tables. It's rather that each page (4096 bytes) of RAM has an additional
> 7-bit value that contains the storage key and some additional bits. It's
> also usable when page tables are still disabled.
> 
> > I'm not sure the two fit in the same command.
> 
> Does it make sense to dump all the MTE or x86 keys all at once? If so, we
> could maybe come up with an unified command. Otherwise it might not make
> sense, indeed.

So they're all really different granularities:
    s390 - one key/physical page
    ARM MTE - one tag/16 bytes physical
    x86 - per virtual page; then a current register with 16 permission
         sets

For x86 I guess it would be easy to dump the register, and then the
values for a range of virtual addresses.
But then if you dumped a range of physical addresses on ARM MTE you'd
get hundreds times more output than for the equivalent s390.

Dave

>  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   |_______/




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux