[Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

[Oleg Nesterov]

On 04/26, Dave Anderson wrote:
>
> > But all the LOCAL_ACTIVE changes in 1-7 do not care about the details of "live"
> > mechanism at all. So I still think we need a generic helper which should be true
> > if local-and-active. Or, vice versa, remote-and-active, this doesn't matter.
...
> > So you suggest to change this patch to do
> >
> > 		if (ACTIVE() && !ACTIVE_QEMU() && !INSTACK(...))
> >
> > To me this simply looks worse, but I won't insist. But note that if we ever have
> > another ACTIVE_SOMETHING() source, we will need to modify this code again.  While
> > this code do not care about qemu/something at all. So I still think we need a new
> > helper which doesn't depend on qemu or whatever else.
>
> Right, but this is definitely the outlier with respect to "live" systems.

Can't understand...

> > > > Or perhaps you mean that ACTIVE_QEMU() should be defined as
> > > >
> > > > 	#define ACTIVE_QEMU()	(pc->flags2 & QEMU_LIVE)
> > > >
> > > > ? iow, it should not imply ACTIVE() ? This would be even worse, in this case we
> > > > would neet to replace almost every ACTIVE() with "ACTIVE() || ACTIVE_QEMU()".
>
> QEMU_LIVE should be in pc->flags, and appear as part of MEMORY_SOURCES.  And LIVE_SYSTEM
> should also be set so that the facility falls under both ACTIVE() and ACTIVE_QEMU().
> And then in the subset of cases where ACTIVE() is too broad, ACTIVE_QEMU() can be added
> as a restriction.

OK. But not in the case above? This particular /proc/$tc->pid doesn't need to
know if this (remote) live system is ACTIVE_QEMU() or ACTIVE_SOMETHING_ELSE() ?
All it needs to know if we debug the (live) kernel on the same machine or not.

So why we can't have a generic macro which can be used in this code and other
paths which do not care?

> But the above is not relevant with respect to some new extension of the ramdump.

Exactly. Another reason to not add the ACTIVE_QEMU() helper right now. The fact
that this remote-and-live system runs under qemu doesn't matter at all. We use
ramdump because /tmp/MEM is actually the dump of the physical memory, and if
the guest doesn't crash it is as "live" as /dev/crash is "live".

I guess I seriously misunderstand you.

> > > If it's a live system, why is necessary to specify RAM offsets?
> >
> > I suspect we will need offsets in more complex situations, qemu can have multiple
> > memory-backend-file/numa options.  And perhaps even a single file may need it,
> > not sure.
>
> But with any live system, crash reads the relevant kernel data structures and sets
> up its picture of the system's physical memory accordingly.

Yes, yes, and again /tmp/MEM I used in the previous discussion _is_ the live
memory of the guest. And in this particular case the mapping is trivial, so we
do not need the offsets.

> There's no need to specify
> where the memory lies -- it's all available in the live kernel itself.
...
> Ramdumps don't have any header information, so the
> physical memory blocks have to be specified on the crash command line

Yes, and that is why we may need OFFSET (and probably LENGTH too) in more complex
situations with memory-backend-file, but again I am not sure.

> I'm not sure because that's what I don't understand.  You seem to be describing two completely
> different facilities:
>
>   (1) a live access facility like /dev/mem, et al, but to a live KVM guest
>   (2) some kind of ramdump facility?

I tried to explain this in the previous email, not sure I was clear...

Oleg.