From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60372 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OavfW-00076J-Fh for qemu-devel@nongnu.org; Mon, 19 Jul 2010 15:06:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OavfV-0007ML-2o for qemu-devel@nongnu.org; Mon, 19 Jul 2010 15:06:26 -0400 Received: from mail-iw0-f173.google.com ([209.85.214.173]:62562) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OavfU-0007Lu-Ud for qemu-devel@nongnu.org; Mon, 19 Jul 2010 15:06:25 -0400 Received: by iwn6 with SMTP id 6so5106748iwn.4 for ; Mon, 19 Jul 2010 12:06:23 -0700 (PDT) Message-ID: <4C44A229.20307@codemonkey.ws> Date: Mon, 19 Jul 2010 14:06:17 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Question about qemu firmware configuration (fw_cfg) device References: <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> <4C446526.1030008@codemonkey.ws> <20100719145324.GV4689@redhat.com> <4C44751B.3070902@codemonkey.ws> <20100719161137.GA2391@redhat.com> In-Reply-To: <20100719161137.GA2391@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: qemu-devel@nongnu.org, "Richard W.M. Jones" , Alexander Graf On 07/19/2010 11:11 AM, Gleb Natapov wrote: > On Mon, Jul 19, 2010 at 10:54:03AM -0500, Anthony Liguori wrote: > >> On 07/19/2010 09:53 AM, Gleb Natapov wrote: >> >>> On Mon, Jul 19, 2010 at 09:45:58AM -0500, Anthony Liguori wrote: >>> >>>> On 07/19/2010 02:33 AM, 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. >>>>> >>>> Your constraints are purely artificial. >>>> >>>> >>> What is artificial about it? Each time we break them we safer. >>> >> Just because something doesn't fit as an ISA or PCI device doesn't >> mean it can't exist in real life. There are plenty of one-off >> devices with odd interfaces. >> > And there are such that cause cpu to stall for 6.5 seconds when you do > io to them? That would certainly be a poorly designed interface. I can appreciate your point and I think suggesting that we should implement an ad-hoc completion interface is reasonable. For instance, outl(FW_CFG_SET_INITRD_ADDR, addr) while !inb(FW_CFG_INITRD_READY): // spin >>>> There are plenty of places that something like fw_cfg could live and >>>> still do DMA. It can directly hang off of the Southbridge. It >>>> doesn't necessary need to be connected to the ISA/LPC buses. >>>> >>> Examples of real HW? >>> >> The IBM IMM, HP ILO, or Intel iAMT modules. They basically play an >> identical role to fw_cfg. >> >> > So what are their interfaces? May be we should emulate one. > The interface to firmware is private and changes from platform to platform. The IMM exposes various interfaces to the OS as it implements a number of legacy devices. It also exposes a side-channel (very similar to virtio-console) as a USB RNDIS driver. I believe it implements IPMI over a private ethernet type although I'd have to double check. It may actually use TCP/IP. Of course it is possible to add >>> proper DMA interface to fw_cfg, but should we do it for such a small >>> gain? >>> >> I think an ad-hoc DMA interface is perfectly reasonable to do. I >> agree that adding a more generic DMA interface is overkill. >> >> > It should look like real DMA at least. The justification for it should > be better than "In our project we don't what to do this and we don't > what to do that so our initrd is 100M now, so why not add hack to qemu > to load it 1 second faster so we can grow it some more". > I certainly agree that adding a polling interface for DMA completion is a reasonable requirement. Regards, Anthony Liguori > -- > Gleb. >