Re: [Xen-devel] [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader
>>> On 07.07.16 at 17:04, wrote: > On 07/07/2016 04:35 AM, Jan Beulich wrote: > On 06.07.16 at 18:32, wrote: >>> On 07/06/2016 12:04 PM, Roger Pau Monné wrote: On Tue, Jul 05, 2016 at 03:04:59PM -0400, Boris Ostrovsky wrote: > * Don't set HW_REDUCED_ACPI flags: this flag is only available starting > with > ACPI v5 Hm, I still think HW_REDUCED_ACPI should be set for the time being, considering that we don't provide PM timer or RTC for example. Not setting this would be a violation of the ACPI specification, and would mean introducing Xen specific hacks yet again to guest OSes, in order to disable those devices. Is the fact that HW_REDUCED_ACPI was introduced in ACPI v5 a problem? >>> Yes, because we build v2 tables and they are somewhat different. >> So couldn't we switch to building v5 tables (or even v6) for PVH >> (and perhaps re-using the "acpi=" config setting to allow specifying a >> version - with any value above 1 indicating the requested version)? I >> certainly agree that setting a v5 flag in a v2 table is bad (best we can >> hope for is that any consumer would ignore such a flag). > > Hmm... I thought earlier that v2 and v5(+) tables are different but now > that I went back this doesn't seem to be the case. It's v1 vs v2 that > changed formats. Yeah, they didn't repeat that mistake again. Jan > If that's the case (I'll check more carefully) then yes, we can provide > PVH guests with higher versions. > > -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader
On 07/07/2016 04:35 AM, Jan Beulich wrote: On 06.07.16 at 18:32, wrote: >> On 07/06/2016 12:04 PM, Roger Pau Monné wrote: >>> On Tue, Jul 05, 2016 at 03:04:59PM -0400, Boris Ostrovsky wrote: * Don't set HW_REDUCED_ACPI flags: this flag is only available starting with ACPI v5 >>> Hm, I still think HW_REDUCED_ACPI should be set for the time being, >>> considering that we don't provide PM timer or RTC for example. Not setting >>> this would be a violation of the ACPI specification, and would mean >>> introducing Xen specific hacks yet again to guest OSes, in order to disable >>> those devices. >>> >>> Is the fact that HW_REDUCED_ACPI was introduced in ACPI v5 a problem? >> Yes, because we build v2 tables and they are somewhat different. > So couldn't we switch to building v5 tables (or even v6) for PVH > (and perhaps re-using the "acpi=" config setting to allow specifying a > version - with any value above 1 indicating the requested version)? I > certainly agree that setting a v5 flag in a v2 table is bad (best we can > hope for is that any consumer would ignore such a flag). Hmm... I thought earlier that v2 and v5(+) tables are different but now that I went back this doesn't seem to be the case. It's v1 vs v2 that changed formats. If that's the case (I'll check more carefully) then yes, we can provide PVH guests with higher versions. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader
On 07/07/16 10:20, Jan Beulich wrote: On 07.07.16 at 11:14, wrote: On 07/07/16 09:35, Jan Beulich wrote: On 06.07.16 at 18:32, wrote: On 07/06/2016 12:04 PM, Roger Pau Monné wrote: On Tue, Jul 05, 2016 at 03:04:59PM -0400, Boris Ostrovsky wrote: * Don't set HW_REDUCED_ACPI flags: this flag is only available starting with ACPI v5 Hm, I still think HW_REDUCED_ACPI should be set for the time being, considering that we don't provide PM timer or RTC for example. Not setting this would be a violation of the ACPI specification, and would mean introducing Xen specific hacks yet again to guest OSes, in order to disable those devices. Is the fact that HW_REDUCED_ACPI was introduced in ACPI v5 a problem? Yes, because we build v2 tables and they are somewhat different. So couldn't we switch to building v5 tables (or even v6) for PVH (and perhaps re-using the "acpi=" config setting to allow specifying a version - with any value above 1 indicating the requested version)? I certainly agree that setting a v5 flag in a v2 table is bad (best we can hope for is that any consumer would ignore such a flag). FWIW, if we switch to ACPI v5.1 or later, it will be easier to merge the ACPI building code with ARM. I don't think we can outright switch to v5 or newer on x86 - old guests (say WinXP) may not be able to deal with that. Right. I meant that if you add support for ACPI v5 (or later) for PVH. It will also help to get a common ACPI build code with ARM. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader
>>> On 07.07.16 at 11:14, wrote: > On 07/07/16 09:35, Jan Beulich wrote: > On 06.07.16 at 18:32, wrote: >>> On 07/06/2016 12:04 PM, Roger Pau Monné wrote: On Tue, Jul 05, 2016 at 03:04:59PM -0400, Boris Ostrovsky wrote: > * Don't set HW_REDUCED_ACPI flags: this flag is only available starting > with ACPI v5 Hm, I still think HW_REDUCED_ACPI should be set for the time being, considering that we don't provide PM timer or RTC for example. Not setting this would be a violation of the ACPI specification, and would mean introducing Xen specific hacks yet again to guest OSes, in order to disable those devices. Is the fact that HW_REDUCED_ACPI was introduced in ACPI v5 a problem? >>> >>> Yes, because we build v2 tables and they are somewhat different. >> >> So couldn't we switch to building v5 tables (or even v6) for PVH >> (and perhaps re-using the "acpi=" config setting to allow specifying a >> version - with any value above 1 indicating the requested version)? I >> certainly agree that setting a v5 flag in a v2 table is bad (best we can >> hope for is that any consumer would ignore such a flag). > > FWIW, if we switch to ACPI v5.1 or later, it will be easier to merge the > ACPI building code with ARM. I don't think we can outright switch to v5 or newer on x86 - old guests (say WinXP) may not be able to deal with that. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader
On 07/07/16 09:35, Jan Beulich wrote: On 06.07.16 at 18:32, wrote: On 07/06/2016 12:04 PM, Roger Pau Monné wrote: On Tue, Jul 05, 2016 at 03:04:59PM -0400, Boris Ostrovsky wrote: * Don't set HW_REDUCED_ACPI flags: this flag is only available starting with ACPI v5 Hm, I still think HW_REDUCED_ACPI should be set for the time being, considering that we don't provide PM timer or RTC for example. Not setting this would be a violation of the ACPI specification, and would mean introducing Xen specific hacks yet again to guest OSes, in order to disable those devices. Is the fact that HW_REDUCED_ACPI was introduced in ACPI v5 a problem? Yes, because we build v2 tables and they are somewhat different. So couldn't we switch to building v5 tables (or even v6) for PVH (and perhaps re-using the "acpi=" config setting to allow specifying a version - with any value above 1 indicating the requested version)? I certainly agree that setting a v5 flag in a v2 table is bad (best we can hope for is that any consumer would ignore such a flag). FWIW, if we switch to ACPI v5.1 or later, it will be easier to merge the ACPI building code with ARM. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader
>>> On 06.07.16 at 18:32, wrote: > On 07/06/2016 12:04 PM, Roger Pau Monné wrote: >> On Tue, Jul 05, 2016 at 03:04:59PM -0400, Boris Ostrovsky wrote: >>> * Don't set HW_REDUCED_ACPI flags: this flag is only available starting >>> with ACPI v5 >> Hm, I still think HW_REDUCED_ACPI should be set for the time being, >> considering that we don't provide PM timer or RTC for example. Not setting >> this would be a violation of the ACPI specification, and would mean >> introducing Xen specific hacks yet again to guest OSes, in order to disable >> those devices. >> >> Is the fact that HW_REDUCED_ACPI was introduced in ACPI v5 a problem? > > Yes, because we build v2 tables and they are somewhat different. So couldn't we switch to building v5 tables (or even v6) for PVH (and perhaps re-using the "acpi=" config setting to allow specifying a version - with any value above 1 indicating the requested version)? I certainly agree that setting a v5 flag in a v2 table is bad (best we can hope for is that any consumer would ignore such a flag). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader
On 07/06/2016 12:04 PM, Roger Pau Monné wrote: > Hello, > > Thanks for the refresh! Do you have this series in some git tree I can pull > from? Sorry, forgot to include this in the message: git://oss.oracle.com/git/bostrovs/xen.git:acpi_v1 > > On Tue, Jul 05, 2016 at 03:04:59PM -0400, Boris Ostrovsky wrote: >> This is V1 of the series posted earlier as an RFC >> >> The goal here is to build ACPI tables for PVHv2/HVMlite guests while reusing >> existing >> hvmloader's ACPI builder code. The builder is provided as a library in >> tools/libacpi. >> >> Main changes from RFC are: >> * Move toolstack code that loads the tables into PVHv2 guest from libxc to >> libxl >> * Don't provide the builder to hypervisor as we didn't find a user for that >> (at least so far) >> * Update e820 map for PVHv2 guests when ACPI tables are loaded >> * Don't set HW_REDUCED_ACPI flags: this flag is only available starting with >> ACPI v5 > Hm, I still think HW_REDUCED_ACPI should be set for the time being, > considering that we don't provide PM timer or RTC for example. Not setting > this would be a violation of the ACPI specification, and would mean > introducing Xen specific hacks yet again to guest OSes, in order to disable > those devices. > > Is the fact that HW_REDUCED_ACPI was introduced in ACPI v5 a problem? Yes, because we build v2 tables and they are somewhat different. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader
Hello, Thanks for the refresh! Do you have this series in some git tree I can pull from? On Tue, Jul 05, 2016 at 03:04:59PM -0400, Boris Ostrovsky wrote: > This is V1 of the series posted earlier as an RFC > > The goal here is to build ACPI tables for PVHv2/HVMlite guests while reusing > existing > hvmloader's ACPI builder code. The builder is provided as a library in > tools/libacpi. > > Main changes from RFC are: > * Move toolstack code that loads the tables into PVHv2 guest from libxc to > libxl > * Don't provide the builder to hypervisor as we didn't find a user for that > (at least so far) > * Update e820 map for PVHv2 guests when ACPI tables are loaded > * Don't set HW_REDUCED_ACPI flags: this flag is only available starting with > ACPI v5 Hm, I still think HW_REDUCED_ACPI should be set for the time being, considering that we don't provide PM timer or RTC for example. Not setting this would be a violation of the ACPI specification, and would mean introducing Xen specific hacks yet again to guest OSes, in order to disable those devices. Is the fact that HW_REDUCED_ACPI was introduced in ACPI v5 a problem? Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader
This is V1 of the series posted earlier as an RFC The goal here is to build ACPI tables for PVHv2/HVMlite guests while reusing existing hvmloader's ACPI builder code. The builder is provided as a library in tools/libacpi. Main changes from RFC are: * Move toolstack code that loads the tables into PVHv2 guest from libxc to libxl * Don't provide the builder to hypervisor as we didn't find a user for that (at least so far) * Update e820 map for PVHv2 guests when ACPI tables are loaded * Don't set HW_REDUCED_ACPI flags: this flag is only available starting with ACPI v5 * Separate ACPI-specific definition from libacpi definitions (i.e. acpi2_0.h vs libacpi.h) * Add Processor objects to PVHv2's AML * Separate out ACPI INFO description into a separate ASL file * Specify ACPI INFO and tables' addresses in callers' code (not in acpi2_0.h) * Build ASL/C files in targets' directories (Jan suggested making symlinks, this is slightly different but serves similar goal of preventing paralell make from making a mess of targets) * Rework include files (x86.h), make callers specify include file that defines standard tools (see for example patch 13) * Reorder some patches to decrease code churn Other changes are described in patches (given number of changes I may have missed mentioning some). Boris Ostrovsky (20): hvmloader: Provide hvmloader_acpi_build_tables() acpi/hvmloader: Move acpi_info initialization out of ACPI code acpi/hvmloader: Initialize vm_gid data outside ACPI code acpi/hvmloader: Decide which SSDTs to install in hvmloader acpi/hvmloader: Move passthrough initialization from ACPI code acpi/hvmloader: Collect processor and NUMA info in hvmloader acpi/hvmloader: Set TIS header address in hvmloader acpi/hvmloader: Make providing IOAPIC in MADT optional acpi/hvmloader: Build WAET optionally acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops acpi/hvmloader: Translate all addresses when assigning addresses in ACPI tables acpi/hvmloader: Link ACPI object files directly acpi/hvmloader: Include file/paths adjustments acpi: Move ACPI code to tools/libacpi x86: Add more checks verifying that PIT/PIC/IOAPIC are emulated x86: Allow LAPIC-only emulation_flags for HVM guests libacpi: Build DSDT for PVH guests libxl/acpi: Add ACPI e820 entry libxl/pvhv2: Include APIC page in MMIO hole for PVHv2 guests libxl/acpi: Build ACPI tables for HVMlite guests .gitignore| 12 +- tools/firmware/hvmloader/Makefile | 20 +- tools/firmware/hvmloader/acpi/Makefile| 72 --- tools/firmware/hvmloader/acpi/README | 24 - tools/firmware/hvmloader/acpi/acpi2_0.h | 473 -- tools/firmware/hvmloader/acpi/build.c | 648 - tools/firmware/hvmloader/acpi/dsdt.asl| 480 -- tools/firmware/hvmloader/acpi/mk_dsdt.c | 489 --- tools/firmware/hvmloader/acpi/ssdt_pm.asl | 421 tools/firmware/hvmloader/acpi/ssdt_s3.asl | 31 -- tools/firmware/hvmloader/acpi/ssdt_s4.asl | 31 -- tools/firmware/hvmloader/acpi/ssdt_tpm.asl| 30 -- tools/firmware/hvmloader/acpi/static_tables.c | 170 --- tools/firmware/hvmloader/config.h |8 +- tools/firmware/hvmloader/hvmloader.c |3 +- tools/firmware/hvmloader/mp_tables.c |1 + tools/firmware/hvmloader/ovmf.c |4 +- tools/firmware/hvmloader/pci.c|1 + tools/firmware/hvmloader/pir.c|1 + tools/firmware/hvmloader/rombios.c|4 +- tools/firmware/hvmloader/seabios.c|5 +- tools/firmware/hvmloader/smp.c|1 + tools/firmware/hvmloader/util.c | 94 tools/firmware/hvmloader/util.h |4 + tools/libacpi/Makefile| 87 tools/libacpi/README | 33 ++ tools/libacpi/acpi2_0.h | 462 ++ tools/libacpi/build.c | 613 +++ tools/libacpi/dsdt.asl| 460 ++ tools/libacpi/dsdt_acpi_info.asl | 23 + tools/libacpi/libacpi.h | 128 + tools/libacpi/mk_dsdt.c | 499 +++ tools/libacpi/ssdt_pm.asl | 421 tools/libacpi/ssdt_s3.asl | 31 ++ tools/libacpi/ssdt_s4.asl | 31 ++ tools/libacpi/ssdt_tpm.asl| 30 ++ tools/libacpi/static_tables.c | 170 +++ tools/libacpi/x86.h | 38 ++ tools/libxc/include/xc_dom.h |4 + tools/libxl/Makefile | 19 +- tools/libxl/libxl_arch.h |3 + tools/libxl/libxl_dom.c
