qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 2/8] acpi: add vmcoreinfo device


From: Dave Anderson
Subject: Re: [Qemu-devel] [PATCH v4 2/8] acpi: add vmcoreinfo device
Date: Mon, 7 Aug 2017 11:44:29 -0400 (EDT)


----- Original Message -----
> Hi Dave
> 
> On Wed, Jul 26, 2017 at 10:21 AM, Michael S. Tsirkin <address@hidden> wrote:
> > On Sat, Jul 15, 2017 at 01:47:50AM +0200, Marc-André Lureau wrote:
> >> >
> >> > There's more info scattered in other places.
> >> >
> >> > Why do you get to document it? Because you are the one exposing it
> >> > across the hypervisor/vm boundary where it will need to be
> >> > understood by people/tools not running within guest.
> >> >
> >> > So "just read the script in qemu source" is not how an interface
> >> > should be documented.
> >>
> >> I don't understand the issue, it's a kernel ELF note that qemu passes
> >> for dump/crash tools in the dump headers/sections.
> >
> > The way it looks to me, this patchset is exposing an internal kernel
> > detail and making it part of ABI maybe it already is, my point was 1.
> > should we get a confirmation from upstream it's not going to change? 2.
> > if it's ABI let's document what do we expect to be there.
> 
> 
> Could you help explain the expectations and stability guarantees of
> vmcoreinfo ELF note ?
> 
> I am a bit stuck here, after all, vmcoreinfo is mostly used by crash
> so I thought you could help.

Sorry for the delay, I'm just back from vacation...

The vmcoreinfo string data is *primarily* used by the makedumpfile facility,
because it needs to find its way around the dumped kernel memory without having
the the vmlinux file's debuginfo data when it's running in the second kernel.

Since crash utilizes the vmlinux file, it only reads a small handful of 
the vmcoreinfo items for things like phys_base that cannot be gleaned
from the vmlinux debuginfo data.  

Anyway, I'm not sure what you mean by "expectations and stability guarantees"?
It's just a block of ASCII string data of a given size that simply needs
to be transferred to the vmcore.  New strings may be added to it at any
time, but that shouldn't have any impact on what you're doing.

Dave
 
 
> The only thing qemu does with it is try to get NUMBER(phys_base)=
> field to update the phys_base used in the various dump headers. (this
> could be dropped, and qemu ignoring the note content, if the debug
> tools take vmcoreinfo values  with higher priority than other header
> fields)
> 
> > But again since there's not a whole lot of documentation here
> > that you provided, I might be misunderstanding completely.
> 
> Because there isn't much available in the kernel either, except
> Documentation/ABI/testing/sysfs-kernel-vmcoreinfo.
> 
> 
> --
> Marc-André Lureau
> 



reply via email to

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