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

[Julien Grall <julien.grall@xxxxxxx>]

On 07/07/16 10:20, Jan Beulich wrote:
> > > > On 07.07.16 at 11:14, <julien.grall@xxxxxxx> wrote:
> > On 07/07/16 09:35, Jan Beulich wrote:
> > > > > > On 06.07.16 at 18:32, <boris.ostrovsky@xxxxxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel