Re: [Qemu-devel] Re: [PATCH 0/5] *** SUBJECT HERE ***

[Aurelien Jarno <aurelien@aurel32.net>]

On Wed, Mar 31, 2010 at 08:08:52PM +0300, Blue Swirl wrote:
> On 3/31/10, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > On 03/26/2010 08:02 PM, Blue Swirl wrote:
> >  > Comments, anyone?
> >
> >  Sorry I'm late.
> >
> >  I don't really like the changes introduced here, because they make
> >  devices very very tied to the boards.  Hopefully this could be changed
> >  one day with qdev, and patches like this make this task more complicated.
> 
> The real solution is to insert a byte swapping bus where needed and
> also make devices use some kind of memory API which goes through any
> buses (including byte swapping buses) in between the device and
> memory.
> 
> >  One example is the openpic page size pointed out downthread.
> >
> >  What about something like this (doesn't change all the places affected
> >  by your series, compile-tested only)?
> 
> In general (with vmport and maybe virtio as the only exceptions), the
> devices have no business knowing _any_ CPU properties, like page size
> or endianness. If there really was a device that really cared about
> CPU page size, the size should be also known by the board and should
> be passed down from there via qdev property. Byte swapping should be
> handled by the bus, bus controller or memory controller.

If the device don't have to know about any CPU properties, it's probably
better to remove the wrong dependency on the CPU property, instead of
hardcoding values, like for example to 4096 for the page size.

Note also that we are talking about devices that are usually part of the
CPU like openpic, that's why there are really tight with the CPU.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net