On 12/10/18 14:40, Jan Beulich wrote:
On 09.10.18 at 17:21, wrote:
>> --- a/xen/common/page_alloc.c
>> +++ b/xen/common/page_alloc.c
>> @@ -161,8 +161,42 @@ string_param("badpage", opt_badpage);
>> /*
>> * no-bootscrub -> Free pages are not zeroed during boot.
>> */
>> -static bool_t opt
nable NMIs during cpu_init().
Signed-off-by: Sergey Dyasli
---
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
---
xen/arch/x86/cpu/common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 057859ab14..09fbd98764 100644
--- a/xen/ar
nable NMIs during cpu_init() and
during __start_xen() for BSP.
Signed-off-by: Sergey Dyasli
---
v2:
- Added enable_nmis() to __start_xen() for BSP
- Added comments as per Andrew's suggestion
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
---
xen/arch/x86/cpu/common.c | 3 +++
xen/a
user_regs *regs,
> case EXIT_REASON_VMXOFF:
> case EXIT_REASON_VMXON:
> case EXIT_REASON_INVEPT:
> +case EXIT_REASON_INVVPID:
> case EXIT_REASON_XSETBV:
> /* inject to L1 */
> nvcpu->nv_vmexit_pending = 1;
Reviewed-by: Sergey Dyasli
On 25/10/2018 16:39, Andrew Cooper wrote:
> This is very dangerous from a security point of view, because a missing entry
> will cause L2's action to be interpreted as L1's action.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Sergey Dyasli
> CC: Jan Beulich
&g
to L1
> guests.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Sergey Dyasli
--
Thanks,
Sergey
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
> Signed-off-by: Andrew Cooper
Reviewed-by: Sergey Dyasli
--
Thanks,
Sergey
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 26/10/2018 10:10, Andrew Cooper wrote:
> On 26/10/2018 10:05, Sergey Dyasli wrote:
>>
>> On 25/10/2018 16:39, Andrew Cooper wrote:
>>> This is very dangerous from a security point of view, because a missing
>>> entry
>>> will cause L2's action t
Raw policy contains the actual values from H/W MSRs. Add PLATFORM_INFO
msr to the policy during probe_cpuid_faulting().
Host policy might have certain features disabled if Xen decides not
to use them. For now, make Host policy equal to Raw policy.
Signed-off-by: Sergey Dyasli
---
v1: Decided to
On Thu, 2018-02-08 at 11:21 +, Roger Pau Monné wrote:
> On Thu, Feb 08, 2018 at 10:23:21AM +0000, Sergey Dyasli wrote:
> > +static void __init calculate_host_policy(void)
> > +{
> > +struct msr_domain_policy *dp = &host_msr_domain_policy;
> > +
>
On Thu, 2018-02-15 at 06:33 -0700, Jan Beulich wrote:
> > > > On 08.02.18 at 11:23, wrote:
> >
> > --- a/xen/arch/x86/cpu/common.c
> > +++ b/xen/arch/x86/cpu/common.c
> > @@ -118,9 +118,18 @@ void (* __read_mostly ctxt_switch_masking)(const
> > struct vcpu *next);
> >
> > bool __init probe_cp
On Fri, 2018-02-16 at 04:06 -0700, Jan Beulich wrote:
> > > > On 16.02.18 at 11:33, wrote:
> >
> > On Thu, 2018-02-15 at 06:33 -0700, Jan Beulich wrote:
> > > > > > On 08.02.18 at 11:23, wrote:
> > > >
> > > > uint64_t val;
> > > > + int rc;
> > > >
> > > > - if (rdmsr_saf
On Fri, 2018-02-16 at 11:38 +, Andrew Cooper wrote:
> On 16/02/18 11:31, Sergey Dyasli wrote:
> > On Fri, 2018-02-16 at 04:06 -0700, Jan Beulich wrote:
> > > > > > On 16.02.18 at 11:33, wrote:
> > > >
> > > > On Thu, 2018-02-15 at 06:33 -0
X86_FEATURE_CPUID_FAULTING.
Finally, derive HVM/PV max domain policies from the Host policy.
Signed-off-by: Sergey Dyasli
---
v2:
- Moved *dp into a narrower scope in probe_cpuid_faulting()
- Changes to how Host/pv/hvm domain policies are calculated
---
xen/arch/x86/cpu/common.c | 12 +++-
xen
eamed
separately
- Combined the next 2 patches into 1
Sergey Dyasli (5):
x86/msr: add VMX MSRs definitions and populate Raw domain policy
x86/msr: add VMX MSRs into HVM_max domain policy
x86/cpuid: update signature of hvm_cr4_guest_valid_bits()
x86/msr: update domain policy on CPUID policy
ed by guest_rd/wrmsr().
Signed-off-by: Sergey Dyasli
---
v4 --> v5:
- Macros are removed and now supported bitmask is used to derive policy
- Added vmx_clear_policy() helper
---
xen/arch/x86/msr.c | 134 +
1 file changed, 134 insertions(+)
diff
olicy() which changes availability of
VMX MSRs based on domain's nested virt settings. If it's enabled, then
the domain receives a copy of HVM_max vmx policy with allowed CR4 bits
adjusted by CPUID policy.
Signed-off-by: Sergey Dyasli
---
v4 --> v5:
- Removed _domain from func
With the new cpuid infrastructure there is a domain-wide struct cpuid
policy and there is no need to pass a separate struct vcpu * into
hvm_cr4_guest_valid_bits() anymore. Make the function accept struct
domain * instead and update callers.
Signed-off-by: Sergey Dyasli
---
v4 --> v5: rebased
X MSRs.
Signed-off-by: Sergey Dyasli
---
v4 --> v5:
- New msr availability helpers are used
---
xen/arch/x86/hvm/vmx/vmx.c | 6 --
xen/arch/x86/hvm/vmx/vvmx.c| 178 -
xen/arch/x86/msr.c | 35
xen/include/asm-x86/hv
mx_true_ctls blocks.
Add calculate_raw_vmx_policy() which fills Raw policy with H/W values
of VMX MSRs. Host policy will contain a copy of these values (for now).
Signed-off-by: Sergey Dyasli
---
v4 --> v5:
- Clarified the reason for splitting MSRs into 5 blocks
- Added raw field into cr0/4_bits
- Moved cr0/4_bits
On Thu, 2018-03-01 at 16:19 +, Roger Pau Monne wrote:
> Commit 406817 doesn't update nested VMX code in order to take into
> account L1 CR4 host mask when nested guest (L2) writes to CR4, and
> thus the mask written to CR4_GUEST_HOST_MASK is likely not as
> restrictive as it should be.
>
> Als
On 26/10/2018 12:09, Andrew Cooper wrote:
> Ok - that patch is now as follows:
>
> x86/vvmx: Let L1 handle all the unconditional vmexit instructions
>
> Signed-off-by: Andrew Cooper
> ...
> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
> index aa202e0..7051eb3 100644
> -
On 30/10/2018 08:06, Tian, Kevin wrote:
>> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
>> Sent: Friday, October 12, 2018 11:28 PM
>>
>> The size of Xen's virtual vmcs region is 4096 bytes. Correctly report
>> it to the guest in case when VMCS sh
On 30/10/2018 07:41, Tian, Kevin wrote:
>> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
>> Sent: Friday, October 12, 2018 11:28 PM
>>
>> As a convenient helper function and refactor the code to use it.
>>
>> No functional change.
>>
>> Sign
On 01/11/2018 02:22, Tian, Kevin wrote:
>> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
>> Sent: Tuesday, October 30, 2018 8:41 PM
>>
>> On 30/10/2018 07:41, Tian, Kevin wrote:
>>>> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
>>
On 01/11/2018 02:29, Tian, Kevin wrote:
>> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
>> Sent: Tuesday, October 30, 2018 8:36 PM
>>
>> On 30/10/2018 08:06, Tian, Kevin wrote:
>>>> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
>>
-off-by: Sergey Dyasli
---
v2:
- Removal of enum vmx_ops_result and refactoring
---
xen/arch/x86/hvm/vmx/vvmx.c| 52 +-
xen/include/asm-x86/hvm/vmx/vmcs.h | 1 +
2 files changed, 30 insertions(+), 23 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen
And use it in nvmx_handle_invept() and nvmx_handle_invvpid().
Signed-off-by: Sergey Dyasli
---
v2:
- new patch
---
xen/arch/x86/hvm/vmx/vvmx.c| 4 ++--
xen/include/asm-x86/hvm/vmx/vmcs.h | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b
reasons, Xen maps bitmaps only:
1. During the first nested vmentry
2. After L1 has changed an appropriate vmcs field
3. After nvmx_purge_vvmcs() was previously called
Signed-off-by: Sergey Dyasli
---
v2:
- slight commit message change
---
xen/arch/x86/hvm/vmx/vvmx.c | 105
Calling vmfail_valid() is correct only if vvmcx is valid. Modify
functions to use vmfail() instead which performs the necessary check.
While at it, add ASSERTs into vmfail_valid/invalid() to quickly catch
an incorrect usage in the future.
Signed-off-by: Sergey Dyasli
---
v2:
- Added ASSERTs
And call it during vmx_vcpu_initialise(). This allows to safely use
vvmx functions that rely on the values inside struct nestedvmx and
struct nestedvcpu, independently of the nested virtualisation
(HVM_PARAM_NESTEDHVM) status of a domain.
Signed-off-by: Sergey Dyasli
---
v2:
- new patch
---
xen
As a convenient helper function and refactor the code to use it.
No functional change.
Signed-off-by: Sergey Dyasli
---
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
CC: Brian Woods
v2:
- Use the new helper in nestedsvm.c
---
xen/arch/x86/hvm/svm/nestedsvm.c| 2 +-
xen/arch/x86/hvm
These were found by running nested VMX tests from kvm-unit-tests.
Sergey Dyasli (8):
x86/vvmx: introduce nvmx_vcpu_preinit()
x86/nestedhvm: introduce vvmcx_valid()
x86/vvmx: add VMX_INSN_INVEPT_INVVPID_INVALID_OP errno
x86/vvmx: correct vmfail() usage for vmptrld and vmclear
x86/vvmx
And make nvmx_handle_vmptrld() return the new errno in case the provided
address is the same as vmxon region address.
While at it, correct the return value for not-4KB-aligned case.
Signed-off-by: Sergey Dyasli
Acked-by: Kevin Tian
---
v2:
- Added Acked-by
---
xen/arch/x86/hvm/vmx/vvmx.c
The size of Xen's virtual vmcs region is 4096 bytes (see comment about
Virtual VMCS layout in include/asm-x86/hvm/vmx/vvmx.h). Correctly report
it to the guest in case when VMCS shadowing is not available instead of
providing H/W value (which is usually smaller).
Signed-off-by: Sergey D
by doing
eager scrubbing during allocation (unless MEMF_no_scrub was provided).
Use the new 'idle' option as the default one.
Signed-off-by: Sergey Dyasli
Reviewed-by: Jan Beulich
---
v2 --> v3:
- Removed "= 0" from enum bootscrub_mode
- Removed num_online_nodes() from pr
On 07/11/2018 12:17, Wei Liu wrote:
> On Wed, Nov 07, 2018 at 11:11:49AM +0000, Sergey Dyasli wrote:
>> Scrubbing RAM during boot may take a long time on machines with lots
>> of RAM. Add 'idle' option to bootscrub which marks all pages dirty
>> initially so they
On 07/11/2018 18:20, Andrew Cooper wrote:
> On 09/10/18 16:21, Sergey Dyasli wrote:
>> Scrubbing RAM during boot may take a long time on machines with lots
>> of RAM. Add 'idle' option to bootscrub which marks all pages dirty
>> initially so they will eventually be
On 07/11/2018 13:28, Wei Liu wrote:
> On Tue, Nov 06, 2018 at 12:07:58PM +0000, Sergey Dyasli wrote:
>> The size of Xen's virtual vmcs region is 4096 bytes (see comment about
>> Virtual VMCS layout in include/asm-x86/hvm/vmx/vvmx.h). Correctly report
>> it to the guest i
(CCing Roger)
On 08/11/2018 11:07, Andrew Cooper wrote:
> On 08/11/18 10:31, Jan Beulich wrote:
>>>>> On 07.11.18 at 19:20, wrote:
>>> On 09/10/18 16:21, Sergey Dyasli wrote:
>>>> Scrubbing RAM during boot may take a long time on machines with lots
>
On 08/11/2018 15:18, Roger Pau Monné wrote:
> On Thu, Nov 08, 2018 at 02:48:40PM +0000, Sergey Dyasli wrote:
>> (CCing Roger)
>>
>> On 08/11/2018 11:07, Andrew Cooper wrote:
>>> On 08/11/18 10:31, Jan Beulich wrote:
>>>>>>> On 07.11.18 at 19:20,
Calling vmfail_valid() is correct only if vvmcx is valid. Modify
functions to use vmfail() instead which performs the necessary check.
While at it, add ASSERTs into vmfail_valid/invalid() to quickly catch
an incorrect usage in the future.
Signed-off-by: Sergey Dyasli
Acked-by: Kevin Tian
These were found by running nested VMX tests from kvm-unit-tests.
v3:
- Removed 1/8 "x86/vvmx: introduce nvmx_vcpu_preinit()"
- Added 1/8 "x86/nestedhvm: init nv_vvmcxaddr in hvm_vcpu_initialise()"
- Added R-by and Acked-by to other patches
Sergey Dyasli (8):
x86/nestedhv
The size of Xen's virtual vmcs region is 4096 bytes (see comment about
Virtual VMCS layout in include/asm-x86/hvm/vmx/vvmx.h). Correctly report
it to the guest in case when VMCS shadowing is not available instead of
providing H/W value (which is usually smaller).
Signed-off-by: Sergey D
This allows to safely use nestedhvm functions that rely on the values
inside struct nestedvcpu independently of the nested virtualisation
(HVM_PARAM_NESTEDHVM) status of a domain.
Signed-off-by: Sergey Dyasli
---
v3:
- new patch
---
xen/arch/x86/hvm/hvm.c | 2 ++
1 file changed, 2 insertions
As a convenient helper function and refactor the code to use it.
No functional change.
Signed-off-by: Sergey Dyasli
Reviewed-by: Boris Ostrovsky
Reviewed-by: Wei Liu
Reviewed-by: Kevin Tian
---
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
CC: Brian Woods
v3:
- Added R-by
v2:
- Use the
And use it in nvmx_handle_invept() and nvmx_handle_invvpid().
Signed-off-by: Sergey Dyasli
Acked-by: Kevin Tian
---
v3:
- Added Acked-by
v2:
- new patch
---
xen/arch/x86/hvm/vmx/vvmx.c| 4 ++--
xen/include/asm-x86/hvm/vmx/vmcs.h | 1 +
2 files changed, 3 insertions(+), 2 deletions
And make nvmx_handle_vmptrld() return the new errno in case the provided
address is the same as vmxon region address.
While at it, correct the return value for not-4KB-aligned case.
Signed-off-by: Sergey Dyasli
Acked-by: Kevin Tian
---
v3:
- no changes
v2:
- Added Acked-by
---
xen/arch/x86
reasons, Xen maps bitmaps only:
1. During the first nested vmentry
2. After L1 has changed an appropriate vmcs field
3. After nvmx_purge_vvmcs() was previously called
Signed-off-by: Sergey Dyasli
Acked-by: Kevin Tian
---
v3:
- Added Acked-by
v2:
- slight commit message change
-off-by: Sergey Dyasli
Acked-by: Kevin Tian
---
v3:
- Added Acked-by
v2:
- Removal of enum vmx_ops_result and refactoring
---
xen/arch/x86/hvm/vmx/vvmx.c| 52 +-
xen/include/asm-x86/hvm/vmx/vmcs.h | 1 +
2 files changed, 30 insertions(+), 23 deletions(-)
diff
Signed-off-by: Sergey Dyasli
---
CC: Jan Beulich
CC: Wei Liu
---
xen/common/page_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 88d1637247..08ee8cfbb9 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common
failValid. So I think the description must be
changed.
--
Sergey
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Sergey Dyasli
> CC: Jun Nakajima
> CC: Kevin Tian
> ---
> xen/arch/x86/hvm/vmx/vvmx.c | 1 -
> 1
;t call vmsucceed() at the end of virtual_vmexit()
Reviewed-by: Sergey Dyasli
--
Thanks,
Sergey
> xen/arch/x86/hvm/vmx/vvmx.c | 22 +++---
> 1 file changed, 7 insertions(+), 15 deletions(-)
>
___
Xen-devel mailing list
X
process since there is little point
in scrubbing memory for Dom0 RAM.
Signed-off-by: Sergey Dyasli
---
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC: "Roger Pau Monné"
---
xen/arch/x86/hvm/dom0_build.c | 2 +-
xen/arch/x86/pv/dom0_build.c | 5 +++--
2 files changed, 4 insert
On 20/11/2018 17:16, Jan Beulich wrote:
On 20.11.18 at 18:00, wrote:
>> Now that idle scrub is the default option, all memory is marked as dirty
>> and alloc_domheap_pages() will do eager scrubbing by default. This can
>> lead to longer Dom0 construction and potentially to a watchdog timeout,
5 files changed, 47 insertions(+), 6 deletions(-)
Reviewed-by: Sergey Dyasli
Thanks
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
process since there is little point
in scrubbing memory for Dom0.
Signed-off-by: Sergey Dyasli
---
v2:
- use MEMF_no_scrub in more calls
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC: "Roger Pau Monné"
---
xen/arch/x86/hvm/dom0_build.c | 2 +-
xen/arch/x86/pv/dom0_bui
//bugs.llvm.org/show_bug.cgi?id=39707
>
> I haven't been able to find any other instances of such conditional
> expression that uses system_state together with an init variable or
> function.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Sergey
On Tue, 2018-01-09 at 02:13 -0700, Jan Beulich wrote:
> > > > On 04.01.18 at 14:06, wrote:
> > +size_t consoled_guest_rx(void)
> > +{
> > +size_t recv = 0, idx = 0;
> > +XENCONS_RING_IDX cons, prod;
> > +
> > +if ( !cons_ring )
> > +return 0;
> > +
> > +spin_lock(&rx_lock);
On Tue, 2018-01-09 at 09:28 -0700, Jan Beulich wrote:
> > > > On 09.01.18 at 16:43, wrote:
> >
> > On Tue, 2018-01-09 at 02:13 -0700, Jan Beulich wrote:
> > > > > > On 04.01.18 at 14:06, wrote:
> > > >
> > > > +size_t consoled_guest_rx(void)
> > > > +{
> > > > +size_t recv = 0, idx = 0;
> >
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
(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
-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
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
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 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
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 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
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
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!
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
>>
>>
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 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
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,
>>>>>
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
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) [175
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
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
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
Win
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 ""
>> whic
; 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 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:
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 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:
>>
>>
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 issue w
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
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
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, 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
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
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
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 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 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 for X
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 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:
>>
>>
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 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
101 - 200 of 265 matches
Mail list logo
