From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35731 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OasfV-0004b5-FW for qemu-devel@nongnu.org; Mon, 19 Jul 2010 11:54:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OasfU-0004sL-A7 for qemu-devel@nongnu.org; Mon, 19 Jul 2010 11:54:13 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:43203) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OasfU-0004sA-7r for qemu-devel@nongnu.org; Mon, 19 Jul 2010 11:54:12 -0400 Received: by gxk19 with SMTP id 19so2394537gxk.4 for ; Mon, 19 Jul 2010 08:54:11 -0700 (PDT) Message-ID: <4C44751B.3070902@codemonkey.ws> Date: Mon, 19 Jul 2010 10:54:03 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Question about qemu firmware configuration (fw_cfg) device 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> <4C446526.1030008@codemonkey.ws> <20100719145324.GV4689@redhat.com> In-Reply-To: <20100719145324.GV4689@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 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. >> 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. > And I am not against something that does DMA, > but that is not what proposed patch does. It provides magic io > instruction that CPU calls and when instruction completes memory is > updated. This is nothing like DMA. Isn't this exactly what the interface for PCI DMA looks like since there's no standard DMA implementation? > 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. Regards, Anthony Liguori >> Buses exist to multiplex I/O devices because of limited wiring space >> on motherboards. There's no reason we need to constrain ourselves >> to minimize the number of virtual wires we emulate. >> >> Regards, >> >> Anthony Liguori >> > -- > Gleb. >