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

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



Hi George,

On 25/07/16 09:38, George Dunlap wrote:
On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini
<sstabellini@xxxxxxxxxx> wrote:
You are assuming that the guest will map the ACPI blob with the same
attributes as the rest of the superpage.

IHMO, a sane operating system will want to map the ACPI blob read-only.

That's true. But there are other things which might be mapped
differently and could shatter a stage-1 superpage mapping (especially on
x86 that has a much more complex memory map than ARM). Obviously adding
one more is not doing it any good, but it might not make a difference in
practice.

Anyway, I agree with Julien that his suggestion is the best for ARM. If
the libxl maintainers are willing to accept two different code paths for
this on ARM and x86, then I am fine with it too.

Sorry to be a bit late to this thread -- there's a interface principle
that I think we should at some point have a larger discussion about:
whether "maxmem" means the amount of RAM which the guest sees as RAM,
or whether "maxmem" means the amount of RAM that the administrator
sees as used by the guest.  At the moment tnhere's no consistent
answer actually; but I am strongly of the opinion that for usability
the best answer is for "memory" to be the *total* amount of *host*
memory used by the guest.  In an ideal world, the admin should be able
to do "xl info", see that there is 3000MiB free, and then start a
guest with 3000MiB and expect it to succeed.  At the moment he has to
guess.

To confirm, do you include memory allocated by the hypervisor to keep track of the guest (i.e struc domain, struct vcpu...)?

If not, the problem stays the same because the admin will have to know how much memory Xen will allocate to keep track of the guest. So if "xl info" tells you that 3000MiB is free, you will only be able to use 3000MiB - few kilobytes.

If yes, this would be a problem for migration because a newer version of Xen may allocate less/more memory.

Furthermore, with this suggestion, we will likely not be able to take advantage of 1GB superpage unless the admin knows how much memory will be used by Xen outside of the guest RAM (such as the console page, xenstore page, ....).

IHMO, it would be easier if we define "maxmem" as the usable for guest RAM and then let the toolstack take add the extra memory (ACPI blob, special pages...).

Regards,

--
Julien Grall

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.