All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xen-devel] [PATCH v2 for 4.13 1/2] x86/boot: allow early usage of cpu_has_hypervisor
@ 2019-10-30 14:54 Sergey Dyasli
  2019-10-30 14:54 ` [Xen-devel] [PATCH v2 for 4.13 2/2] x86/e820: fix 640k - 1M region reservation logic Sergey Dyasli
  2019-10-30 15:32 ` [Xen-devel] [PATCH v2 for 4.13 1/2] x86/boot: allow early usage of cpu_has_hypervisor Jan Beulich
  0 siblings, 2 replies; 6+ messages in thread
From: Sergey Dyasli @ 2019-10-30 14:54 UTC (permalink / raw)
  To: xen-devel
  Cc: Juergen Gross, Sergey Dyasli, Wei Liu, Andrew Cooper,
	Jan Beulich, Roger Pau Monné

Move early_cpu_init() to be near the top of __start_xen(). Since there
is no serial / vga output at that stage, introduce a new function
to print CPU information at the usual place during boot.

Finally, convert users of cpuid_ecx(1) & X86_FEATURE_HYPERVISOR.

Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Wei Liu <wl@xen.org>
CC: "Roger Pau Monné" <roger.pau@citrix.com>
CC: Juergen Gross <jgross@suse.com>
---
 xen/arch/x86/cpu/common.c   | 25 +++++++++++++++++--------
 xen/arch/x86/guest/xen.c    |  3 +--
 xen/arch/x86/mm.c           |  2 +-
 xen/arch/x86/setup.c        |  4 +++-
 xen/include/asm-x86/setup.h |  1 +
 5 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 6c6bd63301..4f336f64d3 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -109,6 +109,7 @@ static const struct cpu_dev default_cpu = {
 	.c_init	= default_init,
 };
 static const struct cpu_dev *this_cpu = &default_cpu;
+static bool __initdata unrecognised_cpu;
 
 static DEFINE_PER_CPU(uint64_t, msr_misc_features);
 void (* __read_mostly ctxt_switch_masking)(const struct vcpu *next);
@@ -301,9 +302,7 @@ void __init early_cpu_init(void)
 	case X86_VENDOR_SHANGHAI: this_cpu = &shanghai_cpu_dev; break;
 	case X86_VENDOR_HYGON:    this_cpu = &hygon_cpu_dev;    break;
 	default:
-		printk(XENLOG_ERR
-		       "Unrecognised or unsupported CPU vendor '%.12s'\n",
-		       c->x86_vendor_id);
+		unrecognised_cpu = true;
 	}
 
 	cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
@@ -317,11 +316,6 @@ void __init early_cpu_init(void)
 	c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = edx;
 	c->x86_capability[cpufeat_word(X86_FEATURE_SSE3)] = ecx;
 
-	printk(XENLOG_INFO
-	       "CPU Vendor: %s, Family %u (%#x), Model %u (%#x), Stepping %u (raw %08x)\n",
-	       x86_cpuid_vendor_to_str(c->x86_vendor), c->x86, c->x86,
-	       c->x86_model, c->x86_model, c->x86_mask, eax);
-
 	eax = cpuid_eax(0x80000000);
 	if ((eax >> 16) == 0x8000 && eax >= 0x80000008) {
 		eax = cpuid_eax(0x80000008);
@@ -342,6 +336,21 @@ void __init early_cpu_init(void)
 	initialize_cpu_data(0);
 }
 
