Re: [Qemu-devel] [PATCH] qga: implement guest-file-ioctl

[Ladi Prosek]

On Mon, Feb 6, 2017 at 5:10 PM, Alexey Kostyushko <address@hidden> wrote:
> This info is more about pvpanic patch, but may be relevant here also.
>
> Consider that KeInitializeCrashDumpHeader is not enough to create dumps
> because it copy only primary header

You mean that the secondary data area is missing? That's by design -
again, the OS is running, we're not really crashing it so
BugCheckSecondaryDumpDataCallback's are not invoked.

For the actual "crash" crash dumps, we can experiment with
BugCheckDumpIoCallback which would let us push out the header as well
as secondary data but that's a non-goal at the moment.

> and doesn't copy KdDebuggerBlock.

It contains the pointers from KdDebuggerBlock: PsLoadedModuleList,
PsActiveProcessHead, and more. In my testing, the dump created from
KeInitializeCrashDumpHeader and the raw memory image was fully
functional. If there's anything specific you're concerned about, I can
check it.

> Look to combine info from KeCapturePersistentThreadState.

This looks like an undocumented API and I'd like to avoid those if possible.

> Also whenever amount of RAM is changed (memory hot-plug) you need to
> recreate headers.

That would be a maybe. We could just patch the memory regions in the
header to reflect the current memory layout. And there's a chance we
may need to do it anyways - the physical memory layout that QEMU works
with doesn't match what Windows sees for some reason. That's one thing
I need to take a close look at. Thanks!

> I think that there should be virtio direct channel for general purposes of
> dumping and guest-agent channel may be usefull for obtainin varoius
>
> info from guest drivers through ioctls and providing live-dump feature.
>
> ________________________________
> From: Ladi Prosek <address@hidden>
> Sent: Monday, February 6, 2017 6:50:43 PM
> To: Denis Lunev
> Cc: Daniel P. Berrange; qemu-devel; Michael Roth; Alexey Kostyushko
> Subject: Re: [Qemu-devel] [PATCH] qga: implement guest-file-ioctl
>
> On Mon, Feb 6, 2017 at 4:37 PM, Denis V. Lunev <address@hidden> wrote:
>> On 02/01/2017 04:41 PM, Ladi Prosek wrote:
>>> On Wed, Feb 1, 2017 at 12:03 PM, Daniel P. Berrange <address@hidden>
>>> wrote:
>>>> On Wed, Feb 01, 2017 at 11:50:43AM +0100, Ladi Prosek wrote:
>>>>> On Wed, Feb 1, 2017 at 11:20 AM, Daniel P. Berrange
>>>>> <address@hidden> wrote:
>>>>>> On Wed, Feb 01, 2017 at 11:06:46AM +0100, Ladi Prosek wrote:
>>>>>>> Analogous to guest-file-read and guest-file-write, this commit adds
>>>>>>> support for issuing IOCTLs to files in the guest. With the goal of
>>>>>>> abstracting away the differences between Posix ioctl() and Win32
>>>>>>> DeviceIoControl() to provide one unified API, the schema
>>>>>>> distinguishes
>>>>>>> between input and output buffer sizes (as required by Win32) and
>>>>>>> allows the caller to supply either a 'buffer', pointer to which will
>>>>>>> be passed to the Posix ioctl(), or an integer argument, passed to
>>>>>>> ioctl() directly.
>>>>>> What is the intended usage scenario for this ?
>>>>> My specific case is extracting a piece of data from Windows guests.
>>>>> Guest driver exposes a file object with a well-known IOCTL code to
>>>>> return a data structure from the kernel.
>>>> Please provide more information about what you're trying to do.
>>>>
>>>> If we can understand the full details it might suggest a different
>>>> approach that exposing a generic ioctl passthrough facility.
>>> The end goal is to be able to create a Window crash dump file from a
>>> running (or crashed, but running is more interesting because Windows
>>> can't do that by itself) Windows VM. To do that without resorting to
>>> hacks, the host application driving this needs to get the crash dump
>>> header, which Windows provides in its KeInitializeCrashDumpHeader
>>> kernel API.
>>>
>>> I believe that the most natural way to do this is to have
>>> 1) a driver installed in the guest providing a way to call
>>> KeInitializeCrashDumpHeader from user space
>>> 2) an agent in the guest, running in user space, calling the driver
>>> and passing the result back to the host
>>>
>>> Now 2) may as well be an existing agent, such as the QEMU guest agent,
>>> and that's why I am here :)
>>>
>>> KeInitializeCrashDumpHeader returns an opaque byte array, happens to
>>> be 8192 bytes at the moment. My first choice for the kernel-user
>>> interface in the guest is IOCTL because what I'm trying to get across
>>> is a block, a "datagram", not a stream, and I have the option for
>>> easily adding more functionality later by adding more IOCTL codes with
>>> the file object still representing "the driver".
>>>
>>> I could use regular file I/O as well. I would either have to devise a
>>> protocol for talking to the driver, have a way of delimiting messages,
>>> re-syncing the channel etc., or make a slight semantic shift and
>>> instead of the file object representing the driver, it would represent
>>> this one particular function of the driver. Opening the file and
>>> reading from it until eof would yield the crash dump header.
>> I think that this is not as good as can be for the whole design of the
>> feature.
>> The problem here is that userspace starts toooooooooo late and is not
>> accessible when the guest BSODS and we do need a dump for analysis.
>>
>> May be it worth to push this header to QEMU at boot time through virtio
>> bus?
>
> Yes, definitely an option. I believe that having the ability to create
> a dump out of a live system, i.e. without crashing it, is what adds
> the most value here. And that would most likely happen on an
> up-and-running guest so the difference between being able to do it
> after a kernel driver loads and after a user space service starts is
> not that significant.
>
> Still, the sooner the better, for sure. I think I've seen
> virtio-pstore suggested as a possible channel to use to push the
> header.
>
> Thanks!
>
>> Den