Re: [Xen-devel] One question about the hypercall to translate gfn to mfn.

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 15/12/14 16:15, Stefano Stabellini wrote:
> On Mon, 15 Dec 2014, Jan Beulich wrote:
>>>>> On 15.12.14 at 16:22, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>>> On Mon, 15 Dec 2014, Jan Beulich wrote:
>>>>>>> On 15.12.14 at 10:05, <kevin.tian@xxxxxxxxx> wrote:
>>>>> yes, definitely host RAM is the upper limit, and what I'm concerning here
>>>>> is how to reserve (at boot time) or allocate (on-demand) such large PFN
>>>>> resource, w/o collision with other PFN reservation usage (ballooning
>>>>> should be fine since it's operating existing RAM ranges in dom0 e820
>>>>> table).
>>>>
>>>> I don't think ballooning is restricted to the regions named RAM in
>>>> Dom0's E820 table (at least it shouldn't be, and wasn't in the
>>>> classic Xen kernels).
>>>
>>> Could you please elaborate more on this? It seems counter-intuitive at best.
>>
>> I don't see what's counter-intuitive here. How can the hypervisor
>> (Dom0) or tool stack (DomU) know what ballooning intentions a
>> guest kernel may have?
> 
> The hypervisor checks that the memory the guest is giving back is
> actually ram, as a consequence the ballooning interface only supports
> ram. Do you agree?
> 
> Ballooning is restricted to regions named RAM in the e820 table, because
> Linux respects e820 in its pfn->mfn mappings. However it is true that
> respecting the e820 in dom0 is not part of the interface.

Linux will quite happily allow you to add memory outside of the initial
e820 RAM regions.  The current balloon driver even supports this using
the kernel's generic memory hotplug infrastructure.

David

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