From: Guillaume Thouvenin <guillaume.thouvenin@ext.bull.net>
To: Ian Campbell <Ian.Campbell@xensource.com>
Cc: Xen devel ML <xen-devel@lists.xensource.com>
Subject: Re: [RFC] change provided physical RAM map to add EBDA
Date: Thu, 15 Mar 2007 08:45:01 +0000 [thread overview]
Message-ID: <20070315084501.GA4830@bull.net> (raw)
In-Reply-To: <1173875107.8591.25.camel@localhost.localdomain>
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
next prev parent reply other threads:[~2007-03-15 8:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-14 11:02 [RFC] change provided physical RAM map to add EBDA Guillaume Thouvenin
2007-03-14 12:25 ` Ian Campbell
2007-03-15 8:45 ` Guillaume Thouvenin [this message]
2007-03-15 9:24 ` Ian Campbell
2007-03-15 10:55 ` Keir Fraser
2007-03-16 7:50 ` Guillaume Thouvenin
2007-03-15 11:57 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070315084501.GA4830@bull.net \
--to=guillaume.thouvenin@ext.bull.net \
--cc=Ian.Campbell@xensource.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.