Re: [Xen-devel] [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall <julien.grall@xxxxxxx>]

Hi Shannon,

Sorry for the late answer.

On 25/07/16 08:56, Shannon Zhao wrote:
> On 2016/7/20 17:32, Wei Liu wrote:
> > On Wed, Jul 20, 2016 at 02:52:05PM +0800, Shannon Zhao wrote:
> > > > On 2016/7/19 18:38, Wei Liu wrote:
> > > > > > On Fri, Jul 15, 2016 at 05:39:32PM +0800, Shannon Zhao wrote:
> > > > > > [...]
> > > > > > > > > > > > > > It would be trivial to have another option in xl.cfg to allow MB
> > > > > > > > > > > > > > granularity. But I don't think that's a good idea. Asking for more
> > > > > > > > > > > > > > memory when you don't really know how much is enough is not very useful.
> > > > > > > > > > > > > > If an admin can know how much is needed, surely the library can be
> > > > > > > > > > > > > > taught to obtain that knowledge, too.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > We need to decide which model we should go with. And, if we decide to
> > > > > > > > > > > > > > diverge, document the difference between x86 and ARM model.
> > > > > > > > > > Hi Wei,
> > > > > > > > > >
> > > > > > > > > > Do you decide how to add the size of ACPI blob to max_memkb?
> > > > > > AFAICT ARM and x86 maintainers hold different opinions on how memory
> > > > > > should be accounted.
> > > > > >
> > > > > > I would like to have a unified memory accounting model. But if we can't
> > > > > > have that at the moment, I'm fine with divergence, but please document
> > > > > > it somewhere (comment near code snippet, in header, or a file under docs
> > > > > > etc). And the amount added to max_memkb needs to be properly calculated,
> > > > > > not some magic number, so that we have a chance in the future to
> > > > > > confidently change how we do thing.
> > > > If it's only allowed to add the size to max_memkb in
> > > > libxl__domain_build_info_setdefault(), it only can use a const number
> > > > since the tables are not generted and we don;t know the size. But the
> > > > const number could be chosen properly since we could know the maximum
> > > > ACPI tables size of current ARM approach.
> > > >
> > > > But maybe in the future, if we add some new ACPI tables, it should
> > > > increase the size as well. So I think this should be documented.
> > > >
> > > > As I asked before, is it ok to add the size to max_memkb after
> > > > generating the ACPI tables and before loading the tables to guest space?
> > Yes. I don't think shoehorning everything into setdefault is a good
> > idea.
> >
> > I think libxl_arm.c:libxl__arch_domain_create would be the right place
> > to do it.
> >
> > I am thinking about calling xc_domain_setmaxmem there, but not adding a
> > number to d_config->b_info.max_memkb. Adding that to ->max_memkb would
> > be wrong because the bigger ->max_memkb will be recored and the same
> > algorithm will be applied every time you migrate your guest, so the
> > max_memkb will grow bigger and bigger.
> >
> > Given the different approach taken by ARM and x86, maybe we need to also
> > record the size of acpi blobs somewhere in xenstore (also needs to be
> > documented) so that subsequent libxl_domain_setmaxmem can extract that
> > number again.
> >
> > Please wait a bit for Stefano and Julien to comment before you do work.
> Stefano, Julien,
> Any comments regarding how to add the ACPI size to max_memkb?
I think Wei's suggestion is a good one.

Cheers,

--
Julien Grall

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