[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] RFC: vmcoreinfo device
From: |
Marc-André Lureau |
Subject: |
Re: [Qemu-devel] [PATCH] RFC: vmcoreinfo device |
Date: |
Fri, 28 Apr 2017 14:28:38 +0000 |
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?
> +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?
> 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