From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55612 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OamNG-00012J-0d for qemu-devel@nongnu.org; Mon, 19 Jul 2010 05:11:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OamNF-0002Bp-05 for qemu-devel@nongnu.org; Mon, 19 Jul 2010 05:10:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62340) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OamNE-0002Bl-NH for qemu-devel@nongnu.org; Mon, 19 Jul 2010 05:10:56 -0400 Date: Mon, 19 Jul 2010 12:10:54 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] Question about qemu firmware configuration (fw_cfg) device Message-ID: <20100719091054.GL4689@redhat.com> References: <20100719080142.GE4689@redhat.com> <20100719081954.GF4689@redhat.com> <43B9EAA8-E3F5-4903-896C-DEBD90E06162@suse.de> <20100719083050.GG4689@redhat.com> <51B0CBDB-E40B-4A14-A33E-34E13B9BF3CB@suse.de> <20100719084800.GI4689@redhat.com> <28292784-F194-43D8-A640-B0DCAB0CF940@suse.de> <20100719090028.GJ4689@redhat.com> <555E6039-925B-4FB7-91EC-748DBC093FA2@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <555E6039-925B-4FB7-91EC-748DBC093FA2@suse.de> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "Richard W.M. Jones" , qemu-devel@nongnu.org On Mon, Jul 19, 2010 at 11:02:54AM +0200, Alexander Graf wrote: > > On 19.07.2010, at 11:00, Gleb Natapov wrote: > > > On Mon, Jul 19, 2010 at 10:54:43AM +0200, Alexander Graf wrote: > >> > >> On 19.07.2010, at 10:48, Gleb Natapov wrote: > >> > >>> > >>>> Were there DMA capable devices back in ISA times? There must be. If so, we can just take a look at what they do and do it similarly. Bus mastering was a new thing for PCI, right? > >>>> > >>> I think IDE can be considered DMA capable ISA device, no? At least > >>> it works by writing to PIO ports and getting result into memory, but > >>> with interrupts and status bits and everything that real device should > >>> have. On board DMA engine is also ISA device. > >> > >> We could define our device to be polling. So all we need is a status bit that the guest sets when it starts the DMA and the device unsets when the DMA is done. In our case that should be immediate, because the PIO invokes the full code paths, but it would look more like a real device, no? > >> > > This is better, but it shouldn't be synchronous. Kernel and initrd are > > on disk so why not setup aio and read them from io thread allowing vcpu > > thread immediately return to guest mode to process interrupts. > > That would work with the above described device model. If we're going synchronous or asynchronous would become an implementation detail. > If vcpu thread will sleep for too much time without processing events we can see strange timeouts in a guest. > > Or why > > not use virtio-serial while we are at it? After all virtio-serial is > > there to allow host and guest communication. > > Because virtio-serial needs us to set up the full virtio-pci stack. That's too much to mess with in an option rom IMHO. > We already do it for virtio-blk. Read only support is very small in LOC there. Don't know about virtio-serial protocol. -- Gleb.