[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: Compile files only once: some planning
From: |
Blue Swirl |
Subject: |
[Qemu-devel] Re: Compile files only once: some planning |
Date: |
Wed, 24 Mar 2010 22:32:47 +0200 |
On 3/24/10, Michael S. Tsirkin <address@hidden> wrote:
> On Wed, Mar 24, 2010 at 10:24:12PM +0200, Blue Swirl wrote:
> > On 3/24/10, Michael S. Tsirkin <address@hidden> wrote:
> > > On Wed, Mar 24, 2010 at 10:05:10PM +0200, Blue Swirl wrote:
> > > > On 3/24/10, Michael S. Tsirkin <address@hidden> wrote:
> > > > > On Tue, Mar 23, 2010 at 11:43:51PM +0200, Blue Swirl wrote:
> > > > > > rtl8139.c, e1000.c: need to convert ldl/stl to
> cpu_physical_memory_read/write.
> > > > >
> > > > >
> > > > > I don't see how it would help. These still get target_phys_addr_t
> which
> > > > > is per-target. Further, a ton of devices do
> > > > > cpu_register_physical_memory/qemu_register_coalesced_mmio.
> > > > > These are also per target.
> > > >
> > > > I don't know what I was eating yesterday: there are no references to
> > > > ldl/stl in either rtl8139 or e1000. In fact, the conversion is simple
> > > > for the device itself, just add a property "be". The attached patch
> > > > performs this part.
> > > >
> > > > But now there is a bigger problem, how to pass the property to the
> > > > device. It's not fair to require the user to remember to set it.
> > >
> > >
> > > I still don't fully understand how come e1000 cares about
> > > target endianness.
> >
> > It shouldn't. Maybe the real fix is to remove the byte swapping.
>
>
> Presumably it's there for a reason?
>
>
> > > > > A simple solution would be to change all of cpu_XX functions to
> > > > > get a 64 bit address. This is a lot of churn, if we do this
> > > > > anyway we should also pass length to callbacks, this way
> > > > > rwhandler will get very small or go away completely.
> > > >
> > > > It's not too much effort to keep the target_phys_addr_t type.
> > >
> > >
> > > I don't understand - target_phys_addr_t is different for different
> > > targets to we will need to recompile the code for each target.
> > > What am I missing?
> >
> > target_phys_addr_t is 64 bit on a 64 bit host, on a 32 bit host it's
> > size will be either 64 or 32 bits depending on the target. So the
> > files are compiled once on 64 bit host, twice on 32 bit host if both
> > 32 and 64 bits targets are selected.
>
>
> How about just making it 64 bit unconditionally?
> How much do we save by using a 32 bit address value?
On a 32 bit host, probably a lot because of register pressure. And
it's not too much effort to keep the target_phys_addr_t type logic.
[Qemu-devel] Re: Compile files only once: some planning, Michael S. Tsirkin, 2010/03/24
Re: [Qemu-devel] Re: Compile files only once: some planning, Paul Brook, 2010/03/24
Re: [Qemu-devel] Re: Compile files only once: some planning, Anthony Liguori, 2010/03/24
Re: [Qemu-devel] Re: Compile files only once: some planning, Paul Brook, 2010/03/24
Re: [Qemu-devel] Re: Compile files only once: some planning, Anthony Liguori, 2010/03/24
Re: [Qemu-devel] Re: Compile files only once: some planning, Michael S. Tsirkin, 2010/03/25
Re: [Qemu-devel] Re: Compile files only once: some planning, Paul Brook, 2010/03/25