Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1338171 > unrolled thread

[PATCH 0/9] x86/init: replace paravirt_enabled() were possible

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/9] x86/init: replace paravirt_enabled() were possible "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-19 14:10 +0100
    [PATCH 8/9] x86/rtc: replace paravirt_enabled() check with subarch check "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-19 14:10 +0100
      Re: [Xen-devel] [PATCH 8/9] x86/rtc: replace paravirt_enabled() check  with subarch check Juergen Gross <jgross@suse.com> - 2016-02-19 14:30 +0100
        Re: [Xen-devel] [PATCH 8/9] x86/rtc: replace paravirt_enabled()  check with subarch check "Luis R. Rodriguez" <mcgrof@suse.com> - 2016-02-19 15:50 +0100
          Re: [Xen-devel] [PATCH 8/9] x86/rtc: replace paravirt_enabled()  check with subarch check "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-22 07:10 +0100
            Re: [Xen-devel] [PATCH 8/9] x86/rtc: replace paravirt_enabled()  check with subarch check Borislav Petkov <bp@alien8.de> - 2016-02-22 11:30 +0100
              Re: [Xen-devel] [PATCH 8/9] x86/rtc: replace paravirt_enabled() check  with subarch check Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-02-22 15:40 +0100
      Re: [Xen-devel] [PATCH 8/9] x86/rtc: replace paravirt_enabled() check  with subarch check David Vrabel <david.vrabel@citrix.com> - 2016-02-19 14:30 +0100
    [PATCH 5/9] apm32: remove paravirt_enabled() use "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-19 14:10 +0100
      Re: [PATCH 5/9] apm32: remove paravirt_enabled() use Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-02-19 16:20 +0100
        Re: [PATCH 5/9] apm32: remove paravirt_enabled() use "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-19 22:00 +0100
          Re: [PATCH 5/9] apm32: remove paravirt_enabled() use Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-02-19 23:20 +0100
            Re: [PATCH 5/9] apm32: remove paravirt_enabled() use "Luis R. Rodriguez" <mcgrof@suse.com> - 2016-02-20 01:50 +0100
              Re: [PATCH 5/9] apm32: remove paravirt_enabled() use Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-02-22 15:20 +0100
    [PATCH 4/9] x86/init: make ebda depend on PC subarch "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-19 14:20 +0100
    [PATCH 1/9] x86/boot: enumerate documentation for the x86 hardware_subarch "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-19 14:20 +0100
      Re: [Xen-devel] [PATCH 1/9] x86/boot: enumerate documentation for the  x86 hardware_subarch Juergen Gross <jgross@suse.com> - 2016-02-19 14:30 +0100
      Re: [Xen-devel] [PATCH 1/9] x86/boot: enumerate documentation for the  x86 hardware_subarch David Vrabel <david.vrabel@citrix.com> - 2016-02-19 14:50 +0100
        Re: [Xen-devel] [PATCH 1/9] x86/boot: enumerate documentation for  the x86 hardware_subarch "Luis R. Rodriguez" <mcgrof@suse.com> - 2016-02-19 15:50 +0100
    [PATCH 6/9] x86/tboot: remove paravirt_enabled() "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-19 14:20 +0100
    [PATCH 7/9] x86/cpu/intel: replace paravirt_enabled() for f00f work around "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-19 14:20 +0100
    [PATCH 3/9] x86/xen: use X86_SUBARCH_XEN for PV guest boots "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-19 14:20 +0100
    Re: [Xen-devel] [PATCH 0/9] x86/init: replace paravirt_enabled() were  possible David Vrabel <david.vrabel@citrix.com> - 2016-02-19 14:40 +0100
      Re: [Xen-devel] [PATCH 0/9] x86/init: replace paravirt_enabled()  were possible "Luis R. Rodriguez" <mcgrof@suse.com> - 2016-02-19 15:40 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1338184 — [PATCH 7/9] x86/cpu/intel: replace paravirt_enabled() for f00f work around

Use the harware subarch instead now that they are set. If we
want to test removing this work around on Xen we can do so
separatley as another independent change, for now we just want
to remove paravirt_enabled().

Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
 arch/x86/kernel/cpu/intel.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 565648bc1a0a..26d8c496c909 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -220,7 +220,9 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
 	 * The Quark is also family 5, but does not have the same bug.
 	 */
 	clear_cpu_bug(c, X86_BUG_F00F);
-	if (!paravirt_enabled() && c->x86 == 5 && c->x86_model < 9) {
+	if (boot_params.hdr.hardware_subarch != X86_SUBARCH_XEN &&
+	    boot_params.hdr.hardware_subarch != X86_SUBARCH_LGUEST &&
+	    c->x86 == 5 && c->x86_model < 9) {
 		static int f00f_workaround_enabled;
 
 		set_cpu_bug(c, X86_BUG_F00F);
-- 
2.7.0

[toc] | [prev] | [next] | [standalone]

#1338185 — [PATCH 3/9] x86/xen: use X86_SUBARCH_XEN for PV guest boots

The use of subarch should have no current effect on Xen
PV guests, as such this should have no current functional
effects.

Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
 arch/x86/xen/enlighten.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index d09e4c9d7cc5..5b3f1c763806 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1669,6 +1669,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
 	boot_params.hdr.ramdisk_image = initrd_start;
 	boot_params.hdr.ramdisk_size = xen_start_info->mod_len;
 	boot_params.hdr.cmd_line_ptr = __pa(xen_start_info->cmd_line);
+	boot_params.hdr.hardware_subarch = X86_SUBARCH_XEN;
 
 	if (!xen_initial_domain()) {
 		add_preferred_console("xenboot", 0, NULL);
-- 
2.7.0

[toc] | [prev] | [next] | [standalone]

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

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?

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 think you should consider a finer-grained set of feature bits.  e.g.,
platform_has_pc_rtc() and platform_has_tboot() etc.

David

> 
> While at it, document the subarch to avoid any possible misuses.
> 
> Luis R. Rodriguez (9):
>   x86/boot: enumerate documentation for the x86 hardware_subarch
>   tools/lguest: make lguest launcher use X86_SUBARCH_LGUEST explicitly
>   x86/xen: use X86_SUBARCH_XEN for PV guest boots
>   x86/init: make ebda depend on PC subarch
>   apm32: remove paravirt_enabled() use
>   x86/tboot: remove paravirt_enabled()
>   x86/cpu/intel: replace paravirt_enabled() for f00f work around
>   x86/rtc: replace paravirt_enabled() check with subarch check
>   pnpbios: replace paravirt_enabled() check with subarch checks
> 
>  arch/x86/include/asm/paravirt.h       |  6 ------
>  arch/x86/include/asm/paravirt_types.h |  5 -----
>  arch/x86/include/asm/processor.h      |  1 -
>  arch/x86/include/uapi/asm/bootparam.h | 32 +++++++++++++++++++++++++++++++-
>  arch/x86/kernel/apm_32.c              |  2 +-
>  arch/x86/kernel/cpu/intel.c           |  4 +++-
>  arch/x86/kernel/head.c                |  2 +-
>  arch/x86/kernel/rtc.c                 |  3 ++-
>  arch/x86/kernel/tboot.c               |  6 ------
>  arch/x86/xen/enlighten.c              |  4 +---
>  drivers/pnp/pnpbios/core.c            |  4 +++-
>  tools/lguest/lguest.c                 |  4 ++--
>  12 files changed, 44 insertions(+), 29 deletions(-)
> 

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web