Re: Re: Mini-OS in dom0 - virtual memory problems

[Grzegorz Milos <gm281@cam.ac.uk>]

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

>> Mini-OS assumes that the start of the text section is also the 
>> beginning of virtual address space[1]. However, it is generally bad 
>> idea not to start virtual address space at 4Mb boundary. The easiest 
>> way to fix your problem is to move text to 0xc0000000 or 0xc0400000. 
>> More extensive fix, which decouples VIRT_START from &_text is also 
>> possible, but I don't see a reason why it would be needed. Instead 
>> I've included a runtime check. Keir could you apply the patch?
> 
> I changed the beginning of text to 0xC0000000 and the page table setup 
> seems to work, as does the rest of Mini-OS (except XenBus of course). 
> Thank you very much!

There was indeed a XenBus bug, where request structures wouldn't be 
marked as free (Keir could you apply the attached patch?), however I 
don't think that's what you are referring to. What problems do you observe?

Cheers
Gregor

[-- Attachment #2: mini-os.patch --]
[-- Type: text/plain, Size: 644 bytes --]

diff -r 34ab61cd89bb extras/mini-os/xenbus/xenbus.c
--- a/extras/mini-os/xenbus/xenbus.c	Tue Jan 30 21:26:45 2007 +0000
+++ b/extras/mini-os/xenbus/xenbus.c	Wed Jan 31 23:57:41 2007 +0000
@@ -178,6 +178,7 @@ static void release_xenbus_id(int id)
     BUG_ON(!req_info[id].in_use);
     spin_lock(&req_lock);
     nr_live_reqs--;
+    req_info[id].in_use = 0;
     if (nr_live_reqs == NR_REQS - 1)
         wake_up(&req_wq);
     spin_unlock(&req_lock);
@@ -212,6 +213,7 @@ static int allocate_xenbus_id(void)
     probe = o_probe + 1;
     spin_unlock(&req_lock);
     init_waitqueue_head(&req_info[o_probe].waitq);
+
     return o_probe;
 }
 

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel