From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55284 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ObCfQ-0003sw-Qw for qemu-devel@nongnu.org; Tue, 20 Jul 2010 09:15:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ObCfP-0001kp-MK for qemu-devel@nongnu.org; Tue, 20 Jul 2010 09:15:28 -0400 Received: from mail2.shareable.org ([80.68.89.115]:35596) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ObCfP-0001jD-Fj for qemu-devel@nongnu.org; Tue, 20 Jul 2010 09:15:27 -0400 Date: Tue, 20 Jul 2010 14:15:16 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] Question about qemu firmware configuration (fw_cfg) device Message-ID: <20100720131516.GC5439@shareable.org> References: <20100717095059.GA19767@amd.home.annexia.org> <20100717095353.GB19767@amd.home.annexia.org> <269D196D-8CE8-4E24-8EE1-39756AC55F7F@suse.de> <20100718200942.GL13194@amd.home.annexia.org> <44FD4F00-843D-41C8-B21A-148D16745015@suse.de> <20100719062356.GU4689@redhat.com> <20100719072802.GO13194@amd.home.annexia.org> <20100719073312.GY4689@redhat.com> <4E9BBBA5-F2D1-4485-AFD3-8D6FDE3A3CCC@suse.de> <20100719075110.GB4689@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100719075110.GB4689@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: qemu-devel@nongnu.org, Alexander Graf , "Richard W.M. Jones" Gleb Natapov wrote: > On Mon, Jul 19, 2010 at 09:40:18AM +0200, Alexander Graf wrote: > > > > On 19.07.2010, at 09:33, Gleb Natapov wrote: > > > > > On Mon, Jul 19, 2010 at 08:28:02AM +0100, Richard W.M. Jones wrote: > > >> On Mon, Jul 19, 2010 at 09:23:56AM +0300, Gleb Natapov wrote: > > >>> That what I am warring about too. If we are adding device we have to be > > >>> sure such device can actually exist on real hw too otherwise we may have > > >>> problems later. > > >> > > >> I don't understand why the constraints of real h/w have anything to do > > >> with this. Can you explain? > > >> > > > Each time we do something not architectural it cause us troubles later. > > > So constraints of real h/w is our constrains to. > > > > > >>> Also 1 second on 100M file does not look like huge gain to me. > > >> > > >> Every second counts. We're trying to get libguestfs boot times down > > >> from 8-12 seconds to 4-5 seconds. For many cases it's an interactive > > >> program. > > >> > > > So what about making initrd smaller? I remember managing two > > > distribution in 64M flash in embedded project. > > > > Having a huge initrd basically helps in reusing a lot of existing code. We do the same - in general the initrd is just a subset of the applications of the host OS. And if you start putting perl or the likes into it, it becomes big. > > > Why not provide small disk/cdrom with all those utilities installed? > > > I guess the best thing for now really is to try and see which code paths insb goes along. It should really be coalesced. > > > It is coalesced to a certain extent (reenter guest every 1024 bytes, > read from userspace page at a time). You need to continue injecting > interrupt into a guest during long string operation and checking > exception condition on a page boundaries. First obvious change is to make that 4k bytes (page size) when the I/O port is the firmware port. That'll make initrd 4 times faster straight away. If that's not enough saving, it strikes me a cleaner approach than inventing new kinds of DMA and/or new PCI devices, is to just detect when the rep insb instruction is used for loading a firmware blob and treat that as a different trap. Is guest SeaBIOS in real mode at that point? If yes, then it would be best to trap this combination: rep insb is fetching a blob + CPU is in real mode Because then it's safe to skip the exception check on page boundaries. If no, the trap will need to be a bit smarter. Advantages of this approach: - No need for new BIOS - Will work with older BIOSes using current method, and accelerate them - No need for distinct -initrd BIOS implementations for isapc and pc, (compared with the PCI proposal) - Doesn't add any new "extra-architectural" behaviour -- Jamie