qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 04/11] exec: introduce MemoryRegionCache


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 04/11] exec: introduce MemoryRegionCache
Date: Tue, 13 Dec 2016 14:14:09 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1


On 12/12/2016 15:06, Stefan Hajnoczi wrote:
> On Mon, Dec 12, 2016 at 12:18:50PM +0100, Paolo Bonzini wrote:
>> diff --git a/exec.c b/exec.c
>> index d4b3656..8d4bb0e 100644
>> --- a/exec.c
>> +++ b/exec.c
>> @@ -3077,6 +3077,82 @@ void cpu_physical_memory_unmap(void *buffer, hwaddr 
>> len,
>>  #define RCU_READ_UNLOCK(...)     rcu_read_unlock()
>>  #include "memory_ldst.inc.c"
>>  
>> +int64_t address_space_cache_init(MemoryRegionCache *cache,
>> +                                 AddressSpace *as,
>> +                                 hwaddr addr,
>> +                                 hwaddr len,
>> +                                 bool is_write)
>> +{
>> +    hwaddr l, xlat;
>> +    MemoryRegion *mr;
>> +    void *ptr;
>> +
>> +    assert(len > 0);
>> +
>> +    l = len;
>> +    mr = address_space_translate(as, addr, &xlat, &l, is_write);
>> +    if (!memory_access_is_direct(mr, is_write)) {
>> +        return -EINVAL;
>> +    }
>> +
>> +    l = address_space_extend_translation(as, addr, len, mr, xlat, l, 
>> is_write);
>> +    ptr = qemu_ram_ptr_length(mr->ram_block, xlat, &l);
>> +
>> +    cache->xlat = xlat;
>> +    cache->is_write = is_write;
>> +    cache->mr = mr;
>> +    cache->ptr = ptr;
>> +    cache->len = l;
>> +    memory_region_ref(cache->mr);
>> +
>> +    return l;
>> +}
> 
> What happens when [addr, addr + len) overlaps a MemoryRegion boundary?
> It looks like this function silently truncates the MemoryRegionCache,

Yes, this is what address_space_map does.  It's up to the caller to
decide what to do.

Patch 8 ("virtio: use MemoryRegionCache to access descriptors") does it
right.  As you noted, patch 9 doesn't check for errors at all---that's
part of why this is RFC.

Paolo

> leading to an assertion failure in address_space_translate_cached().
> 
> Perhaps it would be better to fail address_space_cache_init() if the
> length is truncated.
> 



reply via email to

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