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

Re: [Xen-devel] HVM support for e820_host (Was: Bug: Limitation of <=2GB RAM in domU persists with 4.3.0)



Gordan Bobic <gordan@xxxxxxxxxx> wrote:
> On Wed, 4 Sep 2013 22:04:42 -0400, Konrad Rzeszutek Wilk 
> <konrad.wilk@xxxxxxxxxx> wrote:
>
>> diff --git a/tools/firmware/hvmloader/e820.h
>> b/tools/firmware/hvmloader/e820.h
>> index b2ead7f..2fa700d 100644
>> --- a/tools/firmware/hvmloader/e820.h
>> +++ b/tools/firmware/hvmloader/e820.h
>> @@ -8,6 +8,9 @@
>>  #define E820_RESERVED     2
>>  #define E820_ACPI         3
>>  #define E820_NVS          4
>> +#define E820_UNUSABLE     5
>> +
>> +#define E820MAX         128
>>
>>  struct e820entry {
>>      uint64_t addr;
>
> I don't think we actually need
> +#define E820_UNUSABLE     5
>
> any more because it is no longer used anywhere
> in the patch. Do we need that extra e820 hole type?

You could extend the dump_e820... code to print that type as well 
> I guess it's only useful if we want to explicitly
> signify that a memory hole is inherited from
> the host e820 map, rather than _really_ needed.
> Otherwise we could probably just use E820_RESERVED
> in it's place.

Originally it was used to cover area that are RAM in the host but won't be RAM 
in the guest because the amount of memory the guest has is less then the 
physical amount. 

>
> Gordan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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