[PATCH] KVM: arm/arm64: vgic: Add debugfs vgic-state file

[Christoffer Dall]

On Tue, Jan 24, 2017 at 12:35:43PM +0000, Andre Przywara wrote:
> Hi,
> 
> [...]
> 
> >>>>
> >>>> As I didn't understand the seq_* semantics in the first place, I didn't
> >>>> have a look yet what could cause this.
> >>>
> >>> Nice catch, I'll have a look at this.
> >>>
> >>> Just so I'm sure, these are two processes reading the vgic-state file
> >>> for the same single VM, right?
> >>
> >> Yes, just one VM. I was about to write a small test program which is a
> >> bit more nasty and launches <n> threads all doing lseek();read(); on the
> >> same file in a loop, but it turned out that this isn't necessary ;-)
> >> I have that now working, so I can give this a test later.
> >>
> >> I was wondering if you could ditch that lseek / offset setting feature
> >> at all? The smaller debugfs files don't support it as well (ESPIPE on
> >> lseek()). Is that an option when setting up the seq interface?
> >>
> > 
> > I think that only works if you're guaranteed to always only print within
> > the buffer allocated for a single read, but if you run out of buffer
> > space the seq_file code will allocate more space, do the fast forward
> > thing, and continue reading where it left off.  I feel like when we're
> > enumaring over 1000 irqs and could be spitting out a bunch of LPI data
> > later on, this is a bit fragile.
> > The recommendations also state you should only do this if you don't need
> > a lot of locking or printing small data amounts, but I'm not enough of
> > an expert on the seq file to know exactly when that applies and when it
> > doesn't, but it doesn't feel like this fits within that bracket.
> 
> Thanks for the explanation, and this indeed makes some sense.
> I just wanted to save you some nasty debugging, instead tricking you
> into just papering over the issue ;-)
> 
Indeed, I'm all for that if it works :)

Thanks,
-Christoffer