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: Marc-André Lureau
Subject: Re: [Qemu-devel] [PATCH v4 2/8] acpi: add vmcoreinfo device
Date: Fri, 28 Jul 2017 07:52:17 -0700

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.

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]