Thanks for getting the other patches in the series onto master, Jan.
This is the only patch out of this series that did not make it through,
so I keeping my comments here.
On 23.01.20 11:26, Jan Beulich wrote:
On 22.01.2020 23:30, Eslam Elnikety wrote:
Decouple the microcode indexing
On 21.01.20 21:51, Eslam Elnikety wrote:
On 21.01.20 10:27, Jan Beulich wrote:
On 21.01.2020 00:50, Eslam Elnikety wrote:
On 20.01.20 09:42, Jan Beulich wrote:
On 17.01.2020 20:06, Eslam Elnikety wrote:
On 20.12.19 10:53, Jan Beulich wrote:
On 19.12.2019 22:08, Eslam Elnikety wrote
The buffer holding the microcode bits should be marked as const.
Signed-off-by: Eslam Elnikety
Acked-by: Jan Beulich
---
xen/arch/x86/microcode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
index a662a7f438
Specify applicability and the default value. Also state that, in case of
EFI, the microcode update blob specified in the EFI cfg takes precedence
over `ucode=scan`, if the latter is specified on Xen commend line.
No functional changes.
Signed-off-by: Eslam Elnikety
---
docs/misc/xen-command
otherwise as before
Eslam Elnikety (4):
x86/microcode: Improve documentation for ucode=
x86/microcode: Improve parsing for ucode=
x86/microcode: avoid unnecessary xmalloc/memcpy of ucode data
x86/microcode: use const qualifier for microcode buffer
docs/misc/xen-command-line.pandoc | 14 +
corresponding to the BSP gets xmalloc()'d and
populated after the fact.
Signed-off-by: Eslam Elnikety
Acked-by: Jan Beulich
---
xen/arch/x86/microcode.c | 32
1 file changed, 4 insertions(+), 28 deletions(-)
diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86
es. Update the command line documentation for
consistency. As an added benefit, the 'parse_ucode' logic becomes
independent of GRUB vs. EFI.
While at it, drop the leading comment for parse_ucode. No practical
use for it given this commit.
Signed-off-by: Eslam Elnikety
---
docs/misc/xen-command-l
On 21.01.20 10:27, Jan Beulich wrote:
On 21.01.2020 00:50, Eslam Elnikety wrote:
On 20.01.20 09:42, Jan Beulich wrote:
On 17.01.2020 20:06, Eslam Elnikety wrote:
On 20.12.19 10:53, Jan Beulich wrote:
On 19.12.2019 22:08, Eslam Elnikety wrote:
On 18.12.19 12:49, Jan Beulich wrote
On 20.01.20 09:42, Jan Beulich wrote:
On 17.01.2020 20:06, Eslam Elnikety wrote:
On 20.12.19 10:53, Jan Beulich wrote:
On 19.12.2019 22:08, Eslam Elnikety wrote:
On 18.12.19 12:49, Jan Beulich wrote:
On 18.12.2019 02:32, Eslam Elnikety wrote:
Decouple the microcode referencing mechanism
On 20.12.19 11:34, Jürgen Groß wrote:
On 20.12.19 11:12, Jan Beulich wrote:
On 19.12.2019 23:11, Eslam Elnikety wrote:
On 18.12.19 13:42, Jan Beulich wrote:
On 18.12.2019 02:32, Eslam Elnikety wrote:
--- /dev/null
+++ b/xen/arch/x86/microcode/Makefile
@@ -0,0 +1,46 @@
+# Copyright (C) 2019
On 20.12.19 11:12, Jan Beulich wrote:
On 19.12.2019 23:11, Eslam Elnikety wrote:
On 18.12.19 13:42, Jan Beulich wrote:
On 18.12.2019 02:32, Eslam Elnikety wrote:
--- /dev/null
+++ b/xen/arch/x86/microcode/Makefile
@@ -0,0 +1,46 @@
+# Copyright (C) 2019 Amazon.com, Inc. or its affiliates
Picking this up again after the break. Apologies for the delay.
On 20.12.19 10:53, Jan Beulich wrote:
On 19.12.2019 22:08, Eslam Elnikety wrote:
On 18.12.19 12:49, Jan Beulich wrote:
On 18.12.2019 02:32, Eslam Elnikety wrote:
Decouple the microcode referencing mechanism when using GRUB
On 18.12.19 13:42, Jan Beulich wrote:
On 18.12.2019 02:32, Eslam Elnikety wrote:
+
+
+Xen can bundle microcode updates within its image. This support is conditional
+on the build configuration BUILTIN_UCODE being enabled. Builtin microcode is
+useful
On 18.12.19 13:05, Jan Beulich wrote:
On 18.12.2019 02:32, Eslam Elnikety wrote:
@@ -725,7 +701,7 @@ static int __init microcode_init(void)
*/
if ( ucode_blob.size )
{
-xfree(ucode_blob.data);
+bootstrap_map(NULL);
As much as I like the change, I
On 18.12.19 12:49, Jan Beulich wrote:
On 18.12.2019 02:32, Eslam Elnikety wrote:
Decouple the microcode referencing mechanism when using GRUB to that
when using EFI. This allows us to avoid the "unspecified effect" of
using ` | scan` along xen.efi.
I guess "unspecified eff
corresponding to the BSP gets xmalloc()'d and
populated after the fact.
Signed-off-by: Eslam Elnikety
---
xen/arch/x86/microcode.c | 32
1 file changed, 4 insertions(+), 28 deletions(-)
diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
index 8b4d87782c
ng via EFI) takes precedence over the builtin one.
Signed-off-by: Eslam Elnikety
---
Changes in v2:
- Allow for ucode=|scan,{no-}builtin and detail the model. Reflect
those changes onto microcode.c and docs/misc/xen-command-line.pandoc
- Add documentation to the existing docs/admin-guide
rd parsing of the ucode parameter. While at it,
simplify the logic in microcode_grab_module().
Update the command line documentation for consistency. Also, drop the
leading comment for parse_ucode_param. (No practical use for it given
this commit).
Signed-off-by: Eslam Elnikety
---
docs/misc/x
builtin suppot (Patch 4).
Changes in v2:
- An earlier version of Patch 4 was submitted in isolation. Refer to the
patch itself for details regarding the relevant changes.
- Patches 1--3 are additions.
Eslam Elnikety (4):
x86/microcode: Improve documentation and parsing for ucode=
x86/microcode
The buffer holding the microcode bits should be marked as const.
Signed-off-by: Eslam Elnikety
---
xen/arch/x86/microcode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
index c878fc71ff..4616fa9d2e 100644
--- a/xen
On 13.12.19 14:40, Andrew Cooper wrote:
On 09/12/2019 21:49, Eslam Elnikety wrote:
+
+extern const char __builtin_intel_ucode_start[],
__builtin_intel_ucode_end[];
+extern const char __builtin_amd_ucode_start[],
__builtin_amd_ucode_end[];
+#endif
+
/* By default, ucode loading is done in NMI
On 13.12.19 14:57, Andrew Cooper wrote:
On 12/12/2019 22:13, Eslam Elnikety wrote:
Second, there is often need to couple a Xen build with a minimum
microcode patch level. Having the microcode built within the Xen image
itself is a streamlined, natural way of achieving that.
Okay, I can accept
On 11.12.19 10:54, Jan Beulich wrote:
On 11.12.2019 00:18, Eslam Elnikety wrote:
On 10.12.19 10:37, Jan Beulich wrote:
On 09.12.2019 09:41, Eslam Elnikety wrote:
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2113,7 +2113,7 @@ logic applies:
active
On 11.12.19 10:47, Jan Beulich wrote:
On 10.12.2019 23:40, Eslam Elnikety wrote:
On 10.12.19 10:21, Jan Beulich wrote:
On 09.12.2019 22:49, Eslam Elnikety wrote:
On 09.12.19 16:19, Andrew Cooper wrote:
On 09/12/2019 08:41, Eslam Elnikety wrote:
--- /dev/null
+++ b/xen/arch/x86/microcode
On 10.12.19 10:37, Jan Beulich wrote:
On 09.12.2019 09:41, Eslam Elnikety wrote:
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2113,7 +2113,7 @@ logic applies:
active by default.
### ucode (x86)
-> `= List of [ | scan=, nmi= ]`
+> `
On 10.12.19 10:21, Jan Beulich wrote:
On 09.12.2019 22:49, Eslam Elnikety wrote:
On 09.12.19 16:19, Andrew Cooper wrote:
On 09/12/2019 08:41, Eslam Elnikety wrote:
--- /dev/null
+++ b/xen/arch/x86/microcode/Makefile
@@ -0,0 +1,40 @@
+# Copyright (C) 2019 Amazon.com, Inc. or its affiliates
On 09.12.19 16:19, Andrew Cooper wrote:
On 09/12/2019 08:41, Eslam Elnikety wrote:
diff --git a/docs/misc/builtin-ucode.txt b/docs/misc/builtin-ucode.txt
new file mode 100644
index 00..43bb60d3eb
Instead of introducing a new file, please extend
docs/admin-guide/microcode-loading.rst
the update.
A Xen image with builtin microcode can be explicitly instructed to:
(a) look for microcode elsewhere (e.g., a boot module that contains more
recent microcodes via ucode=scan), or
(b) skip the builtin microcode update (e.g., ucode=no-builtin).
Signed-off-by: Eslam Elnikety
Thanks for this series, Jan.
On 30.10.19 11:39, Jan Beulich wrote:
To fulfill the "protected" in its name, don't let the real hardware
values "shine through". Report a control register value expressing this.
Signed-off-by: Jan Beulich
---
TBD: Do we want to permit Dom0 access?
It would be
On 14.08.19 15:02, Andrew Cooper wrote:
On 14/08/2019 13:51, George Dunlap wrote:
On 8/7/19 5:03 PM, Jan Beulich wrote:
Whatever we do in Xen, it'll only allow to work around that issue.
An actual fix belongs in the kernel(s). For this reason I suppose
what we're talking about here is a
xen_evtchn_2l_init();
and xen_evtchn_fifo_init fails when EVTCHNOP_init_control fails. This commit
does not change the current default behaviour: announce FIFO event channels
ABI support for guests unless explicitly stated otherwise at domaincreate.
Signed-off-by: Eslam Elnikety
---
Changes in
plain text reading of it discarded the
markings. If so - please don't send HTML mail.)
Oopsy. It was HTML. I will be more diligent going forward :)
On 8. Aug 2019, at 15:27, Jan Beulich
mailto:jbeul...@suse.com>> wrote:
On 07.08.2019 19:42, Eslam Elnikety wrote:
--- a/xen/common/event_cha
xen_evtchn_2l_init();
and xen_evtchn_fifo_init fails when EVTCHNOP_init_control fails. This commit
does not change the current default behaviour: announce FIFO event channels
ABI support for guests unless explicitly stated otherwise at domaincreate.
Signed-off-by: Eslam Elnikety
---
Changes in
hen EVTCHNOP_init_control fails. This commit
does not change the current default behaviour: announce FIFO event channels
ABI support for guests unless explicitly stated otherwise at domaincreate.
Signed-off-by: Eslam Elnikety
---
docs/man/xl.cfg.5.pod.in| 5 +
tools/libxl/libxl.h | 8
to
unless
specified otherwise.
Signed-off-by: Eslam Elnikety
---
Changes in v2:
- Added a missing hunk / setting vkb_device per config
Changes in v3:
- Added entries in libxl.h and in documentation
---
docs/man/xl.cfg.pod.5.in| 4
tools/libxl/libxl.h | 9
unless
specified otherwise.
Signed-off-by: Eslam Elnikety
---
Changes in v2:
- Added a missing hunk / setting vkb_device per config
---
tools/libxl/libxl_create.c | 9 ++---
tools/libxl/libxl_types.idl | 1 +
tools/xl/xl_parse.c | 1 +
tools/xl/xl_sxp.c | 2 ++
4
Give the administrator further control on when to scrub domheap pages by adding
an option to always scrub. This is a safety feature that, when enabled,
prevents a (buggy) domain from leaking secrets if it accidentally frees a page
without proper scrubbing.
Signed-off-by: Eslam Elnikety
Acked
unless
specified otherwise.
Signed-off-by: Eslam Elnikety
---
tools/libxl/libxl_create.c | 9 ++---
tools/libxl/libxl_types.idl | 1 +
tools/xl/xl_sxp.c | 2 ++
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index
Give the administrator further control on when to scrub domheap pages by adding
an option to always scrub. This is a safety feature that, when enabled,
prevents a (buggy) domain from leaking secrets if it accidentally frees a page
without proper scrubbing.
Signed-off-by: Eslam Elnikety
---
docs
happen AFTER the unpause. This bug was introduced in commit be650750945
"credit1: Use atomic bit operations for the flags structure".
Original patch author credit: Xi Xiong while at Amazon.
Signed-off-by: Eslam Elnikety
Reviewed-by: Leonard Foerster
Reviewed-by: Petre Eftime
Acked
happen AFTER the unpause. This bug was introduced in commit be650750945
"credit1: Use atomic bit operations for the flags structure".
Original patch author credit: Xi Xiong.
Signed-off-by: Eslam Elnikety
Reviewed-by: Leonard Foerster
Reviewed-by: Petre Eftime
---
xen/common/sched_cr
41 matches
Mail list logo
