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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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.


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

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