Re: [PATCH v3 2/2] proc: add /proc/<pid>/arch_state

[Palmer Dabbelt]

On Wed, 21 Nov 2018 01:53:50 PST (-0800), peterz@xxxxxxxxxxxxx wrote:
> On Wed, Nov 21, 2018 at 09:19:36AM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 21, 2018 at 09:39:00AM +0800, Li, Aubrey wrote:
> > > > Also; you were going to shop around with the other architectures to see
> > > > what they want/need for this interface. I see nothing on that.
> > > >
> > > I'm open for your suggestion, :)
> >
> > Well, we have linux-arch and the various maintainers are also listed in
> > MAINTAINERS. Go forth and ask..
>
> Ok, so I googled a wee bit (you could have too).
>
> There's not that many architectures that build big hot chips
> (powerpc,x86,arm64,s390) (mips, sparc64 and ia64 are pretty dead I
> think, although the Fujitsu Sparc M10 X+/X SIMD looked like it could be
> 'fun').
>
> Of those, powerpc altivec doesn't seem to be very wide, but you'd have
> to ask the power folks. Same for s390 z13.
>
> The Fujitsu/ARM64-SVE stuff looks like it can be big and hot.
>
> And RISC-V has was vector extention, but I don't think anybody is
> actually building big hot versions of that just yet.

We don't actually have a vector extension yet, but there's supposed to be a 
draft out in 2 weeks.  The plan is that this draft will be sufficiently 
long-lived that we can start software implementation work.  While I don't 
believe it's intended that hardware implementations become available using 
this draft specification, these things tend to take a life of their own.  I'd 
be pretty surprised if we don't end up seeing hardware implementations of this 
draft specification.

I don't know if they'll be big and hot, though -- the whole point of the vector 
extension is that we can build chips that aren't that big or hot :)

On a more serious note, in RISC-V land we've attempted to make mcontext 
extensible and plan on shimming all the additional architectural state into 
there.  Thus, I don't think this interface is particularly useful for us.

I also don't like this "file full of 1s and 0s" interface, but it's certainly 
not my place to shoot it down.  In RISC-V land we're trying very hard to 
carefully examine any user-visible ABI to ensure it's something we're willing 
to keep around for ever, and this doesn't seem like something that fits that 
mold.