On 2011-09-14 11:49, Avi Kivity wrote:
> Jan, too, was interested in this.
>
> On 09/14/2011 12:23 PM, Avi Kivity wrote:
>> This patchset introduces memory_region_set_enabled() and
>> memory_region_set_address() to avoid the requirement on memory
>> routers to track the internal state of the memory API (so they know
>> whether they need to add or remove a region). Instead, they can
>> simply copy the state of the region from the guest-exposed register
>> to the memory core, via the new mutator functions.
>>
>> Please review. Do we need a memory_region_set_size() as well? Do we want
>>
>> memory_region_set_attributes(mr,
>> MR_ATTR_ENABLED | MR_ATTR_SIZE,
>> (MemoryRegionAttributes) {
>> .enabled = s->enabled,
>> .address = s->addr,
>> });
>>
>> ?
>>
>> Avi Kivity (3):
>> memory: introduce memory_region_set_enabled()
>> memory: introduce memory_region_set_address()
>> memory: optimize empty transactions due to mutators
>>
>> memory.c | 64
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++---------
>> memory.h | 28 +++++++++++++++++++++++++++
>> 2 files changed, 82 insertions(+), 10 deletions(-)
>>
Whatever the outcome is (tons of memory_region_set/get_X functions or
huge attribute structures + set/get_attributes), it should be consistent
for all attributes of a memory region. And there should be only one way
of doing this.
I think the decision multiple set/get vs. attribute struct depends on
some (estimated) usage stats: How many call sites will access multiple
attributes in one run and how may will only manipulate a single?
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
