From: Jan Kiszka <jan.kiszka@web.de>
To: "Andreas Färber" <andreas.faerber@web.de>
Cc: "Hervé Poussineau" <hpoussin@reactos.org>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] MMIO coalescing of the i82378 bridge
Date: Sat, 23 Jun 2012 14:53:05 +0200 [thread overview]
Message-ID: <4FE5BC31.8000006@web.de> (raw)
In-Reply-To: <4FE5BA8F.7050405@web.de>
[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]
On 2012-06-23 14:46, Andreas Färber wrote:
> Hi Jan,
>
> Am 23.06.2012 11:28, schrieb Jan Kiszka:
>> just stumbled over the memory_region_set_coalescing in pci_i82378_init:
>> What ISA devices are affected by this? It looks a bit strange to me as
>> the MMIO requests are apparently mapped on PIO requests, and we don't
>> have PIO coalescing on x86. Depending on the target device on PREP, this
>> may have some unexpected side effects. Or is only framebuffer memory
>> addressed this way?
>
> I only remember touching that line to rebase it onto either Memory API
> or QOM. The i82378 is the sole PCI-ISA bridge so all ISA devices will be
> affected by it, which is pretty much everything except VGA iirc.
> The upcoming pc87312(?) Super I/O also would be attached to it,
> replacing some of the bogus I/O in the current "prep" machine.
>
> I'm not familiar with what this option affects. What unexpected side
> effects would you expect? :)
Simple example: You write to the PIT to start/stop a timer, but this
transaction is now delayed until the next coalesced buffer flush.
IOW, there surely exit write operations that must not be reordered /wrt
to the VCPU execution flow. I would recommend to drop coalescing, even
more if its benefit is not clear.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
prev parent reply other threads:[~2012-06-23 12:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-23 9:28 [Qemu-devel] MMIO coalescing of the i82378 bridge Jan Kiszka
2012-06-23 12:46 ` Andreas Färber
2012-06-23 12:53 ` Jan Kiszka [this message]
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=4FE5BC31.8000006@web.de \
--to=jan.kiszka@web.de \
--cc=andreas.faerber@web.de \
--cc=hpoussin@reactos.org \
--cc=qemu-devel@nongnu.org \
/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).