Re: [Xen-devel] [PATCH 0/9] x86/init: replace paravirt_enabled() were possible

["Luis R. Rodriguez" <mcgrof@suse.com>]

On Fri, Feb 19, 2016 at 01:34:59PM +0000, David Vrabel wrote:
> On 19/02/16 13:08, Luis R. Rodriguez wrote:
> > I originally set out to rename paravirt_enabled() to paravirt_legacy()
> > but we instead decided to remove paravirt_enabled() completely. Although
> > I have some linker table work which will help make this cleaner, instead
> > of waiting for that to go in, just remove the known cases that should
> > be safe for paravirt_enabled() and also replace it for the subarch
> > use.
> 
> I don't understand the purpose of this series.  How is replacing "if
> (A)" with "if (B)" an improvement?

Its about semantics. Let's recall I first set out to simply document
paravirt_enabled() as per Konrad's recommendation I also renamed it
to avoid confusion. What we've learned is that paravirt_enabled()'s
semantics were a mishap due to two main factors:

  1) Industry moving way from legacy:
    a) Exhibit A: PC system design guide  [0] - Move by Intel and
       Microsoft to help build legacy free systems.
    b) EXhibit B: ACPI IA-PC boot architecture flags (all for legacy)
  2) The array of different guest types during this time.

The best thing we had was subarch added via boot protocol 2.07
but as I've learned only lguest and a few hacks picked it up,
even though Xen clearly had a subarch added for it. The current
"grey" area of different guest types does not help, but this
just means we lack way to further describe things.

[0] http://tech-insider.org/windows/research/2000/1102.html

> Using the hardware subarch in this way looks like paravirt_enabled()
> with a slightly different flavour and I don't think this is that useful
> to determine if certain hardware features should be used.

I agree, and it was not my goal to just leave it like that.
The *real* way I am targeting use of the subarch is reflected
in how I am proposing we use linker tables and dependency
relationships on x86. Please refer to that series where
such annotations added here are removed. I posted this
series separately as otherwise the clutch to removal of
paravirt_enabled() is the progress on linker tables. That
may take time.

> I think you should consider a finer-grained set of feature bits.  e.g.,
> platform_has_pc_rtc() and platform_has_tboot() etc.

Are you suggesting as further x86 boot protocol changes?

  Luis