qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [patch 2/2] i386: pc: align gpa<->hpa on 1GB boundary


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [patch 2/2] i386: pc: align gpa<->hpa on 1GB boundary
Date: Fri, 25 Oct 2013 09:52:34 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9

Il 25/10/2013 05:58, Marcelo Tosatti ha scritto:
> On Fri, Oct 25, 2013 at 12:55:36AM +0100, Paolo Bonzini wrote:
>>> +        if (hpagesize == (1<<30)) {
>>> +            unsigned long holesize = 0x100000000ULL - below_4g_mem_size;
>>> +
>>> +            memory_region_init_alias(ram_above_4g, NULL, "ram-above-4g", 
>>> ram,
>>> +                                    0x100000000ULL,
>>> +                                    above_4g_mem_size - holesize);
>>> +            memory_region_add_subregion(system_memory, 0x100000000ULL,
>>> +                                    ram_above_4g);
>>> +
>>> +            ram_above_4g_piecetwo = 
>>> g_malloc(sizeof(*ram_above_4g_piecetwo));
>>> +            memory_region_init_alias(ram_above_4g_piecetwo, NULL,
>>> +                                     "ram-above-4g-piecetwo", ram,
>>> +                                     0x100000000ULL - holesize, holesize);
>>> +            memory_region_add_subregion(system_memory,
>>> +                                        0x100000000ULL +
>>> +                                        above_4g_mem_size - holesize,
>>> +                                        ram_above_4g_piecetwo);
>>
>> Why break it in two?  You can just allocate extra holesize bytes in the
>> "ram" MemoryRegion, and not map the part that corresponds to
>> [0x100000000ULL - holesize, 0x100000000ULL).
> 
> - If the "ram" MemoryRegion is backed with 1GB hugepages, you might not 
> want to allocate extra holesize bytes (which might require an entire
> 1GB page).
> 
> - 1GB backed RAM can be mapped with 2MB pages.
> 
>> Also, as Peter said this cannot depend on host considerations.  Just do
>> it unconditionally, but only for new machine types (pc-1.8 and q35-1.8,
>> since unfortunately we're too close to hard freeze).
> 
> Why the description of memory subregions and aliases are part of machine
> types?

It affects the migration stream, which stores RAM offsets instead of
physical addresses.

Let's say you have an 8 GB guest and the hole size is 0.25 GB.

If the huge page size is 2MB, you have:

       Physical address            Length           RAM offsets
       0                           3.75 GB          pc.ram @ 0
       4 GB                        4.25 GB          pc.ram @ 3.75 GB

If the huge page size is 1GB, you have:

       Physical address            Length           RAM offsets
       0                           3.75 GB          pc.ram @ 0
       4 GB                        4 GB             pc.ram @ 4 GB
       8 GB                        0.25 GB          pc.ram @ 3.75 GB

So your memory "rotates" around the 3.75 GB boundary when you migrate
from a non-gbpages host to a gbpages host or vice versa.

If we're doing it only for new machine types, it's even simpler to just
have two RAM regions:

       Physical address            Length           RAM offsets
       0                           3.75 GB          pc.ram-below-4g @ 0
       4 GB                        4.25 GB          pc.ram-above-4g @ 0

Because offsets are zero, and lengths match the RAM block lengths, you
do not need any complication with aliasing.  This still has to be done
only for new machine types.

Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]