WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [RFC] change provided physical RAM map to add EBDA

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] change provided physical RAM map to add EBDA
From: Guillaume Thouvenin <guillaume.thouvenin@xxxxxxxxxxxx>
Date: Thu, 15 Mar 2007 08:45:01 +0000
Cc: Xen devel ML <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 15 Mar 2007 03:40:28 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1173875107.8591.25.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20070314110238.GA27518@xxxxxxxx> <1173875107.8591.25.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.13 (2006-08-11)
On Wed, Mar 14, 2007 at 12:25:07PM +0000, Ian Campbell wrote:
> > 
> >  Does it make sense to add support for EBDA in dom0 by changing the 
> > physical map? 
> > If not, what is the more appropriate solution to get information found in 
> > EBDA area 
> > from dom0?
> 
> Isn't the EBDA region at a known location? bios_ebda.h suggests that it
> is always at 0x40e0. In which case can't you just ioremap it?

Yes I think you're right, EBDA seems always located at 0x40E in physical
memory. I don' think that I can use ioremap because it is used to remap
I/O memory into kernel address space and it's not exactly what I need
here. But you're right, it could be a solution to map the machine
address 0x40E to a given pseudo physical address. My first idea was to
use set_gpfn_from_mfn(0x40E, 0x40E) from Xen but when I read at address 
0x40E from dom0 with the following code:

  /* The pointer to the EBDA is stored in the word @ phys 0x40E(40:0E) */
  ptr = *(unsigned short *)phys_to_virt(0x40Eul);
  ptr = (unsigned long)phys_to_virt(ptr << 4);
  printk(KERN_INFO "EBDA: ptr = 0x%lx\n", ptr);

ptr is equal to 0x0 instead of 0x99000 (which is where ebda area starts)
when it is read by the hypervisor. So if you have any hint about how to 
map 0x40E machine address to 0x40E pseudo physical address. As suggested 
by Bryan I also tried to use xc_map_foreign_range() but I miss the trick 
about how to use it. 

> If not then have a look at machine_e820 in i386 setup-xen.c (e820-xen.c
> on x86_64 I think) -- this is the real underlying e820 which is used to
> register the real physical memory resources in domain 0. Does this
> already contain the region you are talking about? 

It contains the region in linux but when it is compiled for xen (I mean
with CONFIG_XEN defined) all ebda stuff is just removed. So, as far as I 
understand, in domain0 the ebda is not set. 

> Or do you mean to
> create a completely artificial region that doesn't exist on real
> hardware?

My idea is to map the real memory region that contains EBDA to dom0. So
dom0 will see the real machine memory region under 640Ko (0xa0000) in is
own physical map. 

> Presumably much of the difference from native would be hidden in
> get_bios_ebda().

If I understand, the idea is to map the EBDA region somewhere in dom0 
address space and hide the mapping in get_bios_ebda(). I think it could
be a solution. 

So I will try to allocate memory space in dom0 to store ebda area, add
an hypercall to map the ebda area to the new allocated memory and modify
the get_bios_ebda() to read the correct address. If I didn't say to many
"silly" things, is this approach better than a new physical RAM map?

Regards,
Guillaume

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