From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53312) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzigC-00013E-SL for qemu-devel@nongnu.org; Thu, 27 Oct 2016 07:17:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzig8-0000B4-4Q for qemu-devel@nongnu.org; Thu, 27 Oct 2016 07:17:04 -0400 Received: from [209.132.183.28] (port=35186 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bzig7-00005A-Sb for qemu-devel@nongnu.org; Thu, 27 Oct 2016 07:17:00 -0400 Date: Thu, 27 Oct 2016 12:57:45 +0200 From: Igor Mammedov Message-ID: <20161027125745.6f4ed84d@nial.brq.redhat.com> In-Reply-To: <20161026152234.GQ30231@citrix.com> References: <1477416484-29054-1-git-send-email-wei.liu2@citrix.com> <20161026170952.18c02dbb@nial.brq.redhat.com> <20161026152234.GQ30231@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC] acpi: don't build acpi tables for xen hvm guests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wei Liu Cc: Anthony PERARD , Xen-devel , Stefano Stabellini , qemu-devel@nongnu.org On Wed, 26 Oct 2016 16:22:34 +0100 Wei Liu wrote: > On Wed, Oct 26, 2016 at 05:09:52PM +0200, Igor Mammedov wrote: > > On Tue, 25 Oct 2016 18:28:04 +0100 > > Wei Liu wrote: > > > > > Xen's toolstack is in charge of building ACPI tables. Skip acpi table > > > building if running on Xen. > > > > > > This issue is discovered due to direct kernel boot on Xen doesn't boot > > > anymore, because the new ACPI tables cause the guest to exceed its > > > memory allocation limit. > > > > > > Reported-by: Sander Eikelenboom > > > Signed-off-by: Wei Liu > > Question is: > > Why does xen guest get ACPI tables from QEMU instead of using > > Xen provided ones. > > Maybe it's firmware issue i.e. firmware side shouldn't load > > ACPI tables from QEMU provided fwcfg file and load Xen provided instead. > > > > It hasn't come to the point that the guest is booted. QEMU exits when > trying to populate some pages for the guest, at which point the guest > has not yet been started. In a sense, Xen guest doesn't get ACPI from > QEMU because it never gets to that point. > > Direct kernel boot causes fw_cfg to be filled in. pcms->has_acpi_build > defaults to true and acpi_enabled is also true. These make all checks in > acpi_setup pass. QEMU proceeds to build and load ACPI tables (which are > never going to be used by Xen guests), causing the guest to exceeds its > limit. > > Wei. would something like this work for you? diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index a54a468..61b6026 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -1094,10 +1094,13 @@ DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa, #ifdef CONFIG_XEN static void xenfv_machine_options(MachineClass *m) { + PCMachineClass *pcmc = PC_MACHINE_CLASS(m); + m->desc = "Xen Fully-virtualized PC"; m->max_cpus = HVM_MAX_VCPUS; m->default_machine_opts = "accel=xen"; m->hot_add_cpu = pc_hot_add_cpu; + pcmc->has_acpi_build = false; } DEFINE_PC_MACHINE(xenfv, "xenfv", pc_xen_hvm_init, > > > > --- > > > Cc: Anthony PERARD > > > Cc: Stefano Stabellini > > > > > > RFC because I'm not sure this is the best way to fix it. > > > --- > > > hw/i386/acpi-build.c | 6 ++++++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c > > > index a26a4bb..2cdff12 100644 > > > --- a/hw/i386/acpi-build.c > > > +++ b/hw/i386/acpi-build.c > > > @@ -45,6 +45,7 @@ > > > #include "sysemu/tpm_backend.h" > > > #include "hw/timer/mc146818rtc_regs.h" > > > #include "sysemu/numa.h" > > > +#include "hw/xen/xen.h" > > > > > > /* Supported chipsets: */ > > > #include "hw/acpi/piix4.h" > > > @@ -2865,6 +2866,11 @@ void acpi_setup(void) > > > return; > > > } > > > > > > + if (xen_enabled()) { > > > + ACPI_BUILD_DPRINTF("Xen enabled. Bailing out.\n"); > > > + return; > > > + } > > > + > > > build_state = g_malloc0(sizeof *build_state); > > > > > > acpi_set_pci_info(); > > >