qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 3/7] memory: iommu support


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH v2 3/7] memory: iommu support
Date: Wed, 31 Oct 2012 12:32:02 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1

On 10/30/2012 09:11 PM, Blue Swirl wrote:
> On Tue, Oct 30, 2012 at 11:47 AM, Avi Kivity <address@hidden> wrote:
>> Add a new memory region type that translates addresses it is given,
>> then forwards them to a target address space.  This is similar to
>> an alias, except that the mapping is more flexible than a linear
>> translation and trucation, and also less efficient since the
>> translation happens at runtime.
>>
>> The implementation uses an AddressSpace mapping the target region to
>> avoid hierarchical dispatch all the way to the resolved region; only
>> iommu regions are looked up dynamically.
>>
>> +
>> +static MemoryRegionOps memory_region_iommu_ops = {
>> +    .read = memory_region_iommu_read,
>> +    .write = memory_region_iommu_write,
>> +#ifdef HOST_BIGENDIAN
>> +    .endianness = DEVICE_BIG_ENDIAN,
> 
> Why couple this with host endianness? I'd expect IOMMU to operate at
> target bus endianness, for example LE for PCI on PPC guest.

This has nothing to do with device endianness; we're translating from a
byte buffer (address_space_rw()) to a uint64_t
(MemoryRegionOps::read/write()) so we need to take host endianess into
account.

This code cleverly makes use of memory core endian support to do the
conversion for us.  But it's probably too clever and should be replaced
by an explicit call to a helper.



-- 
error compiling committee.c: too many arguments to function



reply via email to

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