+void __init early_cpu_print_info(void)
+{
+	struct cpuinfo_x86 *c = &boot_cpu_data;
+
+	if (unrecognised_cpu)
+		printk(XENLOG_ERR
+		       "Unrecognised or unsupported CPU vendor '%.12s'\n",
+		       c->x86_vendor_id);
+
+	printk(XENLOG_INFO "CPU Vendor: %s, Family %u (%#x), Model %u (%#x), "
+			   "Stepping %u (raw %08x)\n",
+	       x86_cpuid_vendor_to_str(c->x86_vendor), c->x86, c->x86,
+	       c->x86_model, c->x86_model, c->x86_mask, cpuid_eax(0x00000001));
+}
+
 static void generic_identify(struct cpuinfo_x86 *c)
 {
 	u32 eax, ebx, ecx, edx, tmp;
diff --git a/xen/arch/x86/guest/xen.c b/xen/arch/x86/guest/xen.c
index 7b7a5badab..9b776afed9 100644
--- a/xen/arch/x86/guest/xen.c
+++ b/xen/arch/x86/guest/xen.c
@@ -72,8 +72,7 @@ void __init probe_hypervisor(void)
     if ( xen_guest )
         return;
 
-    /* Too early to use cpu_has_hypervisor */
-    if ( !(cpuid_ecx(1) & cpufeat_mask(X86_FEATURE_HYPERVISOR)) )
+    if ( !cpu_has_hypervisor )
         return;
 
     find_xen_leaves();
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 99816fc67c..4cdccab8c8 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5943,7 +5943,7 @@ const struct platform_bad_page *__init get_platform_badpages(unsigned int *array
     case 0x000806e0: /* erratum KBL??? */
     case 0x000906e0: /* errata KBL??? / KBW114 / CFW103 */
         *array_size = (cpuid_eax(0) >= 7 &&
-                       !(cpuid_ecx(1) & cpufeat_mask(X86_FEATURE_HYPERVISOR)) &&
+                       !cpu_has_hypervisor &&
                        (cpuid_count_ebx(7, 0) & cpufeat_mask(X86_FEATURE_HLE)));
         return &hle_bad_page;
     }
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index dec60d0301..07adfed566 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -723,6 +723,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
     /* Enable NMIs.  Our loader (e.g. Tboot) may have left them disabled. */
     enable_nmis();
 
+    early_cpu_init();
+
     if ( pvh_boot )
     {
         /*
@@ -1519,7 +1521,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
     softirq_init();
     tasklet_subsys_init();
 
-    early_cpu_init();
+    early_cpu_print_info();
 
     paging_init();
 
diff --git a/xen/include/asm-x86/setup.h b/xen/include/asm-x86/setup.h
index 861d46d6ac..251151508d 100644
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -15,6 +15,7 @@ extern char __2M_rwdata_start[], __2M_rwdata_end[];
 extern unsigned long xenheap_initial_phys_start;
 
 void early_cpu_init(void);
+void early_cpu_print_info(void);
 void early_time_init(void);
 
 void set_nr_cpu_ids(unsigned int max_cpus);
-- 
2.17.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* [Xen-devel] [PATCH v2 for 4.13 2/2] x86/e820: fix 640k - 1M region reservation logic
  2019-10-30 14:54 [Xen-devel] [PATCH v2 for 4.13 1/2] x86/boot: allow early usage of cpu_has_hypervisor Sergey Dyasli
@ 2019-10-30 14:54 ` Sergey Dyasli
  2019-10-30 15:33   ` Jan Beulich
  2019-10-31 18:42   ` Wei Liu
  2019-10-30 15:32 ` [Xen-devel] [PATCH v2 for 4.13 1/2] x86/boot: allow early usage of cpu_has_hypervisor Jan Beulich
  1 sibling, 2 replies; 6+ messages in thread
From: Sergey Dyasli @ 2019-10-30 14:54 UTC (permalink / raw)
  To: xen-devel
  Cc: Juergen Gross, Sergey Dyasli, Wei Liu, Andrew Cooper,
	Jan Beulich, Roger Pau Monné

Converting a guest from PV to PV-in-PVH makes the guest to have 384k
less memory, which may confuse guest's balloon driver. This happens
because Xen unconditionally reserves 640k - 1M region in E820 despite
the fact that it's really a usable RAM in PVH boot mode.

Fix this by skipping region type change in virtualised environments,
trusting whatever memory map our hypervisor has provided.

Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Wei Liu <wl@xen.org>
CC: "Roger Pau Monné" <roger.pau@citrix.com>
CC: Juergen Gross <jgross@suse.com>
---
 xen/arch/x86/e820.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
index 8e8a2c4e1b..30ab8d9b35 100644
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ -318,9 +318,10 @@ static int __init copy_e820_map(struct e820entry * biosmap, unsigned int nr_map)
 
         /*
          * Some BIOSes claim RAM in the 640k - 1M region.
-         * Not right. Fix it up.
+         * Not right. Fix it up, but only when running on bare metal.
          */
-        if (type == E820_RAM) {
+        if ( !cpu_has_hypervisor && type == E820_RAM )
+        {
             if (start < 0x100000ULL && end > 0xA0000ULL) {
                 if (start < 0xA0000ULL)
                     add_memory_region(start, 0xA0000ULL-start, type);
-- 
2.17.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [Xen-devel] [PATCH v2 for 4.13 1/2] x86/boot: allow early usage of cpu_has_hypervisor
  2019-10-30 14:54 [Xen-devel] [PATCH v2 for 4.13 1/2] x86/boot: allow early usage of cpu_has_hypervisor Sergey Dyasli
  2019-10-30 14:54 ` [Xen-devel] [PATCH v2 for 4.13 2/2] x86/e820: fix 640k - 1M region reservation logic Sergey Dyasli
@ 2019-10-30 15:32 ` Jan Beulich
  2019-10-30 17:13   ` Sergey Dyasli
  1 sibling, 1 reply; 6+ messages in thread
From: Jan Beulich @ 2019-10-30 15:32 UTC (permalink / raw)
  To: Sergey Dyasli
  Cc: Juergen Gross, Andrew Cooper, Roger Pau Monné, Wei Liu, xen-devel

On 30.10.2019 15:54, Sergey Dyasli wrote:
> @@ -317,11 +316,6 @@ void __init early_cpu_init(void)
>  	c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = edx;
>  	c->x86_capability[cpufeat_word(X86_FEATURE_SSE3)] = ecx;
>  
> -	printk(XENLOG_INFO
> -	       "CPU Vendor: %s, Family %u (%#x), Model %u (%#x), Stepping %u (raw %08x)\n",
> -	       x86_cpuid_vendor_to_str(c->x86_vendor), c->x86, c->x86,
> -	       c->x86_model, c->x86_model, c->x86_mask, eax);

I'm slightly concerned of the code immediately ahead of this
printk() now running _much_ earlier. Did you inspect that there's
no change of the relevant cleared_caps[] entries between the new
and the old call position in setup.c?

> @@ -342,6 +336,21 @@ void __init early_cpu_init(void)
>  	initialize_cpu_data(0);
>  }
>  
> +void __init early_cpu_print_info(void)
> +{
> +	struct cpuinfo_x86 *c = &boot_cpu_data;

const

> +	if (unrecognised_cpu)
> +		printk(XENLOG_ERR
> +		       "Unrecognised or unsupported CPU vendor '%.12s'\n",
> +		       c->x86_vendor_id);
> +
> +	printk(XENLOG_INFO "CPU Vendor: %s, Family %u (%#x), Model %u (%#x), "
> +			   "Stepping %u (raw %08x)\n",
> +	       x86_cpuid_vendor_to_str(c->x86_vendor), c->x86, c->x86,
> +	       c->x86_model, c->x86_model, c->x86_mask, cpuid_eax(0x00000001));

May I suggest to use the shorter "1" here?

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -723,6 +723,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>      /* Enable NMIs.  Our loader (e.g. Tboot) may have left them disabled. */
>      enable_nmis();
>  
> +    early_cpu_init();
> +
>      if ( pvh_boot )
>      {
>          /*
> @@ -1519,7 +1521,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>      softirq_init();
>      tasklet_subsys_init();
>  
> -    early_cpu_init();
> +    early_cpu_print_info();

I agree with splitting the function, but I guess this could still
be moved up by quite a bit, next to the printk()-s right after
console_init_preirq().

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Xen-devel] [PATCH v2 for 4.13 2/2] x86/e820: fix 640k - 1M region reservation logic
  2019-10-30 14:54 ` [Xen-devel] [PATCH v2 for 4.13 2/2] x86/e820: fix 640k - 1M region reservation logic Sergey Dyasli
@ 2019-10-30 15:33   ` Jan Beulich
  2019-10-31 18:42   ` Wei Liu
  1 sibling, 0 replies; 6+ messages in thread
From: Jan Beulich @ 2019-10-30 15:33 UTC (permalink / raw)
  To: Sergey Dyasli
  Cc: Juergen Gross, Andrew Cooper, Roger Pau Monné, Wei Liu, xen-devel

On 30.10.2019 15:54, Sergey Dyasli wrote:
> Converting a guest from PV to PV-in-PVH makes the guest to have 384k
> less memory, which may confuse guest's balloon driver. This happens
> because Xen unconditionally reserves 640k - 1M region in E820 despite
> the fact that it's really a usable RAM in PVH boot mode.
> 
> Fix this by skipping region type change in virtualised environments,
> trusting whatever memory map our hypervisor has provided.
> 
> Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Xen-devel] [PATCH v2 for 4.13 1/2] x86/boot: allow early usage of cpu_has_hypervisor
  2019-10-30 15:32 ` [Xen-devel] [PATCH v2 for 4.13 1/2] x86/boot: allow early usage of cpu_has_hypervisor Jan Beulich
@ 2019-10-30 17:13   ` Sergey Dyasli
  0 siblings, 0 replies; 6+ messages in thread
From: Sergey Dyasli @ 2019-10-30 17:13 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Juergen Gross, sergey.dyasli@citrix.com >> Sergey Dyasli,
	Wei Liu, Andrew Cooper, xen-devel, Roger Pau Monné

On 30/10/2019 15:32, Jan Beulich wrote:
> On 30.10.2019 15:54, Sergey Dyasli wrote:
>> @@ -317,11 +316,6 @@ void __init early_cpu_init(void)
>>  	c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = edx;
>>  	c->x86_capability[cpufeat_word(X86_FEATURE_SSE3)] = ecx;
>>  
>> -	printk(XENLOG_INFO
>> -	       "CPU Vendor: %s, Family %u (%#x), Model %u (%#x), Stepping %u (raw %08x)\n",
>> -	       x86_cpuid_vendor_to_str(c->x86_vendor), c->x86, c->x86,
>> -	       c->x86_model, c->x86_model, c->x86_mask, eax);
> 
> I'm slightly concerned of the code immediately ahead of this
> printk() now running _much_ earlier. Did you inspect that there's
> no change of the relevant cleared_caps[] entries between the new
> and the old call position in setup.c?

You are right, this idea requires a more sophisticated approach.
Please disregard this patch. For now I'll add something like
early_cpu_has_hypervisor(). Will send a v3 soon.

--
Thanks,
Sergey

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Xen-devel] [PATCH v2 for 4.13 2/2] x86/e820: fix 640k - 1M region reservation logic
  2019-10-30 14:54 ` [Xen-devel] [PATCH v2 for 4.13 2/2] x86/e820: fix 640k - 1M region reservation logic Sergey Dyasli
  2019-10-30 15:33   ` Jan Beulich
@ 2019-10-31 18:42   ` Wei Liu
  1 sibling, 0 replies; 6+ messages in thread
From: Wei Liu @ 2019-10-31 18:42 UTC (permalink / raw)
  To: Sergey Dyasli
  Cc: Juergen Gross, Wei Liu, Andrew Cooper, xen-devel, Jan Beulich,
	Roger Pau Monné

On Wed, Oct 30, 2019 at 02:54:47PM +0000, Sergey Dyasli wrote:
> Converting a guest from PV to PV-in-PVH makes the guest to have 384k
> less memory, which may confuse guest's balloon driver. This happens
> because Xen unconditionally reserves 640k - 1M region in E820 despite
> the fact that it's really a usable RAM in PVH boot mode.
> 
> Fix this by skipping region type change in virtualised environments,
> trusting whatever memory map our hypervisor has provided.
> 
> Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>

Reviewed-by: Wei Liu <wl@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2019-10-31 18:42 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-30 14:54 [Xen-devel] [PATCH v2 for 4.13 1/2] x86/boot: allow early usage of cpu_has_hypervisor Sergey Dyasli
2019-10-30 14:54 ` [Xen-devel] [PATCH v2 for 4.13 2/2] x86/e820: fix 640k - 1M region reservation logic Sergey Dyasli
2019-10-30 15:33   ` Jan Beulich
2019-10-31 18:42   ` Wei Liu
2019-10-30 15:32 ` [Xen-devel] [PATCH v2 for 4.13 1/2] x86/boot: allow early usage of cpu_has_hypervisor Jan Beulich
2019-10-30 17:13   ` Sergey Dyasli

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.