Re: [Qemu-devel] [PATCH 0/3] Memory API mutators

[Jan Kiszka <jan.kiszka@siemens.com>]

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