From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] tools/hvmloader: move shared_info to reserved memory area Date: Thu, 25 Oct 2012 04:33:01 -0700 Message-ID: References: <20121025075106.GA16484@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20121025075106.GA16484@aepfle.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Olaf Hering Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 25/10/2012 00:51, "Olaf Hering" 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