[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to reserved memory area

  • To: Olaf Hering <olaf@xxxxxxxxx>
  • From: Keir Fraser <keir.xen@xxxxxxxxx>
  • Date: Thu, 25 Oct 2012 04:33:01 -0700
  • Cc: xen-devel@xxxxxxxxxxxxx
  • Delivery-date: Thu, 25 Oct 2012 11:33:42 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: Ac2ypH1KIVD5Vp78uUm04TvdLbIo9Q==
  • Thread-topic: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to reserved memory area

On 25/10/2012 00:51, "Olaf Hering" <olaf@xxxxxxxxx> wrote:

> On Thu, Oct 25, Olaf Hering wrote:
>> On Wed, Oct 24, Keir Fraser wrote:
>>> Which can be as simple as the attached patch (in fact all the changes apart
>>> from introducing GUEST_RESERVED_{START,END} are really cleaning up and
>>> bug-fixing the out-of-space checks in the mem_hole_alloc/mem_alloc
>>> functions).
>>> This then just requires that the guest maps shared-info to FE700000 itself.
>>> Should be quite easy. :)
>> The patch works for me. And the kernel patch I sent yesterday works as
>> well.
>> Is the memory area starting from 0xFC000000 also reserved in older
>> versions, such as Xen3?

It is marked as E820_RESERVED in the e820 map as far back as Xen-3.4.0
(released Spring 2009). Before that it was not covered by an e820 entry, and
there is a slim chance your guest kernel may decide to map something else at
FE700000 (PCI BAR remapping f.ex)?

> And if the guest runs on an older tool stack, is there a slim chance
> that something allocated memory up to 0xFE700000?

Again, back as far as at least Xen-3.4.0, nothing would ever have got mapped
at FE700000. Earlier than that, can't be as authoritative, but I think it's
very unlikely.

 -- Keir

> Olaf

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.