Re: [Qemu-devel] [PATCH] RFC: vmcoreinfo device

[Ladi Prosek]

On Fri, Apr 28, 2017 at 4:28 PM, Marc-André Lureau
<address@hidden> wrote:
> Hi
>
> On Fri, Apr 28, 2017 at 6:12 PM Ladi Prosek <address@hidden> wrote:
>>
>> On Mon, Apr 24, 2017 at 3:03 PM, Marc-André Lureau
>> <address@hidden> wrote:
>> > The VM coreinfo (vmcoreinfo) device is an emulated device which
>> > exposes a 4k memory range to the guest to store various informations
>> > useful to debug the guest OS. (it is greatly inspired by the VMGENID
>> > device implementation)
>> >
>> > This is an early-boot alternative to the qemu-ga VMDUMP_INFO event
>> > proposed in "[PATCH 00/21] WIP: dump: add kaslr support".
>> >
>> > If deemed more appropriate, we can consider writing to fw_cfg directly
>> > instead of guest memory, now that qemu 2.9 supports it again.
>> >
>> > The proof-of-concept kernel module:
>> > https://github.com/elmarco/vmgenid-test/blob/master/qemuvmci-test.c
>>
>> Here's a proof-of-concept Windows driver:
>>
>> https://github.com/ladipro/kvm-guest-drivers-windows/tree/vmcoreinfo/vmcoreinfo
>>
>> I just wanted to be sure that it's possible to evaluate the ADDR
>> method in Windows.
>>
>> From a practical point of view it is unfortunate that this would be a
>> completely new device. For Windows guests it means another driver
>> binary and all the overhead associated with deploying it on VMs. Would
>> it be too crazy to add this functionality to the pvpanic device? The
>> mechanics could stay the same but it would be done under the existing
>> ACPI\QEMU0001 device.
>
>
> pvpanic is under _SB.PCI0.ISA, that could be problematic
>
> and _STA is a name field.
>
> Someone with more experience with ACPI could tell us if that make sense to
> merge both and how.
>
> Can't you handle 2 ACPI devices in the same windows driver instead?

It can be done but it's uncommon for one driver to drive two different
devices so it would probably be confusing.

>> > +Storage Format:
>> > +---------------
>> > +
>> > +The content is expected to use little-endian format.
>> > +
>> > +In order to implement an OVMF "SDT Header Probe Suppressor", the
>> > contents of
>> > +the vmcoreinfo blob has 40 bytes of padding:
>> > +
>> > ++-----------------------------------+
>> > +| SSDT with OEM Table ID = VMCOREIN |
>> > ++-----------------------------------+
>> > +| ...                               |       TOP OF PAGE
>> > +| VCIA dword object ----------------|----->
>> > +---------------------------+
>> > +| ...                               |       | fw-allocated array for
>> > |
>> > +| _STA method referring to VCIA     |       | "etc/vmcoreinfo"
>> > |
>> > +| ...                               |
>> > +---------------------------+
>> > +| ADDR method referring to VCIA     |       |  0: OVMF SDT Header probe
>> > |
>> > +| ...                               |       |     suppressor
>> > |
>> > ++-----------------------------------+       | 40: uint32 version field
>> > |
>> > +                                            | 44: info contents
>> > |
>> > +                                            |     ....
>> > |
>> > +
>> > +---------------------------+
>> > +                                            END OF PAGE
>> > +
>> > +Version 0 content:
>> > +
>> > + uint64 paddr:
>> > +  Physical address of the Linux vmcoreinfo ELF note.
>>
>> Or physical address of the Windows crash dump header :p
>
>
> Is there support for Windows crash dump in qemu?

Not yet :) We want to add it soon-ish. For QEMU (or libvirt?) to be
able to create Windows crash dump out of a raw guest physical memory
dump, it needs to know the "header", a page-sized datastructure which
Windows exposes via a kernel API. So the idea is that we would use the
same mechanism as Linux for its KASLR dump support.

>>
>> Do we want to have an additional discriminator field to tell what kind
>> of information was written by the guest or would Windows use a
>> different version?
>>
>
> I guess a different version would be ok.
>
> Thanks a lot for looking at it!
> --
> Marc-André Lureau

Thank you!
Ladi