Currently it's impossible to get CPU's microcode revision from Xen after
late loading without looking into Xen logs which is not always convenient.
Add a new platform op in order to get the required data from Xen and
provide a wrapper for libxenctrl.
Signed-off-by: Sergey Dyasli
Reviewed
Currently it's impossible to get CPU's microcode revision from Xen after
late loading without looking into Xen logs which is not always convenient.
Add an option to xen-ucode tool to print the currently loaded ucode
revision.
Sergey Dyasli (3):
tools/xenctrl: add xc_get_cpu_version()
x86
-55-04 (raw 0x00050654) pf 0x1 revision 0x02006e05
AMD: CPU signature 19-01-01 (raw 0x00a00f11) revision 0x0a0011ce
Signed-off-by: Sergey Dyasli
---
v4 --> v5:
- Changed AMD output to be FF-MM-SS instead of famXX
- Modified usage string
- Fixed fprintf indentation
- Printing error messa
As a wrapper for XENPF_get_cpu_version platform op.
Signed-off-by: Sergey Dyasli
Reviewed-by: Andrew Cooper
---
v4 --> v5:
- Added Reviewed-by
v3 --> v4:
- Replaced DECLARE_PLATFORM_OP
- Removed NULL checks
---
tools/include/xenctrl.h | 1 +
tools/libs/ctrl/xc_misc.
Posting v4 with addressed review comments. Changes from v3 are available
in each patch.
Sergey Dyasli (3):
tools/xenctrl: add xc_get_cpu_version()
x86/platform: introduce XENPF_get_ucode_revision
tools/xen-ucode: print information about currently loaded ucode
tools/include/xenctrl.h
06-55-04 (raw 0x00050654) pf 0x1 revision 0x02006e05
AMD:
CPU signature fam19h (raw 0x00a00f11) revision 0x0a0011ce
Signed-off-by: Sergey Dyasli
---
v3 --> v4:
- changed the output to be 1-line long
- made xc_interface *xch global
- added error checking to xc calls
- added er
As a wrapper for XENPF_get_cpu_version platform op.
Signed-off-by: Sergey Dyasli
---
v3 --> v4:
- Replaced DECLARE_PLATFORM_OP
- Removed NULL checks
---
tools/include/xenctrl.h | 1 +
tools/libs/ctrl/xc_misc.c | 17 +
2 files changed, 18 insertions(+)
diff --git a/to
Currently it's impossible to get CPU's microcode revision from Xen after
late loading without looking into Xen logs which is not always convenient.
Add a new platform op in order to get the required data from Xen and
provide a wrapper for libxenctrl.
Signed-off-by: Sergey Dyasli
---
v3 -->
ading")
> Signed-off-by: Andrew Cooper
Reviewed-by: Sergey Dyasli
Thanks,
Sergey
As a wrapper for XENPF_get_cpu_version platform op.
Signed-off-by: Sergey Dyasli
---
tools/include/xenctrl.h | 1 +
tools/libs/ctrl/xc_misc.c | 20
2 files changed, 21 insertions(+)
diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 23037874d3
Currently it's impossible to get CPU's microcode revision after late
loading without looking into Xen logs which is not always convenient.
Add a new platform op in order to get the required data from Xen and
provide a wrapper for libxenctrl.
Signed-off-by: Sergey Dyasli
---
tools/include
For v3 I've removed the usage of xenhypfs and gone back to adding
a new platform op.
Sergey Dyasli (3):
tools/xenctrl: add xc_get_cpu_version()
x86/platform: introduce XENPF_get_ucode_version
tools/xen-ucode: print information about currently loaded ucode
tools/include/xenctrl.h
signature is: 06-55-04 (raw 0x50654)
Current CPU microcode revision is: 0x2006e05
Current CPU processor flags are: 0x1
AMD:
Current CPU signature is: fam19h (raw 0xa00f11)
Current CPU microcode revision is: 0xa0011a8
Signed-off-by: Sergey Dyasli
---
tools/misc/xen-ucode.c | 66
On Wed, Mar 1, 2023 at 11:31 AM Jan Beulich wrote:
>
> On 28.02.2023 18:39, Sergey Dyasli wrote:
> > Add an option to xen-ucode tool to print the currently loaded ucode
> > version and also print it during usage info. Print CPU signature and
> > processor flags as well.
As a wrapper for XENPF_get_cpu_version platform op.
Signed-off-by: Sergey Dyasli
---
tools/include/xenctrl.h | 1 +
tools/libs/ctrl/xc_misc.c | 20
2 files changed, 21 insertions(+)
diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 23037874d3
:
Current CPU signature is: 06-55-04 (raw 0x50654)
Current CPU microcode revision is: 0x2006e05
Current CPU processor flags are: 0x1
AMD:
Current CPU signature is: fam19h (raw 0xa00f11)
Current CPU microcode revision is: 0xa0011a8
Signed-off-by: Sergey Dyasli
---
tools/misc
I've split the patch into 3 parts. And now I'm using xenhypfs instead of
introducing another platform op. That's my first attempt at xenhypfs and
the patch itself is of RFC quality. Open questions are where to put the
new code and if it's possible to come up with a better hypfs functions.
Sergey
-revision
processor-flags
The most useful bit is cpu microcode revision which will get updated
after late ucode loading.
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/cpu/common.c | 58 +++
1 file changed, 58 insertions(+)
diff --git a/xen/arch/x86/cpu
cpu as "primary" when running on AMD CPUs. Also include
Hygon in the check for future-proofing.
Signed-off-by: Sergey Dyasli
---
v5:
- refactored the code by adding is_cpu_primary() helper
- include Hygon cpus into the check
v4:
- new patch
---
xen/arch/x86/cpu/microcode/c
On Tue, Feb 21, 2023 at 2:03 PM Jan Beulich wrote:
>
> On 15.02.2023 16:38, Sergey Dyasli wrote:
> > --- a/xen/arch/x86/cpu/microcode/core.c
> > +++ b/xen/arch/x86/cpu/microcode/core.c
> > @@ -398,10 +398,16 @@ static int cf_check microcode_nmi_callback(
> >
i.e. skip cpu_sibling_mask checks.
Signed-off-by: Sergey Dyasli
---
v4:
- new patch
---
xen/arch/x86/cpu/microcode/core.c | 35 ++-
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/cpu/microcode/core.c
b/xen/arch/x86/cpu/microcode/core.c
index
I've added a second patch to cover late loading as that should also
happen on every cpu, according to AMD.
Sergey Dyasli (2):
x86/ucode/AMD: apply the patch early on every logical thread
x86/ucode/AMD: late load the patch on every logical thread
xen/arch/x86/cpu/microcode/amd.c | 11
for early AMD ucode
loading. Take this opportunity and move opt_ucode_allow_same out of
compare_revisions() to the relevant callers and also modify the warning
message based on it. Intel's side of things is modified for consistency
but provides no functional change.
Signed-off-by: Sergey Dyasli
---
ormed only on the first of SMT/CMT
siblings and only if a newer ucode revision has been provided (unless
allow_same option is specified).
Signed-off-by: Sergey Dyasli
---
v2 --> v3:
- Moved opt_ucode_allow_same out of compare_revisions() and updated
the commit message
- Adjusted the warning messa
On Mon, Jan 16, 2023 at 2:47 PM Jan Beulich wrote:
>
> On 11.01.2023 15:23, Sergey Dyasli wrote:
> > --- a/xen/arch/x86/cpu/microcode/amd.c
> > +++ b/xen/arch/x86/cpu/microcode/amd.c
> > @@ -176,8 +176,13 @@ static enum microcode_match_result compare_revisions(
> &g
0xa00f11)
Current CPU microcode revision is: 0xa0011a8
Signed-off-by: Sergey Dyasli
---
CC: Wei Liu
CC: Anthony PERARD
CC: Juergen Gross
CC: Andrew Cooper
CC: George Dunlap
CC: Jan Beulich
CC: Julien Grall
CC: Stefano Stabellini
CC: "Roger Pau Monné"
---
tools/include
for early AMD ucode
loading. Late loading is still performed only on the first of SMT/CMT
siblings and only if a newer ucode revision has been provided (unless
allow_same option is specified).
Intel's side of things is modified for consistency but provides no
functional change.
Signed-off-by: Ser
On Thu, Jan 5, 2023 at 10:56 PM Andrew Cooper wrote:
> > diff --git a/xen/arch/x86/cpu/microcode/private.h
> > b/xen/arch/x86/cpu/microcode/private.h
> > index 73b095d5bf..c4c6729f56 100644
> > --- a/xen/arch/x86/cpu/microcode/private.h
> > +++ b/xen/arch/x86/cpu/microcode/private.h
> > @@ -7,6
Signed-off-by: Sergey Dyasli
---
CC: Jan Beulich
CC: Andrew Cooper
CC: "Roger Pau Monné"
CC: Wei Liu
---
xen/arch/x86/cpu/microcode/amd.c | 16 +---
xen/arch/x86/cpu/microcode/intel.c | 9 +++--
xen/arch/x86/cpu/microcode/private.h | 1 +
3 files changed,
This is a preparatory step in order to do earlier microcode loading on
the boot CPU when the domain heap has not been initialized yet and
xmalloc still unavailable.
Add make_copy argument which will allow to load microcode directly from
the blob bypassing microcode_cache.
Signed-off-by: Sergey
The second version of patches. Changelog is available in each patch.
Sergey Dyasli (3):
xen/multiboot: add proper struct definitions to typedefs
x86/ucode: allow cpu_request_microcode() to skip memory allocation
x86/ucode: load microcode earlier on boot CPU
xen/arch/x86/cpu/microcode
fuction.
Signed-off-by: Sergey Dyasli
---
v1 --> v2:
- Don't call microcode_grab_module() the second time, use
microcode_scan_module() instead
- Use forward declaration of struct multiboot_info
- Don't use alternative calls
- Rename early_microcode_update_cache() to early_update_ca
This allows to use them for forward declaration in other headers.
Signed-off-by: Sergey Dyasli
---
CC: George Dunlap
CC: Julien Grall
CC: Stefano Stabellini
v1 --> v2:
- New patch
---
xen/include/xen/multiboot.h | 25 +++--
1 file changed, 15 insertions(+), 10 deleti
On Thu, Dec 8, 2022 at 3:34 PM Jan Beulich wrote:
>
> On 08.12.2022 14:59, Andrew Cooper wrote:
> > On 08/12/2022 13:26, Sergey Dyasli wrote:
> >> @@ -240,20 +240,20 @@ static const struct microcode_patch *nmi_patch =
> >> ZERO_BLOCK_PTR;
> >> * pa
microcode_cache.
It needs to find the new virtual address of the ucode blob because it
changes during boot, e.g. from 0x010802fc to 0x83204dac52fc.
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/cpu/microcode/core.c| 61
xen/arch/x86/include/asm/microcode.h
where required.
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/cpu/microcode/amd.c | 17 +++--
xen/arch/x86/cpu/microcode/core.c| 18 +-
xen/arch/x86/cpu/microcode/intel.c | 17 +++--
xen/arch/x86/cpu/microcode/private.h | 18 --
4
its granularity from the single global value.
Take this opportunity to introduce struct sched_gran_name array and
refactor sched_select_granularity().
Signed-off-by: Sergey Dyasli
---
v4:
- use char[8]
v3:
- use const char*
- use sched_gran_name array instead of switch
- updated commit message
v2
On 29/04/2020 09:09, Jürgen Groß wrote:
> On 27.04.20 15:49, Sergey Dyasli wrote:
>> Hi Juergen,
>>
>> When I'm testing vcpu pinning with something like:
>>
>> # xl vcpu-pin 0 0 2
>> # xen-hptool cpu-offline 3
>>
>> (off
Hi Juergen,
When I'm testing vcpu pinning with something like:
# xl vcpu-pin 0 0 2
# xen-hptool cpu-offline 3
(offline / online CPUs {2,3} if the above is successful)
I'm reliably seeing the following crash on the latest staging:
(XEN) Watchdog timer detects that CPU1 is stuck!
its granularity from the single global value.
Take this opportunity to introduce struct sched_gran_name array and
refactor sched_select_granularity().
Signed-off-by: Sergey Dyasli
---
v3:
- use const char*
- use sched_gran_name array instead of switch
- updated commit message
v2:
- print
On 20/04/2020 14:45, Jürgen Groß wrote:
> On 20.04.20 15:06, Sergey Dyasli wrote:
>> Currently it might be not obvious which scheduling mode (e.g. core-
>> scheduling) is being used by the scheduler. Alleviate this by printing
>> additional information about the selected gr
value is being used for each cpupool.
Signed-off-by: Sergey Dyasli
---
v2:
- print information on a separate line
- use per-cpupool granularity
- updated commit message
CC: Juergen Gross
CC: Dario Faggioli
CC: George Dunlap
CC: Jan Beulich
---
xen/common/sched/cpupool.c | 26
On 17/04/2020 08:57, Jürgen Groß wrote:
> On 16.04.20 18:43, Dario Faggioli wrote:
>> On Thu, 2020-04-16 at 09:33 +0100, Sergey Dyasli wrote:
>>> Currently it might be not obvious which scheduling mode is being used
>>> by the scheduler. Alleviate this by printing addit
On 16/04/2020 10:25, Jürgen Groß wrote:
> On 16.04.20 11:20, Sergey Dyasli wrote:
>> On 16/04/2020 09:57, Jürgen Groß wrote:
>>> On 16.04.20 10:33, Sergey Dyasli wrote:
>>>> Currently it might be not obvious which scheduling mode is being used
>>>> by
On 16/04/2020 09:57, Jürgen Groß wrote:
> On 16.04.20 10:33, Sergey Dyasli wrote:
>> Currently it might be not obvious which scheduling mode is being used
>> by the scheduler. Alleviate this by printing additional information
>> about the selected granularity. Messages now loo
-scheduling mode
2. xl debug-keys r
(XEN) [ 45.914314] Scheduler: SMP Credit Scheduler (credit) in 2-way
core-scheduling mode
Signed-off-by: Sergey Dyasli
---
CC: Juergen Gross
CC: Dario Faggioli
CC: George Dunlap
CC: Jan Beulich
---
xen/common/sched/core.c| 10 --
xen/common/sched
(CC Igor)
On 09/04/2020 13:50, Jürgen Groß wrote:
> On 09.04.20 11:41, Sergey Dyasli wrote:
>> In core-scheduling mode, Xen might crash when entering ACPI S5 state.
>> This happens in sched_slave() during is_idle_unit(next) check because
>> next->vcpu_list is stale and po
has been called.
Signed-off-by: Sergey Dyasli
---
CC: Juergen Gross
CC: Dario Faggioli
CC: George Dunlap
CC: Jan Beulich
---
xen/common/sched/core.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 6
Hi Juergen,
I've notived there is no documentation about how vcpu-pin is supposed to work
with core scheduling enabled. I did some experiments and noticed the following
inconsistencies:
1. xl vcpu-pin 5 0 0
Windows 10 (64-bit) (1) 5 00 -b-1644.0 0 / all
On 12/02/2020 12:24, Jürgen Groß wrote:
> On 12.02.20 12:21, Sergey Dyasli wrote:
>> Hi Juergen,
>>
>> Recently our testing has found a host crash which is reproducible.
>> Do you have any idea what might be going on here?
>
> Oh, nice catch!
>
> The problem
On 12/02/2020 09:32, Jan Beulich wrote:
> On 11.02.2020 14:42, Sergey Dyasli wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -228,6 +228,14 @@ choice
>> bool "SILO" if XSM_SILO
>> endchoice
>>
>> +config
Hi Juergen,
Recently our testing has found a host crash which is reproducible.
Do you have any idea what might be going on here?
(XEN) [175654.165126] Assertion 'lock ==
get_sched_res(i->res->master_cpu)->schedule_lock' failed at
...ild/BUILD/xen-4.13.1/xen/include/xen/sched-if.h:269
(XEN)
om guest's DMI tables that otherwise would be shown in tools like
dmidecode.
While at it, add explicit cases for XENVER_[commandline|build_id]
for better code readability. Add a default case with an ASSERT to make
sure that every case is explicitly listed as well.
Signed-off-by: Sergey Dyasli
---
g to allow guests to set up UI / logs
filtering which dependens on the new CONFIG_XSM_DENIED_STRING.
Signed-off-by: Sergey Dyasli
---
v3 --> v4:
- Updated kconfig prompt description
- Added XENVER_denied_string
- Added #ifdef to fix build when CONFIG_XSM is not set
v2 --> v3:
- new patch
Now a proper 2 patches series.
Sergey Dyasli (2):
xsm: add Kconfig option for denied string
xsm: hide detailed Xen version from unprivileged guests
tools/firmware/hvmloader/hvmloader.c | 1 +
tools/firmware/hvmloader/smbios.c| 1 +
tools/firmware/hvmloader/util.c | 11
On 07/02/2020 08:04, Jürgen Groß wrote:
> On 06.02.20 15:02, Sergey Dyasli wrote:
>> On 06/02/2020 11:05, Sergey Dyasli wrote:
>>> On 06/02/2020 09:57, Jürgen Groß wrote:
>>>> On 05.02.20 17:03, Sergey Dyasli wrote:
>>>>> Hello,
>>>>>
On 07/02/2020 14:36, David Miller wrote:
> From: Sergey Dyasli
> Date: Fri, 7 Feb 2020 14:26:52 +
>
>> From: Ross Lagerwall
>>
>> When KASAN (or SLUB_DEBUG) is turned on, there is a higher chance that
>> non-power-of-two allocations are not aligned to t
This series allows to boot and run Xen PV kernels (Dom0 and DomU) with
CONFIG_KASAN=y. It has been used internally for some time now with good
results for finding memory corruption issues in Dom0 kernel.
Only Outline instrumentation is supported at the moment.
Sergey Dyasli (2):
kasan
From: Ross Lagerwall
When KASAN (or SLUB_DEBUG) is turned on, there is a higher chance that
non-power-of-two allocations are not aligned to the next power of 2 of
the size. Therefore, handle grant copies that cross page boundaries.
Signed-off-by: Ross Lagerwall
Signed-off-by: Sergey Dyasli
and KASAN_VMALLOC options currently lead to boot crashes
and hence disabled.
Signed-off-by: Sergey Dyasli
---
v2 --> v3:
- Fix compilation without CONFIG_KASAN
- Dropped _pv prefixes from new functions
- Made xen_kasan_early_init() call kasan_map_early_shadow() directly
- Updated description
From: Ross Lagerwall
Otherwise it produces lots of false positives when a guest starts using
PV I/O devices.
Signed-off-by: Ross Lagerwall
Signed-off-by: Sergey Dyasli
---
v2 --> v3: no changes
v1 --> v2: no changes
RFC --> v1:
- Slightly clarified the commit message
---
drivers/
. Fix this by introducing set_pmd_early_shadow() which calls
pmd_populate_kernel() only once and uses set_pmd() afterwards.
Signed-off-by: Sergey Dyasli
---
v2 --> v3: no changes
v1 --> v2:
- Fix compilation without CONFIG_XEN_PV
- Slightly updated description
RFC --> v1:
- New patc
On 06/02/2020 11:05, Sergey Dyasli wrote:
> On 06/02/2020 09:57, Jürgen Groß wrote:
>> On 05.02.20 17:03, Sergey Dyasli wrote:
>>> Hello,
>>>
>>> I'm currently investigating a Live-Patch application failure in core-
>>> scheduling mode and this is an ex
On 06/02/2020 09:57, Jürgen Groß wrote:
> On 05.02.20 17:03, Sergey Dyasli wrote:
>> Hello,
>>
>> I'm currently investigating a Live-Patch application failure in core-
>> scheduling mode and this is an example of what I usually get:
>> (it's easily reproducibl
Hello,
I'm currently investigating a Live-Patch application failure in core-
scheduling mode and this is an example of what I usually get:
(it's easily reproducible)
(XEN) [ 342.528305] livepatch: lp: CPU8 - IPIing the other 15 CPUs
(XEN) [ 342.558340] livepatch: lp: Timed out on
On 22/01/2020 11:25, Julien Grall wrote:
>
>
> On 22/01/2020 11:19, Sergey Dyasli wrote:
>> On 22/01/2020 10:14, Julien Grall wrote:
>>>
>>>
>>> On 22/01/2020 10:01, Sergey Dyasli wrote:
>>>> On 20/01/2020 10:01, Jan Beulich wrote:
>>&g
On 22/01/2020 10:57, George Dunlap wrote:
> On 1/22/20 10:14 AM, Julien Grall wrote:
>>
>>
>> On 22/01/2020 10:01, Sergey Dyasli wrote:
>>> On 20/01/2020 10:01, Jan Beulich wrote:
>>>> On 17.01.2020 17:44, Sergey Dyasli wrote:
>>>>> v2
On 22/01/2020 10:14, Julien Grall wrote:
>
>
> On 22/01/2020 10:01, Sergey Dyasli wrote:
>> On 20/01/2020 10:01, Jan Beulich wrote:
>>> On 17.01.2020 17:44, Sergey Dyasli wrote:
>>>> v2 --> v3:
>>>> - Remove hvmloader filtering
>>
On 17/01/2020 14:56, Boris Ostrovsky wrote:
>
>
> On 1/17/20 7:58 AM, Sergey Dyasli wrote:
>> --- a/arch/x86/mm/kasan_init_64.c
>> +++ b/arch/x86/mm/kasan_init_64.c
>> @@ -13,6 +13,9 @@
>> #include
>> #include
>> +#include
>> +#includ
On 20/01/2020 08:58, Paul Durrant wrote:
> On Fri, 17 Jan 2020 at 12:59, Sergey Dyasli wrote:
>>
>> From: Ross Lagerwall
>>
>> When KASAN (or SLUB_DEBUG) is turned on, there is a higher chance that
>> non-power-of-two allocations are not aligned to the next pow
On 20/01/2020 10:01, Jan Beulich wrote:
> On 17.01.2020 17:44, Sergey Dyasli wrote:
>> v2 --> v3:
>> - Remove hvmloader filtering
>
> Why? Seeing the prior discussion, how about adding XENVER_denied to
> return the "denied" string, allowing components which
and XENVER_build_id as well
for better code readability.
Signed-off-by: Sergey Dyasli
---
v2 --> v3:
- Remove hvmloader filtering
- Add ASSERT_UNREACHABLE
v1 --> v2:
- Added xsm_filter_denied() to hvmloader instead of modifying xen_deny()
- Made behaviour the same for both Release and Debug
Signed-off-by: Sergey Dyasli
---
v2 --> v3:
- new patch
CC: Andrew Cooper
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Julien Grall
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Wei Liu
CC: Daniel De Graaf
CC: Doug Goldstein
---
xen/common/Kconfig | 8
From: Ross Lagerwall
When KASAN (or SLUB_DEBUG) is turned on, there is a higher chance that
non-power-of-two allocations are not aligned to the next power of 2 of
the size. Therefore, handle grant copies that cross page boundaries.
Signed-off-by: Ross Lagerwall
Signed-off-by: Sergey Dyasli
This series allows to boot and run Xen PV kernels (Dom0 and DomU) with
CONFIG_KASAN=y. It has been used internally for some time now with good
results for finding memory corruption issues in Dom0 kernel.
Only Outline instrumentation is supported at the moment.
Sergey Dyasli (2):
kasan
. Fix this by introducing set_pmd_early_shadow() which calls
pmd_populate_kernel() only once and uses set_pmd() afterwards.
Signed-off-by: Sergey Dyasli
---
v1 --> v2:
- Fix compilation without CONFIG_XEN_PV
- Slightly updated description
RFC --> v1:
- New patch
---
mm/kasan/init.
This enables to use Outline instrumentation for Xen PV kernels.
KASAN_INLINE and KASAN_VMALLOC options currently lead to boot crashes
and hence disabled.
Signed-off-by: Sergey Dyasli
---
v1 --> v2:
- Fix compilation without CONFIG_XEN_PV
- Use macros for KASAN_SHADOW_START
RFC --> v1:
From: Ross Lagerwall
Otherwise it produces lots of false positives when a guest starts using
PV I/O devices.
Signed-off-by: Ross Lagerwall
Signed-off-by: Sergey Dyasli
---
v1 --> v2:
- no changes
RFC --> v1:
- Slightly clarified the commit message
---
drivers/xen/grant-table.c | 5 ++
On 15/01/2020 11:09, Jürgen Groß wrote:
> On 15.01.20 11:54, Sergey Dyasli wrote:
>> Hi Juergen,
>>
>> On 08/01/2020 15:20, Sergey Dyasli wrote:
>>> It is incorrect to call pmd_populate_kernel() multiple times for the
>>> same page table. Xen notice
On 09/01/2020 10:33, Vlastimil Babka wrote:
> On 1/8/20 4:21 PM, Sergey Dyasli wrote:
>> From: Ross Lagerwall
>>
>> When KASAN (or SLUB_DEBUG) is turned on, the normal expectation that
>> allocations are aligned to the next power of 2 of the size does not
>> h
Hi Juergen,
On 08/01/2020 15:20, Sergey Dyasli wrote:
> It is incorrect to call pmd_populate_kernel() multiple times for the
> same page table. Xen notices it during kasan_populate_early_shadow():
>
> (XEN) mm.c:3222:d155v0 mfn 3704b already pinned
>
> This happens for kasa
On 19/12/2019 16:14, Jürgen Groß wrote:
> On 19.12.19 13:45, Sergey Dyasli wrote:
>> Hi Juergen,
>>
>> We recently did another quick test of core scheduling mode, and the following
>> failures were found:
>>
>> 1. live-patch apply failures:
>>
>>
On 13/01/2020 14:40, Andrew Cooper wrote:
> On 13/01/2020 12:51, George Dunlap wrote:
>> So Sergey's second patch:
>> - Still denies XENVER_extraversion at the hypervisor level
>> - Leaves the value returned by the hypervisor as ""
>> - Filters the "" string at the hvmloader level, to prevent
On 10/01/2020 11:02, Andrew Cooper wrote:
> On 10/01/2020 10:37, Sergey Dyasli wrote:
>> Hide the following information that can help identify the running Xen
>> binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset.
>> Add explicit cases f
On 09/01/2020 13:36, Paul Durrant wrote:
> On Wed, 8 Jan 2020 at 15:21, Sergey Dyasli wrote:
>>
>> From: Ross Lagerwall
>>
>> When KASAN (or SLUB_DEBUG) is turned on, the normal expectation that
>> allocations are aligned to the next power of 2 of the size do
On 09/01/2020 23:27, Boris Ostrovsky wrote:
>
>
> On 1/8/20 10:20 AM, Sergey Dyasli wrote:
>> @@ -1943,6 +1973,15 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd,
>> unsigned long max_pfn)
>> if (i && i < pgd_index(__START_KERNEL_map))
On 09/01/2020 09:15, Jürgen Groß wrote:
> On 08.01.20 16:20, Sergey Dyasli wrote:
>> This enables to use Outline instrumentation for Xen PV kernels.
>>
>> KASAN_INLINE and KASAN_VMALLOC options currently lead to boot crashes
>> and hence disabled.
>>
>> Sign
uest's DMI tables that otherwise would be shown in tools like
dmidecode.
Signed-off-by: Sergey Dyasli
---
v1 --> v2:
- Added xsm_filter_denied() to hvmloader instead of modifying xen_deny()
- Made behaviour the same for both Release and Debug builds
- XENVER_capabilities is no longer hided
CC:
This series allows to boot and run Xen PV kernels (Dom0 and DomU) with
CONFIG_KASAN=y. It has been used internally for some time now with good
results for finding memory corruption issues in Dom0 kernel.
Only Outline instrumentation is supported at the moment.
Sergey Dyasli (2):
kasan
From: Ross Lagerwall
Otherwise it produces lots of false positives when a guest starts using
PV I/O devices.
Signed-off-by: Ross Lagerwall
Signed-off-by: Sergey Dyasli
---
RFC --> v1:
- Slightly clarified the commit message
---
drivers/xen/grant-table.c | 5 -
1 file changed
From: Ross Lagerwall
When KASAN (or SLUB_DEBUG) is turned on, the normal expectation that
allocations are aligned to the next power of 2 of the size does not
hold. Therefore, handle grant copies that cross page boundaries.
Signed-off-by: Ross Lagerwall
Signed-off-by: Sergey Dyasli
---
RFC
This enables to use Outline instrumentation for Xen PV kernels.
KASAN_INLINE and KASAN_VMALLOC options currently lead to boot crashes
and hence disabled.
Signed-off-by: Sergey Dyasli
---
RFC --> v1:
- New functions with declarations in xen/xen-ops.h
- Fixed the is
set_pmd_early_shadow() which calls
pmd_populate_kernel() only once and uses set_pmd() afterwards.
Signed-off-by: Sergey Dyasli
---
RFC --> v1:
- New patch
---
mm/kasan/init.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/mm/kasan/init.c b/mm/ka
On 20/12/2019 06:26, Jürgen Groß wrote:
> On 19.12.19 13:45, Sergey Dyasli wrote:
>> Hi Juergen,
>>
>> We recently did another quick test of core scheduling mode, and the following
>> failures were found:
>>
>> 1. live-patch apply failures:
>>
>>
On 06/01/2020 14:40, Jan Beulich wrote:
> On 06.01.2020 15:35, Sergey Dyasli wrote:
>> On 06/01/2020 11:28, George Dunlap wrote:
>>> On 12/19/19 11:15 PM, Andrew Cooper wrote:
>>>> On 19/12/2019 11:35, Jan Beulich wrote:
>>>>>>>>
On 17/12/2019 15:14, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of
>> Sergey Dyasli
>> Sent: 17 December 2019 14:08
>> To: xen-de...@lists.xen.org; kasan-...@googlegroups.com; linux-
>> ker...@vger.kernel.org
>> Cc:
; arch_iommu_hwdom_init852 2-850
> p2m_add_foreign 880 16-864
>
> Signed-off-by: Andrew Cooper
I tested this patch some time ago on a private branch, so
Tested-by: Sergey Dyasli
Thanks,
Sergey
___
On 06/01/2020 11:28, George Dunlap wrote:
> On 12/19/19 11:15 PM, Andrew Cooper wrote:
>> On 19/12/2019 11:35, Jan Beulich wrote:
>> XENVER_changeset
>> XENVER_commandline
>> XENVER_build_id
>>
>> Return a more customer friendly empty string instead of ""
>>
On 17/12/2019 18:06, Boris Ostrovsky wrote:
>
>
>> On Dec 17, 2019, at 9:08 AM, Sergey Dyasli wrote:
>>
>> This series allows to boot and run Xen PV kernels (Dom0 and DomU) with
>> CONFIG_KASAN=y. It has been used internally for some time now with good
>> r
On 18/12/2019 09:24, Jürgen Groß wrote:
> On 17.12.19 15:08, Sergey Dyasli wrote:
>> This enables to use Outline instrumentation for Xen PV kernels.
>>
>> KASAN_INLINE and KASAN_VMALLOC options currently lead to boot crashes
>> and hence disabled.
>>
>> Rough
1 - 100 of 259 matches
Mail list logo
