[RFC] change provided physical RAM map to add EBDA

[RFC] change provided physical RAM map to add EBDA

[Guillaume Thouvenin]

   
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?


 Regards,
 Guillaume

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

[Ian Campbell]

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.

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

[Guillaume Thouvenin]

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

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

[Ian Campbell]

On Thu, 2007-03-15 at 08:45 +0000, Guillaume Thouvenin wrote:
> 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.

That's segment 0x40e I think -- therefore address 0x40e0.

>  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.

I think it is precisely what you need here. You want to map a machine
physical region of memory into the kernel. Because we register I/O
resources base on machine_e820 (i.e. the real physical e820 map) in
domain 0 ioremap will map real physical regions as required.

> > 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. 

The only stuff I see which is commented out is quirk handling for
certain Dell machines which don't correctly reserve the EBDA area in the
e820. If you have such a machine then you will need to re-enable this
and make it act on machine_e820 instead of the regular e820. For all
other machines it shouldn't matter.

> > 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. 

This map already exits -- it is the machine_e820 map.

Ian.

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

[Keir Fraser]

On 15/3/07 08:45, "Guillaume Thouvenin" <guillaume.thouvenin@ext.bull.net>
wrote:

> 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.

You're creating difficulties where there are none: dom0 already has a
mapping of all memory below 1MB. Just use isa_bus_to_virt(0x40e).

 -- Keir

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

[Guillaume Thouvenin]

On Thu, Mar 15, 2007 at 10:55:26AM +0000, Keir Fraser wrote:
> On 15/3/07 08:45, "Guillaume Thouvenin" <guillaume.thouvenin@ext.bull.net>
> wrote:
> 
> > 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.
> 
> You're creating difficulties where there are none: dom0 already has a
> mapping of all memory below 1MB. Just use isa_bus_to_virt(0x40e).

Thank you for pointing the isa_bus_to_virt(), I had missed that.
I will look this solution quickly.

Best Regards,
Guillaume

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

[Alan Cox]

> Yes I think you're right, EBDA seems always located at 0x40E in physical

0x040E physical contains either the real mode segment of the EBDA at
0x40E or may be zero on some systems if no EBDA block is present. On the
same machine you'll sometimes find the EBDA vanishes or appears depending
upon whether a PS/2 mouse is plugged in which can be handy for debug.

> 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. 

This would be useful, and also useful for things like emulators.

Alan