Re: [Xen-devel] [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader

[Jan Beulich]

>>> 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

[Boris Ostrovsky]

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

[Julien Grall]

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

[Jan Beulich]

>>> 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

[Julien Grall]

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

[Jan Beulich]

>>> 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

[Boris Ostrovsky]

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

[Roger Pau Monné]

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

[Boris Ostrovsky]

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