Xen devel - Sep 2011 - [PATCH 0/3] x86/microcode: support for microcode update in Xen dom0

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

Hi all,

I''m proposing this for the next merge window v3.2.

I originally posted this early this year, and it prompted a debate
about what the "proper" way that Linux should do microcode updates,
with the general concensus being "earlier", ideally in the bootloader
(or in the case of Xen, as the hypervisor boots before starting any
domains).  However, as far as I know there has been no progress along
those lines.

I would like to therefore merge this so that a Linux kernel booting as
dom0 under Xen can update the microcode in the same manner as a kernel
booting natively.  When we work out how boot-time microcode updates
can be done, then we''ll look at modifying Xen accordingly.  In the
meantime, we should have a functional parity.

The only change to this code from the previous posting is some patch
restructuring so that regardless of how the platform.h ABI header gets
merged (since there are some other pending branches containing it), it
will be identical and cause no merge headaches.
>From original posting:
This series adds a new "Xen" microcode update type, in addition to
Intel and AMD.

The Xen hypervisor is responsible for performing the actual microcode
update (since only it knows what physical CPUs are in the system and
has sufficient privilege to access them), but it requires the dom0
kernel to provide the actual microcode update data.

Xen update mechanism is uniform independent of the CPU type, but the
driver must know where to find the data file, which depends on the CPU
type.  And since the update hypercall updates all CPUs, we only need
to execute it once on any CPU - but for simplicity it just runs it only
on (V)CPU 0.

Thanks,
	J

Jeremy Fitzhardinge (2):
  xen: add dom0_op hypercall
  xen: add CPU microcode update driver

Yu Ke (1):
  xen/acpi: Domain0 acpi parser related platform hypercall

 arch/ia64/include/asm/xen/interface.h |    1 +
 arch/x86/include/asm/microcode.h      |    9 +
 arch/x86/include/asm/xen/hypercall.h  |    8 +
 arch/x86/include/asm/xen/interface.h  |    1 +
 arch/x86/kernel/Makefile              |    1 +
 arch/x86/kernel/microcode_core.c      |    5 +-
 arch/x86/kernel/microcode_xen.c       |  198 ++++++++++++++++++++
 arch/x86/xen/Kconfig                  |    4 +
 include/xen/interface/platform.h      |  320 +++++++++++++++++++++++++++++++++
 include/xen/interface/xen.h           |    1 +
 10 files changed, 547 insertions(+), 1 deletions(-)
 create mode 100644 arch/x86/kernel/microcode_xen.c
 create mode 100644 include/xen/interface/platform.h

-- 
1.7.6.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From: Yu Ke <ke.yu@intel.com>

This patches implements the xen_platform_op hypercall, to pass the parsed
ACPI info to hypervisor.

Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Tian Kevin <kevin.tian@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
[v1: Added DEFINE_GUEST.. in appropiate headers]
[v2: Ripped out typedefs]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/ia64/include/asm/xen/interface.h |    1 +
 arch/x86/include/asm/xen/interface.h  |    1 +
 include/xen/interface/platform.h      |  320 +++++++++++++++++++++++++++++++++
 include/xen/interface/xen.h           |    1 +
 4 files changed, 323 insertions(+), 0 deletions(-)
 create mode 100644 include/xen/interface/platform.h

diff --git a/arch/ia64/include/asm/xen/interface.h
b/arch/ia64/include/asm/xen/interface.h
index e951e74..1d2427d 100644
--- a/arch/ia64/include/asm/xen/interface.h
+++ b/arch/ia64/include/asm/xen/interface.h
@@ -76,6 +76,7 @@ DEFINE_GUEST_HANDLE(char);
 DEFINE_GUEST_HANDLE(int);
 DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
+DEFINE_GUEST_HANDLE(uint64_t);
 
 typedef unsigned long xen_pfn_t;
 DEFINE_GUEST_HANDLE(xen_pfn_t);
diff --git a/arch/x86/include/asm/xen/interface.h
b/arch/x86/include/asm/xen/interface.h
index 5d4922a..a1f2db5 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -55,6 +55,7 @@ DEFINE_GUEST_HANDLE(char);
 DEFINE_GUEST_HANDLE(int);
 DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
