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.munte...@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. > 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