qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] Memory API


From: Richard Henderson
Subject: Re: [Qemu-devel] [RFC] Memory API
Date: Wed, 18 May 2011 09:51:30 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10

On 05/18/2011 09:06 AM, Avi Kivity wrote:
>> If we keep per-access type function pointers, they should use individual 
>> prototypes
>> for the different access types:
>>
>> typedef uint8_t  (*MemoryReadbFunc)(MemoryRegion *mr, target_phys_addr_t 
>> addr);
>> typedef uint16_t (*MemoryReadwFunc)(MemoryRegion *mr, target_phys_addr_t 
>> addr);
>> typedef uint32_t (*MemoryReadlFunc)(MemoryRegion *mr, target_phys_addr_t 
>> addr);
>> typedef uint64_t (*MemoryReadllFunc)(MemoryRegion *mr, target_phys_addr_t 
>> addr);
>> ...
> 
> I prefer having size as an argument.

The one thing that makes having these function pointers split apart nice
is that it makes it easy to set policy for what different sized reads do.

E.g. for devices for which only 4 byte reads are defined, you only fill
in readl, and let the other sizes cause a machine-check.

Alternately, for devices for which the fundamental size is 1 byte, but
which does handle larger reads in a more-or-less memory-like fashion,
you can fill in a common readw_via_readb function that does the 
composition for you, and without having to have code for that scattered
through every device.


r~



reply via email to

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