On Mon, Feb 06, 2017 at 06:37:29PM +0300, Denis V. Lunev wrote: > On 02/01/2017 04:41 PM, Ladi Prosek wrote: > > On Wed, Feb 1, 2017 at 12:03 PM, Daniel P. Berrange <berra...@redhat.com> > > 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 <berra...@redhat.com> > >>> 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, the lateness of userspace startup is the same objection I have to use of the guest agent in a similar role for dumping of info for Linux guests with KASLR. http://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg01618.html That thread explored options like virtio-pstore, or UEFI pstore or ACPI pstore as approaches for pushing the info the host during very early guest start. Definitely feels like there's scope for considering these needs in a common framework. From a libvirt POV we would really very strongly prefer to have a guest dump mechanism that has a common architectural approach regardless of guest OS, even if the actual info sent over that architecture was different. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
