Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump
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.