From: David Gibson <david@gibson.dropbear.id.au>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: joerg.roedel@amd.com, agraf@suse.de, qemu-devel@nongnu.org,
avi@redhat.com, eduard.munteanu@linux360.ro, rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH 05/14] eepro100: Use PCI DMA stub functions
Date: Fri, 4 Nov 2011 11:28:03 +1100 [thread overview]
Message-ID: <20111104002803.GB4713@truffala.fritz.box> (raw)
In-Reply-To: <20111103122544.GH18296@redhat.com>
On Thu, Nov 03, 2011 at 02:25:45PM +0200, Michael S. Tsirkin wrote:
> On Thu, Nov 03, 2011 at 04:16:34PM +1100, David Gibson wrote:
> > On Wed, Nov 02, 2011 at 09:16:34AM +0200, Michael S. Tsirkin wrote:
> > > On Mon, Oct 31, 2011 at 05:06:49PM +1100, David Gibson wrote:
> > > > From: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
> > [snip]
> > > > @@ -744,21 +713,26 @@ static void dump_statistics(EEPRO100State * s)
> > > > * values which really matter.
> > > > * Number of data should check configuration!!!
> > > > */
> > > > - cpu_physical_memory_write(s->statsaddr, &s->statistics, s->stats_size);
> > > > - e100_stl_le_phys(s->statsaddr + 0, s->statistics.tx_good_frames);
> > > > - e100_stl_le_phys(s->statsaddr + 36, s->statistics.rx_good_frames);
> > > > - e100_stl_le_phys(s->statsaddr + 48, s->statistics.rx_resource_errors);
> > > > - e100_stl_le_phys(s->statsaddr + 60, s->statistics.rx_short_frame_errors);
> > > > + pci_dma_write(&s->dev, s->statsaddr,
> > > > + (uint8_t *) &s->statistics, s->stats_size);
> > > > + stl_le_pci_dma(&s->dev, s->statsaddr + 0,
> > > > + s->statistics.tx_good_frames);
> > > > + stl_le_pci_dma(&s->dev, s->statsaddr + 36,
> > > > + s->statistics.rx_good_frames);
> > > > + stl_le_pci_dma(&s->dev, s->statsaddr + 48,
> > > > + s->statistics.rx_resource_errors);
> > > > + stl_le_pci_dma(&s->dev, s->statsaddr + 60,
> > > > + s->statistics.rx_short_frame_errors);
> > >
> > > This might introduce a bug: stlXX APIs assume aligned addresses,
> > > an address in statsaddr is user-controlled so I'm not sure
> > > it's always aligned.
> > >
> > > Why isn't the patch simply replacing cpu_physical_memory_read
> > > with pci_XXX ? Any cleanups should be done separately.
> >
> > Because it seemed like a good idea at the time. When I first wrote
> > this, the possibility of unaligned addresses wasn't obvious to me.
> > So, I'm working on fixing this now. I can take one of two approaches:
> >
> > - Simply revert this part of the change, reinstate the e100_stl
> > functions as calling into dma_write().
> >
> > - Alter the stX_dma() functions to work for unaligned addresses (by
> > falling back to dma_rw() in that case). This is a little more
> > involved but might make device writing safer in future.
>
> Yes but then we lose the atomicity guarantee. So this might
> still result in subtle emulation bugs.
Sorry, I should have been clearer - I was planning to fall back to
dma_rw() *only* for unaligned addresses. Aligned addresses would
still have the atomicity guarantee.
> > Anthony, Michael, any preferred direction here?
>
> For 1.0 I'd go for option 1 as the simplest.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
next prev parent reply other threads:[~2011-11-04 0:37 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-31 6:06 [Qemu-devel] [0/14] Preliminary work for IOMMU emulation support (v3) David Gibson
2011-10-31 6:06 ` [Qemu-devel] [PATCH 01/14] Define DMA address and direction types David Gibson
2011-11-01 22:21 ` Anthony Liguori
2011-10-31 6:06 ` [Qemu-devel] [PATCH 02/14] Use dma_addr_t type for scatter/gather code David Gibson
2011-10-31 6:06 ` [Qemu-devel] [PATCH 03/14] Add stub functions for PCI device models to do PCI DMA David Gibson
2011-11-02 7:17 ` Michael S. Tsirkin
2011-11-02 11:47 ` David Gibson
2011-10-31 6:06 ` [Qemu-devel] [PATCH 04/14] rtl8139: Use PCI DMA stub functions David Gibson
2011-10-31 6:06 ` [Qemu-devel] [PATCH 05/14] eepro100: " David Gibson
2011-10-31 16:45 ` Stefan Weil
2011-11-01 20:24 ` Anthony Liguori
2011-11-02 7:40 ` Michael S. Tsirkin
2011-11-02 12:46 ` Anthony Liguori
2011-11-02 17:56 ` Alexander Graf
2011-11-02 17:19 ` Anthony Liguori
2011-11-02 17:28 ` Alexander Graf
2011-11-02 19:11 ` Michael S. Tsirkin
2011-11-03 0:52 ` David Gibson
2011-11-02 11:01 ` Michael S. Tsirkin
2011-11-02 7:16 ` Michael S. Tsirkin
2011-11-03 5:16 ` David Gibson
2011-11-03 12:25 ` Michael S. Tsirkin
2011-11-04 0:28 ` David Gibson [this message]
2011-11-05 8:32 ` Stefan Weil
2011-10-31 6:06 ` [Qemu-devel] [PATCH 06/14] ac97: " David Gibson
2011-10-31 6:06 ` [Qemu-devel] [PATCH 07/14] es1370: " David Gibson
2011-10-31 6:06 ` [Qemu-devel] [PATCH 08/14] e1000: " David Gibson
2011-10-31 6:06 ` [Qemu-devel] [PATCH 09/14] lsi53c895a: " David Gibson
2011-10-31 6:06 ` [Qemu-devel] [PATCH 10/14] pcnet-pci: " David Gibson
2011-10-31 6:06 ` [Qemu-devel] [PATCH 11/14] intel-hda: " David Gibson
2011-10-31 6:06 ` [Qemu-devel] [PATCH 12/14] PCI IDE: " David Gibson
2011-10-31 6:06 ` [Qemu-devel] [PATCH 13/14] usb-ehci: " David Gibson
2011-10-31 6:06 ` [Qemu-devel] [PATCH 14/14] usb-uhci: " David Gibson
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=20111104002803.GB4713@truffala.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=agraf@suse.de \
--cc=avi@redhat.com \
--cc=eduard.munteanu@linux360.ro \
--cc=joerg.roedel@amd.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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).