qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 6/9] target-arm: support QMP dump-guest-memor


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v3 6/9] target-arm: support QMP dump-guest-memory
Date: Fri, 18 Dec 2015 16:31:13 +0000

On 18 December 2015 at 16:05, Andrew Jones <address@hidden> wrote:
> On Fri, Dec 18, 2015 at 11:59:39AM +0000, Peter Maydell wrote:
>> On 15 December 2015 at 22:51, Andrew Jones <address@hidden> wrote:
>> > Add the support needed for creating prstatus elf notes. This
>> > allows us to use QMP dump-guest-memory.
>> >
>> > Signed-off-by: Andrew Jones <address@hidden>
>>
>> > +int arm_cpu_write_elf64_note(WriteCoreDumpFunction f, CPUState *cs,
>> > +                             int cpuid, void *opaque)
>> > +{
>> > +    struct aarch64_note note;
>> > +    CPUARMState *env = &ARM_CPU(cs)->env;
>> > +    DumpState *s = opaque;
>> > +    uint64_t pstate, sp;
>> > +    int ret, i;
>> > +
>> > +    aarch64_note_init(&note, s, "CORE", 5, NT_PRSTATUS, 
>> > sizeof(note.prstatus));
>> > +
>> > +    note.prstatus.pr_pid = cpu_to_dump32(s, cpuid);
>> > +
>> > +    if (!is_a64(env)) {
>> > +        aarch64_sync_32_to_64(env);
>> > +        pstate = cpsr_read(env);
>> > +        sp = aarch64_compat_sp(env);
>>
>> I don't understand why we need to do this. If this is an
>> AArch64 dump then we should just treat it as an AArch64
>> dump, and presumably the consumer of the dump knows enough
>> to know what the "hypervisor view" of a CPU that's currently
>> in 32-bit mode is. It has to anyway to be able to figure
>> out where all the other registers are, so why can't it
>> also figure out what mode the CPU is currently in and thus
>> where r13 is in the xregs array?
>
> You're probably right that this shouldn't be necessary. But, in order for
> it not to be necessary, I'll need to write another crash patch. Currently,
> if you do a dump-guest-memory on a running guest, i.e. one where the kernel
> has not called panic(), and thus the cpus are actually in 32-bit usermode,
> rather than in the 64-bit cpu-stop IPI handler, then the crash utility
> segfaults if sp == xregs[31]. crash does properly decode the registers
> it digs out of the stack frame on a panic'ed cpu though, and setting sp
> to aarch64_compat_sp here also allows crash to work properly in the non-
> panic'd case.

If crash segfaults then that's clearly a bug in crash...
What is it expecting to see in the SP field?

> So, I could teach crash to do what I'm doing here in qemu instead, but
> there's still one more reason why it may make sense to do it here. That
> reason is that I don't know what else to put in prstatus.pr_reg.sp. Does
> xregs[31] make the most sense? or just zero? prstatus.pr_reg.pc is the
> correct 32-bit userspace pc, prstatus.pr_reg.pstate is the correct cpsr,
> so why not set sp to the correct userspace sp?

Well, what spec are we following here? The most logical view
to me seems to be to say "you get the view of the system
that you get from a JTAG debugger or a hypervisor", which
is to say you see a 64-bit set of registers and it's the
debugger's job to decide which bits of those might be
interesting to view as 32-bit and what is actually "live"
32 bit state.

>From that point of view there is no valid AArch64 SP register
at this point in execution (xregs[31] for QEMU would be stale
state, so not a good choice I think).

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]