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: Marcelo Tosatti
Subject: Re: [Qemu-devel] [patch 2/2] i386: pc: align gpa<->hpa on 1GB boundary
Date: Fri, 25 Oct 2013 11:34:22 -0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Oct 25, 2013 at 11:57:18AM +0200, igor Mammedov wrote:
> On Fri, 25 Oct 2013 02:58:05 -0200
> Marcelo Tosatti <address@hidden> wrote:
> 
> > 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).
> From POV of moddeling current "ram" as dimm devices, aliasing
> wouldn't work nice. But breaking one block in two or more is fine since
> then blocks could be represented as several dimm devices.
> 
> +3Gb backend ram it could be split in blocks like this:
> 
>   [ 3Gb (1Gb pages backed) ]
>   [tail1 (below_4gb - 3Gb) (2mb pages backed) ]
>   [above_4gb whole X Gb pages (1Gb pages backed)]
>   [tail2 (2mb pages backed)]

Yes, thought of that, unfortunately its cumbersome to add an interface
for the user to supply both 2MB and 1GB hugetlbfs pages.




reply via email to

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