qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/3] xilinx: Speed up the build


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH 0/3] xilinx: Speed up the build
Date: Sat, 09 Jun 2012 17:31:39 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0

Am 09.06.2012 17:20, schrieb Edgar E. Iglesias:
> On Sat, Jun 09, 2012 at 03:54:28AM +0200, Andreas Färber wrote:
>> xilinx_ethlite.c uses tswap32(). Have you ever tested this device to work on
>> microblazeel? I wonder if we could change the device from 
>> DEVICE_NATIVE_ENDIAN
>> to DEVICE_BIG_ENDIAN and in place of tswap32() use a bswap32() conditional on
>> HOST_WORDS_BIGENDIAN so that it becomes independent of the target, too?
> 
> I don't think that will work. the swap is needed if the endianness of the host
> is different from the one of the target...

My thinking was: If we can force the device endianness to a known value
then only the host endianness (not the target endianness) matters
because the Memory API will take care of the device endianness.

The question is: Is the device LE for microblazeel or is it always BE?

> IIRC, the issue is that the device has a built-in RAM mapped so close to
> the regs that they end up in the same "page". With Avis memory-api maybe it's
> possible to expose this sub-page area as a memory?

Me and Avi fixed some bugs for subpage areas, it should work in theory
(for TCG/qtest). Not being aware of a MicroBlaze KVM, if it's a RAM
region then we should definitely model it as such.

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]