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

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Wed, 2007-03-14 at 11:02 +0000, Guillaume Thouvenin wrote:
>    Hello
> 
>  When dom0 starts, we can see that Xen is provided a uniform pseudo physical
> RAM map. For example for a dom0 with 1GB of RAM we can see:
>  
>     BIOS-provided physical RAM map:
>     Xen: 0000000000000000 - 0000000040800000 (usable)
> 
>  If I need to use data provided by EBDA, is it possible to change how Xen 
> provides information to dom0? My idea was to provide something like this:
>   
>     BIOS-provided physical RAM map:
>     Xen: 0000000000000000 - 0000000000099000 (usable)
>     Xen: 0000000000099000 - 00000000000a0000 (reserved for EBDA)
>     Xen: 00000000000a0000 - 0000000040800000 (usable)
> 
>  where memory from 99000 to a0000 is a direct mapping to machine address. By
> doing this, dom0 will be able to access the extended BIOS data area. This will
> allow to port pieces of code that are using EBDA area. I'm thinking about
> MP-table parsing routines found in arch/i386/kernel/mpparse.c or IBM summit
> code found in arch/i386/kernel/summit.c. Also we can see in
> arch/x86_64/kernel/setup-xen.c that currently the code that deals with ebda
> is just removed.
> 
>  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?

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? Or do you mean to
create a completely artificial region that doesn't exist on real
hardware?

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

Ian.



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