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

[Denis V. Lunev]

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?

Den