From: "Andreas Färber" <afaerber@suse.de>
To: Julien Grall <julien.grall@citrix.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
gson@gson.org, 1089996@bugs.launchpad.net,
"Markus Armbruster" <armbru@redhat.com>,
qemu-devel@nongnu.org, "Hervé Poussineau" <hpoussin@reactos.org>,
avi@redhat.com, "Stefan Hajnoczi" <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [[Bug 108996]] hw/dma.c: Fix conversion ioport_register* to MemoryRegion
Date: Fri, 14 Dec 2012 18:30:16 +0100 [thread overview]
Message-ID: <50CB6228.4080005@suse.de> (raw)
In-Reply-To: <8491483f6c0154f26be31bf7fad11566eb4810d3.1355478583.git.julien.grall@citrix.com>
Am 14.12.2012 10:52, schrieb Julien Grall:
> The commit 582299336879504353e60c7937fbc70fea93f3da introduced a bug in
> dma emulation due to a bad conversion between ioport_register* and MemoryRegion.
>
> Cc: 1089996@bugs.launchpad.net
> Reported-by: Andreas Gustafsson <gson@gson.org>
> Signed-off-by: Julien Grall <julien.grall@citrix.com>
I had trouble following here, having handled the offending patch myself:
"Fix", "a bug" and "a bad conversion" is not really telling me what went
wrong and how the numbers are calculated correctly. Please suggest an
additional explanatory paragraph for the commit message (as a reply).
Formally the patch looks fine (modulo missing "of" or
s/conversion/converting/g in $subject).
>From what I gather, the cont region starts at base + 8 << dshift. Why is
the size in memory_region_init_io() 8 << d->dshift and not just 8 when
it previously looped over 0..7? Same question for the channel region.
Could be fixed as follow-up. More comments inline:
> ---
> hw/dma.c | 22 +++++++++++-----------
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/hw/dma.c b/hw/dma.c
> index c2d7b21..1b1d406 100644
> --- a/hw/dma.c
> +++ b/hw/dma.c
> @@ -200,7 +200,7 @@ static void write_cont(void *opaque, hwaddr nport, uint64_t data,
>
> iport = (nport >> d->dshift) & 0x0f;
> switch (iport) {
> - case 0x01: /* command */
> + case 0x00: /* command */
Since the shift is "reverted" above, we effectively have an 0x8 ->
0x8+0x1 -> 0x8+0x0 change, which looks correct.
This delta seems consistent for the other case changes ...
> if ((data != 0) && (data & CMD_NOT_SUPPORTED)) {
> dolog("command %"PRIx64" not supported\n", data);
> return;
> @@ -208,7 +208,7 @@ static void write_cont(void *opaque, hwaddr nport, uint64_t data,
> d->command = data;
> break;
>
> - case 0x02:
> + case 0x01:
> ichan = data & 3;
> if (data & 4) {
> d->status |= 1 << (ichan + 4);
> @@ -220,7 +220,7 @@ static void write_cont(void *opaque, hwaddr nport, uint64_t data,
> DMA_run();
> break;
>
> - case 0x03: /* single mask */
> + case 0x02: /* single mask */
> if (data & 4)
> d->mask |= 1 << (data & 3);
> else
> @@ -228,7 +228,7 @@ static void write_cont(void *opaque, hwaddr nport, uint64_t data,
> DMA_run();
> break;
>
> - case 0x04: /* mode */
> + case 0x03: /* mode */
> {
> ichan = data & 3;
> #ifdef DEBUG_DMA
> @@ -247,23 +247,23 @@ static void write_cont(void *opaque, hwaddr nport, uint64_t data,
> break;
> }
>
> - case 0x05: /* clear flip flop */
> + case 0x04: /* clear flip flop */
> d->flip_flop = 0;
> break;
>
> - case 0x06: /* reset */
> + case 0x05: /* reset */
> d->flip_flop = 0;
> d->mask = ~0;
> d->status = 0;
> d->command = 0;
> break;
>
> - case 0x07: /* clear mask for all channels */
> + case 0x06: /* clear mask for all channels */
> d->mask = 0;
> DMA_run();
> break;
>
> - case 0x08: /* write mask for all channels */
> + case 0x07: /* write mask for all channels */
> d->mask = data;
> DMA_run();
> break;
> @@ -288,11 +288,11 @@ static uint64_t read_cont(void *opaque, hwaddr nport, unsigned size)
>
> iport = (nport >> d->dshift) & 0x0f;
> switch (iport) {
> - case 0x08: /* status */
> + case 0x00: /* status */
> val = d->status;
> d->status &= 0xf0;
> break;
> - case 0x0f: /* mask */
> + case 0x01: /* mask */
> val = d->mask;
> break;
> default:
> @@ -467,7 +467,7 @@ void DMA_schedule(int nchan)
> static void dma_reset(void *opaque)
> {
> struct dma_cont *d = opaque;
> - write_cont(d, (0x06 << d->dshift), 0, 1);
> + write_cont(d, (0x05 << d->dshift), 0, 1);
... and for the (weird :)) reuse of the write_cont() callback function
from within the reset function.
> }
>
> static int dma_phony_handler (void *opaque, int nchan, int dma_pos, int dma_len)
Reviewed-by: Andreas Färber <afaerber@suse.de>
make check runs an fdc-test that passed okay. Can one of you add a test
case to avoid another regression here?
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2012-12-14 17:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-14 9:52 [Qemu-devel] [[Bug 108996]] hw/dma.c: Fix conversion ioport_register* to MemoryRegion Julien Grall
2012-12-14 17:30 ` Andreas Färber [this message]
2012-12-15 21:31 ` Julien Grall
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=50CB6228.4080005@suse.de \
--to=afaerber@suse.de \
--cc=1089996@bugs.launchpad.net \
--cc=armbru@redhat.com \
--cc=avi@redhat.com \
--cc=gson@gson.org \
--cc=hpoussin@reactos.org \
--cc=julien.grall@citrix.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.