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

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



>>> On 15.12.14 at 17:15, <stefano.stabellini@xxxxxxxxxxxxx> 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?

Of course.

> 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.

Right. Plus the kernel is free to extend the region(s) perceived as
RAM in the E820 is sees (makes up) at boot time.

>> It's solely the guest kernel's responsibility
>> to make sure its ballooning activities don't collide with anything
>> else address-wise.
> 
> In the sense that it is in the guest kernel's responsibility to use the
> interface properly.

That's a given for this discussion. The important aspect is that neither
tools nor hypervisor have any influence on how a PV kernel
partitions its PFN space - the only thing they control is the boot time
state thereof.

Jan


_______________________________________________
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®.