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

[andre.przywara@foss.arm.com (Andre Przywara)]

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 ;-)

Cheers,
Andre.