From: Keir Fraser <keir.xen@gmail.com>
To: Kevin O'Connor <kevin@koconnor.net>,
Julian Pidancet <julian.pidancet@gmail.com>
Cc: xen-devel@lists.xensource.com, seabios@seabios.org,
ian.campbell@citrix.com
Subject: Re: Re: [PATCH] SeaBIOS/Xen: Compute the low RAM memory size in the BDA according to the e820
Date: Mon, 14 Nov 2011 08:53:53 +0000 [thread overview]
Message-ID: <CAE687A1.24CDF%keir.xen@gmail.com> (raw)
In-Reply-To: <20111114033618.GA30104@morn.localdomain>
On 14/11/2011 03:36, "Kevin O'Connor" <kevin@koconnor.net> wrote:
>> Like I said, I'm not an ACPI expert. But let say we decide to move
>> this ACPI info structure to some other area, where there's less risk
>> for it to be overwritten, like somewhere above 0xFC000000, wouldn't
>> that prevent some Operating System with limited memory capabilities to
>> access it ?
>
> If the OS can handle AML it can handle 32bit addresses.
>
>> Besides, it seems that SeaBIOS manages itself the space between
>> 0xFC000000 and 4G, so it seems difficult to imagine to have a reserved
>> space with a fixed address in there.
>
> On Xen, the PCI init code isn't used, so assuming this struct doesn't
> need to live in real "ram", I think it could live just about anywhere
> past the end of ram. Even with pciinit.c, addresses over 0xfc00000
> (with the exception of a few bytes for hpet, apic, ioapic, and bios
> image) could be used.
I suggest we stick it at FC000000, and shift hvmloader's mem_alloc()
starting address up by one page to FC001000. The acpi build code will have
to manually mem_hole_populate_ram() that one page before writing to it. This
can then be documented in hvmloader/config.h which contains a description
of, and defines for, the system memory map. This is by far the easiest
solution to this problem; manually crafting an SSDT is a right pain in the
arse, whereas this is maybe a 5-line patch.
-- Keir
> -Kevin
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2011-11-14 8:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-14 1:50 [PATCH] SeaBIOS/Xen: Compute the low RAM memory size in the BDA according to the e820 Julian Pidancet
2011-11-14 1:11 ` Kevin O'Connor
2011-11-14 2:03 ` Julian Pidancet
2011-11-14 2:09 ` Kevin O'Connor
2011-11-14 2:48 ` Julian Pidancet
2011-11-14 3:36 ` Kevin O'Connor
2011-11-14 7:37 ` Rudolf Marek
2011-11-14 8:53 ` Keir Fraser [this message]
2011-11-14 13:23 ` Keir Fraser
2011-11-14 13:27 ` Julian Pidancet
2011-11-14 13:43 ` Kevin O'Connor
2011-11-14 19:25 ` [Xen-devel] " Julian Pidancet
2011-11-14 20:16 ` Keir Fraser
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=CAE687A1.24CDF%keir.xen@gmail.com \
--to=keir.xen@gmail.com \
--cc=ian.campbell@citrix.com \
--cc=julian.pidancet@gmail.com \
--cc=kevin@koconnor.net \
--cc=seabios@seabios.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).