All of lore.kernel.org
 help / color / mirror / Atom feed
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

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