qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] new memory api: offsets?


From: Michael Walle
Subject: Re: [Qemu-devel] new memory api: offsets?
Date: Thu, 1 Sep 2011 12:00:11 +0200
User-agent: KMail/1.13.5 (Linux/2.6.32-5-686-bigmem; KDE/4.4.5; i686; ; )

Am Donnerstag 01 September 2011, 07:54:28 schrieb Avi Kivity:
> On 09/01/2011 01:54 AM, Michael Walle wrote:
> > Hi Avi,
> > 
> > while debugging, i noticed, that mr->offset is never set, expect in the
> > initializer. (The subregion collision warning is printed although the
> > regions are not overlapping.) Is this intended?
> 
> Did you miss memory_region_set_offset()?
I saw that function but it's never called. Now i noticed that this is a 
deprecated public function.

> The subregion collision warning is unrelated?
you are walking along the subregions and use that offset property to detect 
collisions. Shouldn't you use the addr property instead?

@@ -1190,16 +1190,18 @@ static void 
memory_region_add_subregion_common(MemoryRegion *mr,
         if (subregion->may_overlap || other->may_overlap) {
             continue;
         }
-        if (offset >= other->offset + other->size
-            || offset + subregion->size <= other->offset) {
+        if (offset >= other->addr + other->size
+            || offset + subregion->size <= other->addr) {
             continue;
         }

> > btw. you may include the memory region name in the warning.
> 
> sure, patches welcome.

-        printf("warning: subregion collision %llx/%llx vs %llx/%llx\n",
+        printf("warning: subregion collision %llx/%llx (%s) "
+               "vs %llx/%llx (%s)\n",
                (unsigned long long)offset,
                (unsigned long long)subregion->size,
-               (unsigned long long)other->offset,
-               (unsigned long long)other->size);
+               subregion->name,
+               (unsigned long long)other->addr,
+               (unsigned long long)other->size,
+               other->name);

let me know if i should post a git patch instead :)

-- 
Michael



reply via email to

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