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

[Laszlo Ersek <lersek@redhat.com>]

On 07/28/17 16:52, Marc-André Lureau wrote:
> Hi Dave
> 
> On Wed, Jul 26, 2017 at 10:21 AM, Michael S. Tsirkin <mst@redhat.com> 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)

I agree; if "crash" guarantees that the vmcoreinfo note will override
whatever phys_base value QEMU may have guessed otherwise (from other
places) and written to some dedicated phys_base header fields, then in
QEMU we don't have to propagate phys_base from the vmcoreinfo note to
said other fields -- we can treat the vmcoreinfo note entirely opaquely.

Thanks
Laszlo

> 
>> 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.
> 
>