+DEFINE_GUEST_HANDLE(uint64_t);
 #endif
 
 #ifndef HYPERVISOR_VIRT_START
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
new file mode 100644
index 0000000..c168468
--- /dev/null
+++ b/include/xen/interface/platform.h
@@ -0,0 +1,320 @@
+/******************************************************************************
+ * platform.h
+ *
+ * Hardware platform operations. Intended for use by domain-0 kernel.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the
"Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2002-2006, K Fraser
+ */
+
+#ifndef __XEN_PUBLIC_PLATFORM_H__
+#define __XEN_PUBLIC_PLATFORM_H__
+
+#include "xen.h"
+
+#define XENPF_INTERFACE_VERSION 0x03000001
+
+/*
+ * Set clock such that it would read <secs,nsecs> after 00:00:00 UTC,
+ * 1 January, 1970 if the current system time was <system_time>.
+ */
+#define XENPF_settime             17
+struct xenpf_settime {
+	/* IN variables. */
+	uint32_t secs;
+	uint32_t nsecs;
+	uint64_t system_time;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_settime_t);
+
+/*
+ * Request memory range (@mfn, @mfn+@nr_mfns-1) to have type @type.
+ * On x86, @type is an architecture-defined MTRR memory type.
+ * On success, returns the MTRR that was used (@reg) and a handle that can
+ * be passed to XENPF_DEL_MEMTYPE to accurately tear down the new setting.
+ * (x86-specific).
+ */
+#define XENPF_add_memtype         31
+struct xenpf_add_memtype {
+	/* IN variables. */
+	unsigned long mfn;
+	uint64_t nr_mfns;
+	uint32_t type;
+	/* OUT variables. */
+	uint32_t handle;
+	uint32_t reg;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_add_memtype_t);
+
+/*
+ * Tear down an existing memory-range type. If @handle is remembered then it
+ * should be passed in to accurately tear down the correct setting (in case
+ * of overlapping memory regions with differing types). If it is not known
+ * then @handle should be set to zero. In all cases @reg must be set.
+ * (x86-specific).
+ */
+#define XENPF_del_memtype         32
+struct xenpf_del_memtype {
+	/* IN variables. */
+	uint32_t handle;
+	uint32_t reg;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_del_memtype_t);
+
+/* Read current type of an MTRR (x86-specific). */
+#define XENPF_read_memtype        33
+struct xenpf_read_memtype {
+	/* IN variables. */
+	uint32_t reg;
+	/* OUT variables. */
+	unsigned long mfn;
+	uint64_t nr_mfns;
+	uint32_t type;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_read_memtype_t);
+
+#define XENPF_microcode_update    35
+struct xenpf_microcode_update {
+	/* IN variables. */
+	GUEST_HANDLE(void) data;          /* Pointer to microcode data */
+	uint32_t length;                  /* Length of microcode data. */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_microcode_update_t);
+
+#define XENPF_platform_quirk      39
+#define QUIRK_NOIRQBALANCING      1 /* Do not restrict IO-APIC RTE targets */
+#define QUIRK_IOAPIC_BAD_REGSEL   2 /* IO-APIC REGSEL forgets its value    */
+#define QUIRK_IOAPIC_GOOD_REGSEL  3 /* IO-APIC REGSEL behaves properly     */
+struct xenpf_platform_quirk {
+	/* IN variables. */
+	uint32_t quirk_id;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_platform_quirk_t);
+
+#define XENPF_firmware_info       50
+#define XEN_FW_DISK_INFO          1 /* from int 13 AH=08/41/48 */
+#define XEN_FW_DISK_MBR_SIGNATURE 2 /* from MBR offset 0x1b8 */
+#define XEN_FW_VBEDDC_INFO        3 /* from int 10 AX=4f15 */
+struct xenpf_firmware_info {
+	/* IN variables. */
+	uint32_t type;
+	uint32_t index;
+	/* OUT variables. */
+	union {
+		struct {
+			/* Int13, Fn48: Check Extensions Present. */
+			uint8_t device;                   /* %dl: bios device number */
+			uint8_t version;                  /* %ah: major version      */
+			uint16_t interface_support;       /* %cx: support bitmap     */
+			/* Int13, Fn08: Legacy Get Device Parameters. */
+			uint16_t legacy_max_cylinder;     /* %cl[7:6]:%ch: max cyl # */
+			uint8_t legacy_max_head;          /* %dh: max head #         */
+			uint8_t legacy_sectors_per_track; /* %cl[5:0]: max sector #  */
+			/* Int13, Fn41: Get Device Parameters (as filled into %ds:%esi). */
+			/* NB. First uint16_t of buffer must be set to buffer size.      */
+			GUEST_HANDLE(void) edd_params;
+		} disk_info; /* XEN_FW_DISK_INFO */
+		struct {
+			uint8_t device;                   /* bios device number  */
+			uint32_t mbr_signature;           /* offset 0x1b8 in mbr */
+		} disk_mbr_signature; /* XEN_FW_DISK_MBR_SIGNATURE */
+		struct {
+			/* Int10, AX=4F15: Get EDID info. */
+			uint8_t capabilities;
+			uint8_t edid_transfer_time;
+			/* must refer to 128-byte buffer */
+			GUEST_HANDLE(uchar) edid;
+		} vbeddc_info; /* XEN_FW_VBEDDC_INFO */
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_firmware_info_t);
+
+#define XENPF_enter_acpi_sleep    51
+struct xenpf_enter_acpi_sleep {
+	/* IN variables */
+	uint16_t pm1a_cnt_val;      /* PM1a control value. */
+	uint16_t pm1b_cnt_val;      /* PM1b control value. */
+	uint32_t sleep_state;       /* Which state to enter (Sn). */
+	uint32_t flags;             /* Must be zero. */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_enter_acpi_sleep_t);
+
+#define XENPF_change_freq         52
+struct xenpf_change_freq {
+	/* IN variables */
+	uint32_t flags; /* Must be zero. */
+	uint32_t cpu;   /* Physical cpu. */
+	uint64_t freq;  /* New frequency (Hz). */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_change_freq_t);
+
+/*
+ * Get idle times (nanoseconds since boot) for physical CPUs specified in the
+ * @cpumap_bitmap with range [0..@cpumap_nr_cpus-1]. The @idletime array is
+ * indexed by CPU number; only entries with the corresponding @cpumap_bitmap
+ * bit set are written to. On return, @cpumap_bitmap is modified so that any
+ * non-existent CPUs are cleared. Such CPUs have their @idletime array entry
+ * cleared.
+ */
+#define XENPF_getidletime         53
+struct xenpf_getidletime {
+	/* IN/OUT variables */
+	/* IN: CPUs to interrogate; OUT: subset of IN which are present */
+	GUEST_HANDLE(uchar) cpumap_bitmap;
+	/* IN variables */
+	/* Size of cpumap bitmap. */
+	uint32_t cpumap_nr_cpus;
+	/* Must be indexable for every cpu in cpumap_bitmap. */
+	GUEST_HANDLE(uint64_t) idletime;
+	/* OUT variables */
+	/* System time when the idletime snapshots were taken. */
+	uint64_t now;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t);
+
+#define XENPF_set_processor_pminfo      54
+
+/* ability bits */
+#define XEN_PROCESSOR_PM_CX	1
+#define XEN_PROCESSOR_PM_PX	2
+#define XEN_PROCESSOR_PM_TX	4
+
+/* cmd type */
+#define XEN_PM_CX   0
+#define XEN_PM_PX   1
+#define XEN_PM_TX   2
+
+/* Px sub info type */
+#define XEN_PX_PCT   1
+#define XEN_PX_PSS   2
+#define XEN_PX_PPC   4
+#define XEN_PX_PSD   8
+
+struct xen_power_register {
+	uint32_t     space_id;
+	uint32_t     bit_width;
+	uint32_t     bit_offset;
+	uint32_t     access_size;
+	uint64_t     address;
+};
+
+struct xen_processor_csd {
+	uint32_t    domain;      /* domain number of one dependent group */
+	uint32_t    coord_type;  /* coordination type */
+	uint32_t    num;         /* number of processors in same domain */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_processor_csd);
+
+struct xen_processor_cx {
+	struct xen_power_register  reg; /* GAS for Cx trigger register */
+	uint8_t     type;     /* cstate value, c0: 0, c1: 1, ... */
+	uint32_t    latency;  /* worst latency (ms) to enter/exit this cstate */
+	uint32_t    power;    /* average power consumption(mW) */
+	uint32_t    dpcnt;    /* number of dependency entries */
+	GUEST_HANDLE(xen_processor_csd) dp; /* NULL if no dependency */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_processor_cx);
+
+struct xen_processor_flags {
+	uint32_t bm_control:1;
+	uint32_t bm_check:1;
+	uint32_t has_cst:1;
+	uint32_t power_setup_done:1;
+	uint32_t bm_rld_set:1;
+};
+
+struct xen_processor_power {
+	uint32_t count;  /* number of C state entries in array below */
+	struct xen_processor_flags flags;  /* global flags of this processor */
+	GUEST_HANDLE(xen_processor_cx) states; /* supported c states */
+};
+
+struct xen_pct_register {
+	uint8_t  descriptor;
+	uint16_t length;
+	uint8_t  space_id;
+	uint8_t  bit_width;
+	uint8_t  bit_offset;
+	uint8_t  reserved;
+	uint64_t address;
+};
+
+struct xen_processor_px {
+	uint64_t core_frequency; /* megahertz */
+	uint64_t power;      /* milliWatts */
+	uint64_t transition_latency; /* microseconds */
+	uint64_t bus_master_latency; /* microseconds */
+	uint64_t control;        /* control value */
+	uint64_t status;     /* success indicator */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_processor_px);
+
+struct xen_psd_package {
+	uint64_t num_entries;
+	uint64_t revision;
+	uint64_t domain;
+	uint64_t coord_type;
+	uint64_t num_processors;
+};
+
+struct xen_processor_performance {
+	uint32_t flags;     /* flag for Px sub info type */
+	uint32_t platform_limit;  /* Platform limitation on freq usage */
+	struct xen_pct_register control_register;
+	struct xen_pct_register status_register;
+	uint32_t state_count;     /* total available performance states */
+	GUEST_HANDLE(xen_processor_px) states;
+	struct xen_psd_package domain_info;
+	uint32_t shared_type;     /* coordination type of this processor */
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_processor_performance);
+
+struct xenpf_set_processor_pminfo {
+	/* IN variables */
+	uint32_t id;    /* ACPI CPU ID */
+	uint32_t type;  /* {XEN_PM_CX, XEN_PM_PX} */
+	union {
+		struct xen_processor_power          power;/* Cx: _CST/_CSD */
+		struct xen_processor_performance    perf; /* Px: _PPC/_PCT/_PSS/_PSD */
+	};
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo);
+
+struct xen_platform_op {
+	uint32_t cmd;
+	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
+	union {
+		struct xenpf_settime           settime;
+		struct xenpf_add_memtype       add_memtype;
+		struct xenpf_del_memtype       del_memtype;
+		struct xenpf_read_memtype      read_memtype;
+		struct xenpf_microcode_update  microcode;
+		struct xenpf_platform_quirk    platform_quirk;
+		struct xenpf_firmware_info     firmware_info;
+		struct xenpf_enter_acpi_sleep  enter_acpi_sleep;
+		struct xenpf_change_freq       change_freq;
+		struct xenpf_getidletime       getidletime;
+		struct xenpf_set_processor_pminfo set_pminfo;
+		uint8_t                        pad[128];
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_platform_op_t);
+
+#endif /* __XEN_PUBLIC_PLATFORM_H__ */
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index b33257b..063ed39 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -452,6 +452,7 @@ struct start_info {
 /* These flags are passed in the ''flags'' field of
start_info_t. */
 #define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
 #define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain?
*/
+#define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options
*/
 
 typedef uint64_t cpumap_t;
 
-- 
1.7.6.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/include/asm/xen/hypercall.h |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/xen/hypercall.h
b/arch/x86/include/asm/xen/hypercall.h
index 8508bfe..93762ff 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -45,6 +45,7 @@
 #include <xen/interface/xen.h>
 #include <xen/interface/sched.h>
 #include <xen/interface/physdev.h>
+#include <xen/interface/platform.h>
 
 /*
  * The hypercall asms have to meet several constraints:
@@ -299,6 +300,13 @@ HYPERVISOR_set_timer_op(u64 timeout)
 }
 
 static inline int
+HYPERVISOR_dom0_op(struct xen_platform_op *platform_op)
+{
+	platform_op->interface_version = XENPF_INTERFACE_VERSION;
+	return _hypercall1(int, dom0_op, platform_op);
+}
+
+static inline int
 HYPERVISOR_set_debugreg(int reg, unsigned long value)
 {
 	return _hypercall2(int, set_debugreg, reg, value);
-- 
1.7.6.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

Xen does all the hard work for us, including choosing the right update
method for this cpu type and actually doing it for all cpus.  We just
need to supply it with the firmware blob.

Because Xen updates all CPUs (and the kernel''s virtual cpu numbers have
no fixed relationship with the underlying physical cpus), we only bother
doing anything for cpu "0".

[ Impact: allow CPU microcode update in Xen dom0 ]
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
 arch/x86/include/asm/microcode.h |    9 ++
 arch/x86/kernel/Makefile         |    1 +
 arch/x86/kernel/microcode_core.c |    5 +-
 arch/x86/kernel/microcode_xen.c  |  198 ++++++++++++++++++++++++++++++++++++++
 arch/x86/xen/Kconfig             |    4 +
 5 files changed, 216 insertions(+), 1 deletions(-)
 create mode 100644 arch/x86/kernel/microcode_xen.c

diff --git a/arch/x86/include/asm/microcode.h b/arch/x86/include/asm/microcode.h
index 2421507..22677d6 100644
--- a/arch/x86/include/asm/microcode.h
+++ b/arch/x86/include/asm/microcode.h
@@ -61,4 +61,13 @@ static inline struct microcode_ops * __init
init_amd_microcode(void)
 }
 #endif
 
+#ifdef CONFIG_MICROCODE_XEN
+extern struct microcode_ops * __init init_xen_microcode(void);
+#else
+static inline struct microcode_ops * __init init_xen_microcode(void)
+{
+	return NULL;
+}
+#endif
+
 #endif /* _ASM_X86_MICROCODE_H */
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 7338ef2..d34362a 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -105,6 +105,7 @@ obj-$(CONFIG_PCSPKR_PLATFORM)	+= pcspeaker.o
 microcode-y				:= microcode_core.o
 microcode-$(CONFIG_MICROCODE_INTEL)	+= microcode_intel.o
 microcode-$(CONFIG_MICROCODE_AMD)	+= microcode_amd.o
+microcode-$(CONFIG_MICROCODE_XEN)	+= microcode_xen.o
 obj-$(CONFIG_MICROCODE)			+= microcode.o
 
 obj-$(CONFIG_X86_CHECK_BIOS_CORRUPTION) += check.o
diff --git a/arch/x86/kernel/microcode_core.c b/arch/x86/kernel/microcode_core.c
index f924280..ecbcbc0 100644
--- a/arch/x86/kernel/microcode_core.c
+++ b/arch/x86/kernel/microcode_core.c
@@ -84,6 +84,7 @@
 #include <linux/mm.h>
 #include <linux/syscore_ops.h>
 
+#include <xen/xen.h>
 #include <asm/microcode.h>
 #include <asm/processor.h>
 
@@ -501,7 +502,9 @@ static int __init microcode_init(void)
 	struct cpuinfo_x86 *c = &cpu_data(0);
 	int error;
 
-	if (c->x86_vendor == X86_VENDOR_INTEL)
+	if (xen_pv_domain())
+		microcode_ops = init_xen_microcode();
+	else if (c->x86_vendor == X86_VENDOR_INTEL)
 		microcode_ops = init_intel_microcode();
 	else if (c->x86_vendor == X86_VENDOR_AMD)
 		microcode_ops = init_amd_microcode();
diff --git a/arch/x86/kernel/microcode_xen.c b/arch/x86/kernel/microcode_xen.c
new file mode 100644
index 0000000..9d2a06b
--- /dev/null
+++ b/arch/x86/kernel/microcode_xen.c
@@ -0,0 +1,198 @@
+/*
+ * Xen microcode update driver
+ *
+ * Xen does most of the work here.  We just pass the whole blob into
+ * Xen, and it will apply it to all CPUs as appropriate.  Xen will
+ * worry about how different CPU models are actually updated.
+ */
+#include <linux/sched.h>
+#include <linux/module.h>
+#include <linux/firmware.h>
+#include <linux/vmalloc.h>
+#include <linux/uaccess.h>
+
+#include <asm/microcode.h>
+
+#include <xen/xen.h>
+#include <xen/interface/platform.h>
+#include <xen/interface/xen.h>
+
+#include <asm/xen/hypercall.h>
+#include <asm/xen/hypervisor.h>
+
+MODULE_DESCRIPTION("Xen microcode update driver");
+MODULE_LICENSE("GPL");
+
+struct xen_microcode {
+	size_t len;
+	char data[0];
+};
+
+static int xen_microcode_update(int cpu)
+{
+	int err;
+	struct xen_platform_op op;
+	struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
+	struct xen_microcode *uc = uci->mc;
+
+	if (uc == NULL || uc->len == 0) {
+		/*
+		 * We do all cpus at once, so we don''t need to do
+		 * other cpus explicitly (besides, these vcpu numbers
+		 * have no relationship to underlying physical cpus).
+		 */
+		return 0;
+	}
+
+	op.cmd = XENPF_microcode_update;
+	set_xen_guest_handle(op.u.microcode.data, uc->data);
+	op.u.microcode.length = uc->len;
+
+	err = HYPERVISOR_dom0_op(&op);
+
+	if (err != 0)
+		printk(KERN_WARNING "microcode_xen: microcode update failed: %d\n",
err);
+
+	return err;
+}
+
+static enum ucode_state xen_request_microcode_fw(int cpu, struct device
*device)
+{
+	char name[30];
+	struct cpuinfo_x86 *c = &cpu_data(cpu);
+	const struct firmware *firmware;
+	struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
+	enum ucode_state ret;
+	struct xen_microcode *uc;
+	size_t size;
+	int err;
+
+	switch (c->x86_vendor) {
+	case X86_VENDOR_INTEL:
+		snprintf(name, sizeof(name), "intel-ucode/%02x-%02x-%02x",
+			 c->x86, c->x86_model, c->x86_mask);
+		break;
+
+	case X86_VENDOR_AMD:
+		snprintf(name, sizeof(name), "amd-ucode/microcode_amd.bin");
+		break;
+
+	default:
+		return UCODE_NFOUND;
+	}
+
+	err = request_firmware(&firmware, name, device);
+	if (err) {
+		pr_debug("microcode: data file %s load failed\n", name);
+		return UCODE_NFOUND;
+	}
+
+	/*
+	 * Only bother getting real firmware for cpu 0; the others get
+	 * dummy placeholders.
+	 */
+	if (cpu == 0)
+		size = firmware->size;
+	else
+		size = 0;
+
+	if (uci->mc != NULL) {
+		vfree(uci->mc);
+		uci->mc = NULL;
+	}
+
+	ret = UCODE_ERROR;
+	uc = vmalloc(sizeof(*uc) + size);
+	if (uc == NULL)
+		goto out;
+
+	ret = UCODE_OK;
+	uc->len = size;
+	memcpy(uc->data, firmware->data, uc->len);
+
+	uci->mc = uc;
+
+out:
+	release_firmware(firmware);
+
+	return ret;
+}
+
+static enum ucode_state xen_request_microcode_user(int cpu,
+						   const void __user *buf, size_t size)
+{
+	struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
+	struct xen_microcode *uc;
+	enum ucode_state ret;
+	size_t unread;
+
+	if (cpu != 0) {
+		/* No real firmware for non-zero cpus; just store a
+		   placeholder */
+		size = 0;
+	}
+
+	if (uci->mc != NULL) {
+		vfree(uci->mc);
+		uci->mc = NULL;
+	}
+
+	ret = UCODE_ERROR;
+	uc = vmalloc(sizeof(*uc) + size);
+	if (uc == NULL)
+		goto out;
+
+	uc->len = size;
+
+	ret = UCODE_NFOUND;
+
+	unread = copy_from_user(uc->data, buf, size);
+
+	if (unread != 0) {
+		printk(KERN_WARNING "failed to read %zd of %zd bytes at %p ->
%p\n",
+		       unread, size, buf, uc->data);
+		goto out;
+	}
+
+	ret = UCODE_OK;
+
+out:
+	if (ret == 0)
+		uci->mc = uc;
+	else
+		vfree(uc);
+
+	return ret;
+}
+
+static void xen_microcode_fini_cpu(int cpu)
+{
+	struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
+
+	vfree(uci->mc);
+	uci->mc = NULL;
+}
+
+static int xen_collect_cpu_info(int cpu, struct cpu_signature *sig)
+{
+	sig->sig = 0;
+	sig->pf = 0;
+	sig->rev = 0;
+
+	return 0;
+}
+
+static struct microcode_ops microcode_xen_ops = {
+	.request_microcode_user		  = xen_request_microcode_user,
+	.request_microcode_fw             = xen_request_microcode_fw,
+	.collect_cpu_info                 = xen_collect_cpu_info,
+	.apply_microcode                  = xen_microcode_update,
+	.microcode_fini_cpu               = xen_microcode_fini_cpu,
+};
+
+struct microcode_ops * __init init_xen_microcode(void)
+{
+	if (!xen_initial_domain())
+		return NULL;
+	return &microcode_xen_ops;
+}
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 5cc821c..4d04d4f 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -57,3 +57,7 @@ config XEN_DEBUG
 	help
 	  Enable various WARN_ON checks in the Xen MMU code.
 	  Enabling this option WILL incur a significant performance overhead.
+
+config MICROCODE_XEN
+       def_bool y
+       depends on XEN_DOM0 && MICROCODE
-- 
1.7.6.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Ping?

On 09/26/2011 11:17 AM, Jeremy Fitzhardinge wrote:
> From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>
> Hi all,
>
> I''m proposing this for the next merge window v3.2.
>
> I originally posted this early this year, and it prompted a debate
> about what the "proper" way that Linux should do microcode
updates,
> with the general concensus being "earlier", ideally in the
bootloader
> (or in the case of Xen, as the hypervisor boots before starting any
> domains).  However, as far as I know there has been no progress along
> those lines.
>
> I would like to therefore merge this so that a Linux kernel booting as
> dom0 under Xen can update the microcode in the same manner as a kernel
> booting natively.  When we work out how boot-time microcode updates
> can be done, then we''ll look at modifying Xen accordingly.  In the
> meantime, we should have a functional parity.
>
> The only change to this code from the previous posting is some patch
> restructuring so that regardless of how the platform.h ABI header gets
> merged (since there are some other pending branches containing it), it
> will be identical and cause no merge headaches.
>
> From original posting:
>
> This series adds a new "Xen" microcode update type, in addition
to
> Intel and AMD.
>
> The Xen hypervisor is responsible for performing the actual microcode
> update (since only it knows what physical CPUs are in the system and
> has sufficient privilege to access them), but it requires the dom0
> kernel to provide the actual microcode update data.
>
> Xen update mechanism is uniform independent of the CPU type, but the
> driver must know where to find the data file, which depends on the CPU
> type.  And since the update hypercall updates all CPUs, we only need
> to execute it once on any CPU - but for simplicity it just runs it only
> on (V)CPU 0.
>
> Thanks,
> 	J
>
> Jeremy Fitzhardinge (2):
>   xen: add dom0_op hypercall
>   xen: add CPU microcode update driver
>
> Yu Ke (1):
>   xen/acpi: Domain0 acpi parser related platform hypercall
>
>  arch/ia64/include/asm/xen/interface.h |    1 +
>  arch/x86/include/asm/microcode.h      |    9 +
>  arch/x86/include/asm/xen/hypercall.h  |    8 +
>  arch/x86/include/asm/xen/interface.h  |    1 +
>  arch/x86/kernel/Makefile              |    1 +
>  arch/x86/kernel/microcode_core.c      |    5 +-
>  arch/x86/kernel/microcode_xen.c       |  198 ++++++++++++++++++++
>  arch/x86/xen/Kconfig                  |    4 +
>  include/xen/interface/platform.h      |  320
+++++++++++++++++++++++++++++++++
>  include/xen/interface/xen.h           |    1 +
>  10 files changed, 547 insertions(+), 1 deletions(-)
>  create mode 100644 arch/x86/kernel/microcode_xen.c
>  create mode 100644 include/xen/interface/platform.h
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Oct 11, 2011 at 08:40:05PM -0400, Jeremy Fitzhardinge
wrote:
> Ping?
> 
> On 09/26/2011 11:17 AM, Jeremy Fitzhardinge wrote:
> > From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> >
> > Hi all,
> >
> > I''m proposing this for the next merge window v3.2.
> >
> > I originally posted this early this year, and it prompted a debate
> > about what the "proper" way that Linux should do microcode
updates,
> > with the general concensus being "earlier", ideally in the
bootloader
> > (or in the case of Xen, as the hypervisor boots before starting any
> > domains).  However, as far as I know there has been no progress along
> > those lines.
Err,

wait a sec, last time the suggestion was that _because_ xen supports the
multiboot protocol, implementing an early solution would be even easier
for you:

http://marc.info/?l=linux-kernel&m=129667641316947&w=2

Why would a xen microcode solution would even be contingent on how
upstream Linux solves it (and when)?

AFAICT, you want to hand off the microcode image from the bootloader to
the hypervisor and update ucode there - no need for dom0 changes...

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/12/2011 03:16 AM, Borislav Petkov wrote:
> On Tue, Oct 11, 2011 at 08:40:05PM -0400, Jeremy Fitzhardinge wrote:
>> Ping?
>>
>> On 09/26/2011 11:17 AM, Jeremy Fitzhardinge wrote:
>>> From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>>>
>>> Hi all,
>>>
>>> I''m proposing this for the next merge window v3.2.
>>>
>>> I originally posted this early this year, and it prompted a debate
>>> about what the "proper" way that Linux should do
microcode updates,
>>> with the general concensus being "earlier", ideally in
the bootloader
>>> (or in the case of Xen, as the hypervisor boots before starting any
>>> domains).  However, as far as I know there has been no progress
along
>>> those lines.
> Err,
>
> wait a sec, last time the suggestion was that _because_ xen supports the
> multiboot protocol, implementing an early solution would be even easier
> for you:
>
> http://marc.info/?l=linux-kernel&m=129667641316947&w=2
>
> Why would a xen microcode solution would even be contingent on how
> upstream Linux solves it (and when)?
>
> AFAICT, you want to hand off the microcode image from the bootloader to
> the hypervisor and update ucode there - no need for dom0 changes...
I don''t want a Xen-specific solution to this.  If Linux overall moves
to
a boot-time microcode loading scheme, then I''m happy to support it. 
But
in the meantime, I want a Xen system to Just Work in the same manner as
a non-Xen one, without requiring special support from all the distros.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/12/2011 03:16 AM, Borislav Petkov wrote:
> 
> Why would a xen microcode solution would even be contingent on how
> upstream Linux solves it (and when)?
> 
Agreed... especially since Xen is "special" when it comes to booting
anyway.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don''t speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/12/2011 11:18 AM, H. Peter Anvin wrote:
> On 10/12/2011 03:16 AM, Borislav Petkov wrote:
>> Why would a xen microcode solution would even be contingent on how
>> upstream Linux solves it (and when)?
>>
> Agreed... especially since Xen is "special" when it comes to
booting anyway.
"Special" only in the sense that you need a new line in grub.

But doing boot-time microcode is a lot more "special" since it would
require distros to move the microcode files to /boot.  That would either
mean having two sets of microcode packages, or also changing the way
that Linux does its microcode loading (if only by changing the paths,
but I have no idea what that implies since its all tied up with the rest
of the firmware loading stuff).

The whole thrust of the Xen upstreaming work has been to minimize the
amount of arbitrary "specialness" so that its as easy as possibly for
people and distros to deploy and use Xen.

With respect to microcode loading, this patch means that users and
distros just don''t need to worry about microcode any more.  It packages
and operates exactly like it would for native Linux, which is exactly
how we like it.

While doing the whole boot time multiboot thing may offer some small
hypothetical technical advantages, it has the significant cost of just
complicating the whole deployment and use story.

If there were a general shift to "this is how we''re going to do
microcode in the future", then Xen will happily go along for the ride. 
But for right now, this patch seems like the pragmatic solution.

I think the real question is where there''s something objectionable
about
the patch itself?

Thanks,
    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Oct 12, 2011 at 03:18:22PM -0400, Jeremy Fitzhardinge
wrote:
> While doing the whole boot time multiboot thing may offer some small
> hypothetical technical advantages, it has the significant cost of just
> complicating the whole deployment and use story.
You simply can''t call the need to apply ucode as early as possible a
"hypothetical techical advantage." Other issues like how to handle
ucode
images and how to put them together and how distros distribute them
and whether xen minimizes the amount of "specialness" or not are only
secondary.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/12/2011 12:18 PM, Jeremy Fitzhardinge wrote:
> If there were a general shift to "this is how we''re going to
do
> microcode in the future", then Xen will happily go along for the ride.
It *is* how we want to do microcode in the future.  There is a prototype 
for the Intel hardware side here; we just haven''t had time to finalize 
it partly because I got pulled onto the kernel.org situation.
> But for right now, this patch seems like the pragmatic solution.
No.
> I think the real question is where there''s something objectionable
about
> the patch itself?
"It does something that is slightly broken on real hardware and totally 
broken for a hypervisor and perpetuates it, while still needing enabling?"

	-hpa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Oct 12, 2011 at 09:45:43PM +0200, Borislav Petkov
wrote:
> On Wed, Oct 12, 2011 at 03:18:22PM -0400, Jeremy Fitzhardinge wrote:
> > While doing the whole boot time multiboot thing may offer some small
> > hypothetical technical advantages, it has the significant cost of just
> > complicating the whole deployment and use story.
> 
> You simply can''t call the need to apply ucode as early as possible
a
> "hypothetical techical advantage." Other issues like how to
handle ucode
> images and how to put them together and how distros distribute them
> and whether xen minimizes the amount of "specialness" or not are
only
> secondary.
Why is it paramount to do it as early as possible? As in, even doing
it before Linux kernel is invoked is preferred than during initrd runtime?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/12/2011 01:40 PM, Konrad Rzeszutek Wilk wrote:
> Why is it paramount to do it as early as possible? As in, even doing
> it before Linux kernel is invoked is preferred than during initrd runtime?
It is paramount to do it as early as possible *because the CPU is 
broken*.  That''s why there is a microcode update at all.  It is 
*supposed* to be installed by BIOS, but for whatever reason it wasn''t 
(including user doesn''t want to update the BIOS), so the very fact that
this is done in the OS at all is a bit of a fail.

Doing it in the bootloader is messy because bootloaders typically
aren''t
SMP-aware (and really shouldn''t need to be), which leaves the OS.  On 
native hardware it should ideally be done as early in the processor 
bringup as possible.

	-hpa

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Oct 12, 2011 at 05:31:50PM -0400, H. Peter Anvin
wrote:
> On 10/12/2011 01:40 PM, Konrad Rzeszutek Wilk wrote:
> > Why is it paramount to do it as early as possible? As in, even doing
> > it before Linux kernel is invoked is preferred than during initrd
runtime?
> 
> It is paramount to do it as early as possible *because the CPU is 
> broken*.  That''s why there is a microcode update at all.  It is 
> *supposed* to be installed by BIOS, but for whatever reason it
wasn''t
> (including user doesn''t want to update the BIOS), so the very fact
that
> this is done in the OS at all is a bit of a fail.
Oh, that''s easy: you know how OEMs support a platform for a while and
then move on to something new and stop updating BIOSen, including ucode
images contained in them?

Well, in that case, the OS is the last possible place where we want to
be able to apply the ucode. And, we want to apply it as _early_ _as_
_possible_. Bootloader doesn''t cut it as hpa says below, so next comes
SMP cores bootup code. That''s it.
> Doing it in the bootloader is messy because bootloaders typically
> aren''t SMP-aware (and really shouldn''t need to be), which
leaves the
> OS. On native hardware it should ideally be done as early in the
> processor bringup as possible.
Yep.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/12/2011 12:45 PM, Borislav Petkov wrote:
> On Wed, Oct 12, 2011 at 03:18:22PM -0400, Jeremy Fitzhardinge wrote:
>> While doing the whole boot time multiboot thing may offer some small
>> hypothetical technical advantages, it has the significant cost of just
>> complicating the whole deployment and use story.
> You simply can''t call the need to apply ucode as early as possible
a
> "hypothetical techical advantage."
The current scheme has worked pretty well so far; there doesn''t seem to
be a huge concern about it.  Have there been actual observed failures
with the current mechanism, or is the drive to make it earlier driven by
an aesthetic desire to make it "as it should be"?
>  Other issues like how to handle ucode
> images and how to put them together and how distros distribute them
> and whether xen minimizes the amount of "specialness" or not are
only
> secondary.
No, they''re not.  If users end up with a broken setup then they get no
microcode updates at all, which makes everything else moot.  It has to
be deployed correctly for it to be worth anything at all.

What is secondary, or rather, completely irrelevant is whether Xen is
involved or not.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/12/2011 03:27 PM, Jeremy Fitzhardinge wrote:
>
> The current scheme has worked pretty well so far; there doesn''t
seem to
> be a huge concern about it.  Have there been actual observed failures
> with the current mechanism, or is the drive to make it earlier driven by
> an aesthetic desire to make it "as it should be"?
>
Yes, there has.  There is at least one case where we have to print an 
error message saying "update your BIOS" because our current microcode 
update is too late.

	-hpa

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/12/2011 03:29 PM, H. Peter Anvin wrote:
> On 10/12/2011 03:27 PM, Jeremy Fitzhardinge wrote:
>>
>> The current scheme has worked pretty well so far; there
doesn''t seem to
>> be a huge concern about it.  Have there been actual observed failures
>> with the current mechanism, or is the drive to make it earlier driven
by
>> an aesthetic desire to make it "as it should be"?
>>
>
> Yes, there has.  There is at least one case where we have to print an
> error message saying "update your BIOS" because our current
microcode
> update is too late.
Is that K8 errata 93 or something else?

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/12/2011 01:22 PM, H. Peter Anvin wrote:
> On 10/12/2011 12:18 PM, Jeremy Fitzhardinge wrote:
>> If there were a general shift to "this is how we''re going
to do
>> microcode in the future", then Xen will happily go along for the
ride.
>
> It *is* how we want to do microcode in the future.  There is a
> prototype for the Intel hardware side here; we just haven''t had
time
> to finalize it partly because I got pulled onto the kernel.org situation.
OK, great!  Has there been any public discussion about this?

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/12/2011 03:33 PM, Jeremy Fitzhardinge wrote:
>>
>> Yes, there has.  There is at least one case where we have to print an
>> error message saying "update your BIOS" because our current
microcode
>> update is too late.
>
> Is that K8 errata 93 or something else?
>
The one I''m thinking about is an Atom erratum, but it''s
entirely
possible there are others.

	-hpa



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/12/2011 03:34 PM, Jeremy Fitzhardinge wrote:
>>
>> It *is* how we want to do microcode in the future.  There is a
>> prototype for the Intel hardware side here; we just haven''t
had time
>> to finalize it partly because I got pulled onto the kernel.org
situation.
>
> OK, great!  Has there been any public discussion about this?
>
I don''t remember.

	-hpa



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Oct 12, 2011 at 06:33:28PM -0400, Jeremy Fitzhardinge
wrote:
> On 10/12/2011 03:29 PM, H. Peter Anvin wrote:
> > On 10/12/2011 03:27 PM, Jeremy Fitzhardinge wrote:
> >>
> >> The current scheme has worked pretty well so far; there
doesn''t seem to
> >> be a huge concern about it.  Have there been actual observed
failures
> >> with the current mechanism, or is the drive to make it earlier
driven by
> >> an aesthetic desire to make it "as it should be"?
> >>
> >
> > Yes, there has.  There is at least one case where we have to print an
> > error message saying "update your BIOS" because our current
microcode
> > update is too late.
> 
> Is that K8 errata 93 or something else?
AFAIR, that was an Atom erratum fix.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

The stickiest part of all of this is where to leave the microcode so the 
kernel can get to it way early.  We could use the linked list, but that 
would mean bootloader enabling; another idea was to stick it as a prefix 
to the initramfs identified by a signature.

	-hpa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/12/2011 03:49 PM, H. Peter Anvin wrote:
> The stickiest part of all of this is where to leave the microcode so
> the kernel can get to it way early.  We could use the linked list, but
> that would mean bootloader enabling; another idea was to stick it as a
> prefix to the initramfs identified by a signature.
I think it would be easiest for the multiboot case if it were a separate
file, but I don''t feel I''m really up on all the details.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/12/2011 04:40 PM, Jeremy Fitzhardinge wrote:
> On 10/12/2011 03:49 PM, H. Peter Anvin wrote:
>> The stickiest part of all of this is where to leave the microcode so
>> the kernel can get to it way early.  We could use the linked list, but
>> that would mean bootloader enabling; another idea was to stick it as a
>> prefix to the initramfs identified by a signature.
>
> I think it would be easiest for the multiboot case if it were a separate
> file, but I don''t feel I''m really up on all the details.
For the multiboot case, yes of course.

Some bootloaders allow initramfs to be concatenated from multiple files; 
unfortunately I''m not sure if Grub ever grew that capability.  Sigh.

	-hpa



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/12/2011 04:55 PM, H. Peter Anvin wrote:
> On 10/12/2011 04:40 PM, Jeremy Fitzhardinge wrote:
>> On 10/12/2011 03:49 PM, H. Peter Anvin wrote:
>>> The stickiest part of all of this is where to leave the microcode
so
>>> the kernel can get to it way early.  We could use the linked list,
but
>>> that would mean bootloader enabling; another idea was to stick it
as a
>>> prefix to the initramfs identified by a signature.
>>
>> I think it would be easiest for the multiboot case if it were a
separate
>> file, but I don''t feel I''m really up on all the
details.
>
> For the multiboot case, yes of course.
>
> Some bootloaders allow initramfs to be concatenated from multiple
> files; unfortunately I''m not sure if Grub ever grew that
capability.
> Sigh.
Presumably we''d want some way to make all possible microcode files
available to the hypervisor/kernel so that there''s no need to construct
the bootloader config for a specific CPU vendor (or worse, CPU model). 
So that would need either some way of specifying multiple files, or a
wrapper which can contain multiple files?

    J


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/12/2011 05:00 PM, Jeremy Fitzhardinge wrote:
>
> Presumably we''d want some way to make all possible microcode files
> available to the hypervisor/kernel so that there''s no need to
construct
> the bootloader config for a specific CPU vendor (or worse, CPU model).
> So that would need either some way of specifying multiple files, or a
> wrapper which can contain multiple files?
>
I have been thinking a "bundle" format with a per-vendor header
followed
by the microcode in the appropriate format for each vendor.

	-hpa



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Oct 12, 2011 at 08:03:50PM -0400, H. Peter Anvin
wrote:
> On 10/12/2011 05:00 PM, Jeremy Fitzhardinge wrote:
> >
> > Presumably we''d want some way to make all possible microcode
files
> > available to the hypervisor/kernel so that there''s no need to
construct
> > the bootloader config for a specific CPU vendor (or worse, CPU model).
> > So that would need either some way of specifying multiple files, or a
> > wrapper which can contain multiple files?
> >
> 
> I have been thinking a "bundle" format with a per-vendor header
followed
> by the microcode in the appropriate format for each vendor.
Yes, makes sense. Keep it as simple as possible.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Oct 12, 2011 at 06:49:51PM -0400, H. Peter Anvin
wrote:
> The stickiest part of all of this is where to leave the microcode so the 
> kernel can get to it way early.  We could use the linked list, but that 
> would mean bootloader enabling;
Yep, started looking at that and it means grub legacy and grub2 enabling
at least.
> another idea was to stick it as a prefix 
> to the initramfs identified by a signature.
https://bugzilla.redhat.com/show_bug.cgi?id=179127

with the patch there you can do

initrd /initramfs-image1.gz /initramfs-image2.gz

which is exactly what we want.

Bottomline is, extending initrd handling to deal with multiple initrd
images might turn out to be easier to do than the linked list deal.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, Oct 13, 2011 at 03:33:52AM -0400, Borislav Petkov
wrote:
> Bottomline is, extending initrd handling to deal with multiple initrd
> images might turn out to be easier to do than the linked list deal.
Alternatively and IMHO, we could avoid the bootloader enabling by
making the ucode part of the initramfs and pull up some of the
prepare_namespace() work in kernel_init() before smp_init() so that we
can have it ready for when bootstrapping the cores.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/13/2011 02:57 AM, Borislav Petkov wrote:
> On Thu, Oct 13, 2011 at 03:33:52AM -0400, Borislav Petkov wrote:
>> Bottomline is, extending initrd handling to deal with multiple initrd
>> images might turn out to be easier to do than the linked list deal.
> 
> Alternatively and IMHO, we could avoid the bootloader enabling by
> making the ucode part of the initramfs and pull up some of the
> prepare_namespace() work in kernel_init() before smp_init() so that we
> can have it ready for when bootstrapping the cores.
> 
I think that is really ugly, and it also makes it much harder to get the
microcode patch in early on the BSP.  There are enough issues where we
would like to get the microcode in early even on the BSP.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don''t speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

H. Peter Anvin writes ("[Xen-devel] Re: [PATCH 0/3] x86/microcode: support
for microcode update in Xen dom0"):
> On 10/12/2011 12:18 PM, Jeremy Fitzhardinge wrote:
> > But for right now, this patch seems like the pragmatic solution.
> 
> No.
This is a quite astonishing response.  At the moment, microcode
updates in Xen systems are _completely broken_ because they do not
happen at all.

The existing machinery in Linux is the way it is and you say it''s no
good - how about we just remove it all too ?  Because that''s what
you''re suggesting is the proper course for Xen!

At the moment, Jeremy''s patch is a significant improvement.  It is
quite unreasonable to block it because some pie-in-the-sky scheme for
doing it at boot time does not exist yet.

Either:
 (a) Jeremy''s patch should go in
 (b) all after-boot microcode update code should be removed from Linux

Ian.
(very cross)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, Oct 13, 2011 at 11:57:08AM +0200, Borislav Petkov
wrote:
> On Thu, Oct 13, 2011 at 03:33:52AM -0400, Borislav Petkov wrote:
> > Bottomline is, extending initrd handling to deal with multiple initrd
> > images might turn out to be easier to do than the linked list deal.
> 
> Alternatively and IMHO, we could avoid the bootloader enabling by
> making the ucode part of the initramfs and pull up some of the
> prepare_namespace() work in kernel_init() before smp_init() so that we
> can have it ready for when bootstrapping the cores.
<scratches his head>
You are still using the microcode API (the existing one) to
program the CPUs right? It is just that you are fetching the images
much much earlier than it currently is done?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/17/2011 10:08 AM, Konrad Rzeszutek Wilk wrote:
> 
> <scratches his head>
> You are still using the microcode API (the existing one) to
> program the CPUs right? It is just that you are fetching the images
> much much earlier than it currently is done?
> 
No, the goal is to ditch the existing API and load the CPUs very early
in the start path.

	-hpa

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, 17 Oct 2011, H. Peter Anvin wrote:
> On 10/17/2011 10:08 AM, Konrad Rzeszutek Wilk wrote:
> > <scratches his head>
> > You are still using the microcode API (the existing one) to
> > program the CPUs right? It is just that you are fetching the images
> > much much earlier than it currently is done?
> > 
> 
> No, the goal is to ditch the existing API and load the CPUs very early
> in the start path.
And how do we apply new microcode at runtime?  A new API?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/17/11 19:40, H. Peter Anvin wrote:
> On 10/17/2011 10:08 AM, Konrad Rzeszutek Wilk wrote:
>>
>> <scratches his head>
>> You are still using the microcode API (the existing one) to
>> program the CPUs right? It is just that you are fetching the images
>> much much earlier than it currently is done?
>>
>
> No, the goal is to ditch the existing API and load the CPUs very early
> in the start path.
>
> 	-hpa
I think this approach is good to get the microcode applied as
early as possible at boot time. But on servers you usually do not want
to reboot the machine unless you do a BIOS update which will apply
the new microcode anyway. So for applying the microcode update
at runtime I would like to keep the existing API.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Oct 18, 2011 at 04:56:22AM -0400, Christoph Egger
wrote:
> I think this approach is good to get the microcode applied as
> early as possible at boot time. But on servers you usually do not want
> to reboot the machine unless you do a BIOS update which will apply
> the new microcode anyway. So for applying the microcode update
> at runtime I would like to keep the existing API.
No, you don''t want to keep the existing API and you know it.
I''ve
explained to you last week why.

-- 
Regards/Gruss,
Boris.

Operating Systems Research Center
Advanced Micro Devices, Inc.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/18/11 11:35, Borislav Petkov wrote:
> On Tue, Oct 18, 2011 at 04:56:22AM -0400, Christoph Egger wrote:
>> I think this approach is good to get the microcode applied as
>> early as possible at boot time. But on servers you usually do not want
>> to reboot the machine unless you do a BIOS update which will apply
>> the new microcode anyway. So for applying the microcode update
>> at runtime I would like to keep the existing API.
>
> No, you don''t want to keep the existing API and you know it.
I''ve
> explained to you last week why.
>
By "existing API" I mean the xen hypercall. Sorry for the confusion.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Borislav Petkov writes ("Re: [Xen-devel] Re: [PATCH 0/3] x86/microcode:
support for microcode update in Xen dom0"):
> No, you don''t want to keep the existing API and you know it.
I''ve
> explained to you last week why.
So should I submit a patchset to remove the existing post-boot
microcode loading from Linux ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

After pulling in this change from your tree, I found the following bug,
when checking an enum value, which should be considered before inclusion:


diff --git a/arch/x86/kernel/microcode_xen.c
b/arch/x86/kernel/microcode_xen.c
index 9d2a06b..6a73957 100644
--- a/arch/x86/kernel/microcode_xen.c
+++ b/arch/x86/kernel/microcode_xen.c
@@ -157,7 +157,7 @@ static enum ucode_state xen_request_microcode_user(int
cpu,
  ret = UCODE_OK;

 out:
- if (ret == 0)
+ if (ret == UCODE_OK)
  uci->mc = uc;
  else
  vfree(uc);



On Mon, Sep 26, 2011 at 2:17 PM, Jeremy Fitzhardinge
<jeremy@goop.org>wrote:
> From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>
> Hi all,
>
> I''m proposing this for the next merge window v3.2.
>
> I originally posted this early this year, and it prompted a debate
> about what the "proper" way that Linux should do microcode
updates,
> with the general concensus being "earlier", ideally in the
bootloader
> (or in the case of Xen, as the hypervisor boots before starting any
> domains).  However, as far as I know there has been no progress along
> those lines.
>
> I would like to therefore merge this so that a Linux kernel booting as
> dom0 under Xen can update the microcode in the same manner as a kernel
> booting natively.  When we work out how boot-time microcode updates
> can be done, then we''ll look at modifying Xen accordingly.  In the
> meantime, we should have a functional parity.
>
> The only change to this code from the previous posting is some patch
> restructuring so that regardless of how the platform.h ABI header gets
> merged (since there are some other pending branches containing it), it
> will be identical and cause no merge headaches.
>
> >From original posting:
>
> This series adds a new "Xen" microcode update type, in addition
to
> Intel and AMD.
>
> The Xen hypervisor is responsible for performing the actual microcode
> update (since only it knows what physical CPUs are in the system and
> has sufficient privilege to access them), but it requires the dom0
> kernel to provide the actual microcode update data.
>
> Xen update mechanism is uniform independent of the CPU type, but the
> driver must know where to find the data file, which depends on the CPU
> type.  And since the update hypercall updates all CPUs, we only need
> to execute it once on any CPU - but for simplicity it just runs it only
> on (V)CPU 0.
>
> Thanks,
>        J
>
> Jeremy Fitzhardinge (2):
>  xen: add dom0_op hypercall
>  xen: add CPU microcode update driver
>
> Yu Ke (1):
>  xen/acpi: Domain0 acpi parser related platform hypercall
>
>  arch/ia64/include/asm/xen/interface.h |    1 +
>  arch/x86/include/asm/microcode.h      |    9 +
>  arch/x86/include/asm/xen/hypercall.h  |    8 +
>  arch/x86/include/asm/xen/interface.h  |    1 +
>  arch/x86/kernel/Makefile              |    1 +
>  arch/x86/kernel/microcode_core.c      |    5 +-
>  arch/x86/kernel/microcode_xen.c       |  198 ++++++++++++++++++++
>  arch/x86/xen/Kconfig                  |    4 +
>  include/xen/interface/platform.h      |  320
> +++++++++++++++++++++++++++++++++
>  include/xen/interface/xen.h           |    1 +
>  10 files changed, 547 insertions(+), 1 deletions(-)
>  create mode 100644 arch/x86/kernel/microcode_xen.c
>  create mode 100644 include/xen/interface/platform.h
>
> --
> 1.7.6.2
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 11/03/2011 08:06 AM, Ben Guthro wrote:
> After pulling in this change from your tree, I found the following
> bug, when checking an enum value, which should be considered before
> inclusion:
>
>
> diff --git a/arch/x86/kernel/microcode_xen.c
> b/arch/x86/kernel/microcode_xen.c
> index 9d2a06b..6a73957 100644
> --- a/arch/x86/kernel/microcode_xen.c
> +++ b/arch/x86/kernel/microcode_xen.c
> @@ -157,7 +157,7 @@ static enum ucode_state
> xen_request_microcode_user(int cpu,
>  ret = UCODE_OK;
>  
>  out:
> -if (ret == 0)
> +if (ret == UCODE_OK)
>  uci->mc = uc;
>  else
>  vfree(uc);
Thanks!

    J


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Am 13.10.2011 09:00, schrieb Borislav Petkov:
> On Wed, Oct 12, 2011 at 08:03:50PM -0400, H. Peter Anvin wrote:
>> On 10/12/2011 05:00 PM, Jeremy Fitzhardinge wrote:
>>>
>>> Presumably we''d want some way to make all possible
microcode files
>>> available to the hypervisor/kernel so that there''s no need
to construct
>>> the bootloader config for a specific CPU vendor (or worse, CPU
model).
>>> So that would need either some way of specifying multiple files, or
a
>>> wrapper which can contain multiple files?
>>>
>>
>> I have been thinking a "bundle" format with a per-vendor
header followed
>> by the microcode in the appropriate format for each vendor.
> 
> Yes, makes sense. Keep it as simple as possible.
For the majority of the past 10 years, the microcode has been shipped as
one big file (at least for intel).
So have you looked at the file format of the bundles that already exist?