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

[Keir Fraser <keir.xen@gmail.com>]

On 25/10/2012 04:33, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 25/10/2012 00:51, "Olaf Hering" <olaf@aepfle.de> 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.

To be honest, given that the XenPVHVM extensions to Linux won't have been
tested on such old hypervisors, it wouldn't be a bad thing to bail on
setting up the extensions when you detect running on a really old Xen
version (e.g., earlier than 3.4.0) anyway. There's a fair chance of doing
more harm than good?

 -- Keir

>  -- Keir
> 
>> Olaf
> 
>