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. -- Crash-utility mailing list [email protected] https://www.redhat.com/mailman/listinfo/crash-utility
