From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42446) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1calYv-0004p7-Sx for qemu-devel@nongnu.org; Mon, 06 Feb 2017 10:50:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1calYr-0007v5-PC for qemu-devel@nongnu.org; Mon, 06 Feb 2017 10:50:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60686) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1calYr-0007uZ-BW for qemu-devel@nongnu.org; Mon, 06 Feb 2017 10:50:37 -0500 Date: Mon, 6 Feb 2017 15:50:29 +0000 From: "Daniel P. Berrange" Message-ID: <20170206155029.GB31991@redhat.com> Reply-To: "Daniel P. Berrange" References: <1485943606-13998-1-git-send-email-lprosek@redhat.com> <20170201102013.GC3232@redhat.com> <20170201110320.GD3232@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH] qga: implement guest-file-ioctl List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Denis V. Lunev" Cc: Ladi Prosek , qemu-devel , mdroth@linux.vnet.ibm.com, Aleksey Kostyushko 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 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 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/ :|