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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 13 Jul 2016, Julien Grall wrote:
> Hello,
> 
> On 12/07/2016 17:58, Boris Ostrovsky wrote:
> > On 07/12/2016 12:10 PM, Julien Grall wrote:
> > > On 12/07/2016 16:08, Boris Ostrovsky wrote:
> > > > On 07/12/2016 10:57 AM, Shannon Zhao wrote:
> > > > > On 2016年07月12日 22:50, Wei Liu wrote:
> > > > > > On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > Does it mean we would need
> > > > > > > > > > > > > > > > > > > > > > > > > > to update the slack
> > > > > > > > > > > > > > > > > > > > > > > > > > to take into account the
> > > > > > > > > > > > > > > > > > > > > > > > > > ACPI
> > > > > > > > > > > > > > > > > > > > > > > > > > blob?
> > > > > > > > > > > > > > > > > > Yes, we need to take into account the ACPI
> > > > > > > > > > > > > > > > > > blob.
> > > > > > > > > > > > > > > > > > Probably not in the
> > > > > > > > > > > > > > > > > > slack but directly in mam_memkb.
> > > > > > > > > > > > > > Sorry, I'm not sure understand this. I found the
> > > > > > > > > > > > > > b_info->max_memkb but
> > > > > > > > > > > > > > didn't find the slack you said. And how to fix this?
> > > > > > > > > > > > > > Update
> > > > > > > > > > > > > > b_info->max_memkb or the slack?
> > > > > > > > > > Can you calculate the size of your payload and add that to
> > > > > > > > > > max_memkb?
> > > > > > > > > > 
> > > > > > > > Yeah, but the size will be changed if we change the tables in
> > > > > > > > the
> > > > > > > > future
> > > > > > > > and this also should consider x86, right?
> > > > > > That could easily be solved by introducing a function to calculate
> > > > > > the
> > > > > > size, right?
> > > > > Oh, I'm not familiar with this. Let's clarify on this. It can add the
> > > > > size to max_memkb after generating the ACPI tables and before loading
> > > > > the tables to guest space and it doesn't have to add the size at
> > > > > libxl__domain_build_info_setdefault(), right?
> > > > 
> > > > This was discussed before: ACPI tables are part of RAM whose size is
> > > > specified by the config file (and is reflected in max_memkb I believe).
> > > > It may not be presented to the guest as RAM (i.e. on x86 it is labeled
> > > > by BIOS (or whoever) as a dedicated type in e820) but it still resides
> > > > in DIMMs.
> > > 
> > > I don't think this was the conclusion of the thread. IHMO, "maxmem" is
> > > the amount of RAM a guest could effectively use.
> > > 
> > > Whilst the ACPI tables will be in the DIMM from the host point of
> > > view. From a guest point of view it will be a ROM.
> > 
> > The config file specifies resources provided by the host. How the guest
> > views those resources is not important, I think.
> 
> This would need to be clarified. For instance special pages (Xenstore,
> Console...) are RAM from the host point of view but not taken into account in
> the "maxmem" provided by the user. For my understanding, some kB of the slack
> is used for that.
> 
> > 
> > > 
> > > It will affect some others part of the guest if we don't increment the
> > > "maxmem" requested by the user. For ARM the ACPI blob will be exposed
> > > at a specific address that is outside of the guest RAM (see the guest
> > > memory layout in public/arch-arm.h).
> > > 
> > > We chose this solution over putting in the RAM because the ACPI tables
> > > are not easily relocatable (compare to the device tree, initrd and
> > > kernel) so we could not take advantage of superpage in both stage-2
> > > (hypervisor) and stage-1 (kernel) page table.
> > 
> > Maybe this is something ARM-specific then. For x86 we will want to keep
> > maxmem unchanged.
> 
> I don't think what I described in my previous mail is ARM-specific. The
> pressure will be more important on the TLBs, if Xen does not use superpage in
> the stage 2 page tables (i.e EPT for x86) no matter the architecture.
> 
> IHMO, this seems to be a bigger drawback compare to add few more kilobytes to
> maxmem in the toolstack for the ACPI blob. You will loose them when creating
> the intermediate page table in any case.

I agree with Julien. On ARM we have to increase maxmem because I don't
think that shattering a superpage is acceptable for just a few KBs. In
fact, it's not much about increasing maxmem, but it's about keeping the
allocation of guest memory to the value passed by the user in "memory",
so that it can be done in the most efficient way possible. (I am
assuming users are going to allocate VMs of 2048MB, rather than 2049MB.)

I wouldn't want to end up adding to the performance tuning page on the
wiki "Make sure to add 1 more MB to the memory of your VM to get the
most out of the system."

I know that the location of the ACPI blob on x86 is different in guest
memory space, but it seems to me that the problem would be the same. Do
you have 1 gigabyte pages in stage-2 on x86? If so, I would think twice
about this. Otherwise, if you only have 4K and 2MB allocations, then it
might not make that much of a difference.

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