qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 14/15] memory: return MemoryRegion from qemu_ram


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 14/15] memory: return MemoryRegion from qemu_ram_addr_from_host
Date: Mon, 03 Jun 2013 12:51:31 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6

Il 03/06/2013 08:40, Paolo Bonzini ha scritto:
> Il 02/06/2013 18:04, Peter Maydell ha scritto:
>> On 2 June 2013 16:43, Paolo Bonzini <address@hidden> wrote:
>>> -int qemu_ram_addr_from_host(void *ptr, ram_addr_t *ram_addr);
>>> +MemoryRegion *qemu_ram_addr_from_host(void *ptr, ram_addr_t *ram_addr);
>>>  ram_addr_t qemu_ram_addr_from_host_nofail(void *ptr);
>>
>> This is weird, because now the _nofail and the standard
>> versions of this function return different things.

Ah, actually that's not a change.  The function used to return 0/-1 and
place the address in a by-reference argument.  It's a somewhat weird
decision made when the normal and _nofail version were split (commit
e890261, Export qemu_ram_addr_from_host, 2010-10-11).  Returning -1 to
indicate failure would have been ok, since it's not a valid ram_addr_t.

>> Why wouldn't a caller of the _nofail version potentially
>> need the MemoryRegion* too?

Because there are just a handful of calls, and all of them are in
cputlb.c which is not very much MemoryRegion-aware.  I'll just move it
there and make it static.

The right fix here would be to make all the MCE handling code not
KVM-specific.  Then it can be in exec.c and ram_addr_t can be private
(eliminating a good deal of confusion between it and hwaddr).

Paolo



reply via email to

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