From: Anthony Liguori <anthony@codemonkey.ws>
To: Gleb Natapov <gleb@redhat.com>
Cc: qemu-devel@nongnu.org, "Richard W.M. Jones" <rjones@redhat.com>,
Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] Question about qemu firmware configuration (fw_cfg) device
Date: Mon, 19 Jul 2010 10:54:03 -0500 [thread overview]
Message-ID: <4C44751B.3070902@codemonkey.ws> (raw)
In-Reply-To: <20100719145324.GV4689@redhat.com>
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.
>
next prev parent reply other threads:[~2010-07-19 15:54 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-17 9:50 [Qemu-devel] Question about qemu firmware configuration (fw_cfg) device Richard W.M. Jones
2010-07-17 9:53 ` Richard W.M. Jones
2010-07-18 17:26 ` Alexander Graf
2010-07-18 20:09 ` Richard W.M. Jones
2010-07-18 20:32 ` Alexander Graf
2010-07-19 6:23 ` Gleb Natapov
2010-07-19 7:28 ` Richard W.M. Jones
2010-07-19 7:33 ` Gleb Natapov
2010-07-19 7:40 ` Alexander Graf
2010-07-19 7:51 ` Gleb Natapov
2010-07-19 7:57 ` Alexander Graf
2010-07-19 8:01 ` Gleb Natapov
2010-07-19 8:08 ` Alexander Graf
2010-07-19 8:19 ` Gleb Natapov
2010-07-19 8:24 ` Alexander Graf
2010-07-19 8:30 ` Gleb Natapov
2010-07-19 8:41 ` Alexander Graf
2010-07-19 8:48 ` Gleb Natapov
2010-07-19 8:54 ` Alexander Graf
2010-07-19 9:00 ` Gleb Natapov
2010-07-19 9:02 ` Alexander Graf
2010-07-19 9:10 ` Gleb Natapov
2010-07-19 9:13 ` Alexander Graf
2010-07-19 9:19 ` Gleb Natapov
2010-07-19 9:21 ` Alexander Graf
2010-07-19 9:32 ` Gleb Natapov
2010-07-19 9:23 ` Richard W.M. Jones
2010-07-20 13:15 ` Jamie Lokier
2010-07-20 13:40 ` Gleb Natapov
2010-07-20 13:59 ` Richard W.M. Jones
2010-07-19 9:19 ` Richard W.M. Jones
2010-07-19 7:44 ` Richard W.M. Jones
2010-07-19 7:55 ` Gleb Natapov
2010-07-19 8:34 ` Richard W.M. Jones
2010-07-19 8:40 ` Gleb Natapov
2010-07-19 9:00 ` Richard W.M. Jones
2010-07-19 9:04 ` Richard W.M. Jones
2010-07-19 9:06 ` Gleb Natapov
2010-07-19 9:09 ` Alexander Graf
2010-07-19 9:15 ` Gleb Natapov
2010-07-19 9:16 ` Alexander Graf
2010-07-19 13:06 ` Richard W.M. Jones
2010-07-19 13:12 ` Gleb Natapov
2010-07-19 14:52 ` Anthony Liguori
2010-07-19 14:54 ` Gleb Natapov
2010-07-19 14:45 ` Anthony Liguori
2010-07-19 14:53 ` Gleb Natapov
2010-07-19 15:54 ` Anthony Liguori [this message]
2010-07-19 16:11 ` Gleb Natapov
2010-07-19 16:47 ` Richard W.M. Jones
2010-07-19 17:04 ` Gleb Natapov
2010-07-19 19:06 ` Anthony Liguori
2010-07-19 6:12 ` Gleb Natapov
2010-07-19 6:14 ` [Qemu-devel] " Gleb Natapov
2010-07-20 22:22 ` [Qemu-devel] " Blue Swirl
2010-07-21 7:27 ` Alexander Graf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C44751B.3070902@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=agraf@suse.de \
--cc=gleb@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).