qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v18 13/14] memory backend: fill memory backend r


From: Marcelo Tosatti
Subject: Re: [Qemu-devel] [PATCH v18 13/14] memory backend: fill memory backend ram fields
Date: Wed, 26 Feb 2014 09:58:14 -0300
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Feb 26, 2014 at 01:45:38PM +0100, Paolo Bonzini wrote:
> Il 26/02/2014 13:31, Igor Mammedov ha scritto:
> >>> The problem is that some backends might not be handled the same way.
> >>> For example, not all backends might produce a single void*/size_t pair
> >>> for the entire region.  Think of a "composite" backend that produces a
> >>> large memory region from two smaller ones.
> >I'd prefer to keep backends simple, with 1:1 mapping to memory regions.
> 
> I agree.  However not all backends may have a mapping to a RAM
> memory region.  A composite backend could create a container memory
> region whose children are other HostMemoryBackend objects.
> 
> >Is there a need in composite one or something similar?
> 
> I've heard of users that want a node backed partially by hugetlbfs
> and partially by regular RAM.  Not sure why.
> 
> Paolo

To overcommit the non hugetlbfs backed guest RAM (think guest pagecache on that 
non
hugetlbfs backed memory, swappable and KSM-able).

The problem is, you have to in someway guarantee the guest allocates 
1GB pages out of the hugetlb backed GPA ranges. Some thoughts
(honestly, dislike all of them):

1) Boot guest with hugepages, allocate hugepages in guest,
later on hotplug 4K backed ranges. HV-unaware reboot might fail,
though.

2) Communicate hugepage GPAs to guest.

3) Create holes in non hugepage backed GPA range.






reply via email to

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