Alexander Graf writes:
> Correct. With IMA, you even do exactly that: Enforce a signature check
> of the next binary with kexec.
>
> The problem is that you typically want to update the system because
> something is broken; most likely your original environment had a
> security issue
Alexander Graf writes:
> Hey Ashish,
>
> On 09.04.24 22:42, Ashish Kalra wrote:
>> From: Ashish Kalra
>>
>> The patchset adds bits and pieces to get kexec (and crashkernel) work on
>> SNP guest.
>
>
> With this patch set (and similar for the TDX one), you enable the
> typical kdump case, which
Sean Christopherson writes:
> On Fri, Oct 20, 2023, Vitaly Kuznetsov wrote:
>> > ---
>> > arch/x86/kernel/kvmclock.c | 12
>> > 1 file changed, 8 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/arch/x86/kernel/kvmclock.c b/ar
. Shutemov
> Fixes: c02027b5742b ("x86/kvm: Disable kvmclock on all CPUs on shutdown")
> Cc: Paolo Bonzini
> Cc: Wanpeng Li
> Cc: Vitaly Kuznetsov
> Cc: Sean Christopherson
> ---
> arch/x86/kernel/kvmclock.c | 12
> 1 file changed, 8 insertions(+), 4
Baoquan He writes:
>
> While I would suggest adding kexec@lists.infradead.org when code changes
> are related to kexec/kdump since we usually watch this mailing list.
> LKML contains too many mails, we may miss this kind of change, have to
> debug and test again.
>
Definitely makes sense and
Baoquan He writes:
> On 04/07/20 at 02:04pm, Vitaly Kuznetsov wrote:
>> Baoquan He writes:
>>
>> >
>> > The trace is here.
>> >
>> > [ 132.480817] RIP: 0010:crash_vmclear_local_loaded_vmcss+0x57/0xd0
>> > [kvm_intel]
&g
Baoquan He writes:
>
> The trace is here.
>
> [ 132.480817] RIP: 0010:crash_vmclear_local_loaded_vmcss+0x57/0xd0
> [kvm_intel]
This is a known bug,
https://lore.kernel.org/kvm/20200401081348.1345307-1-vkuzn...@redhat.com/
--
Vitaly
___
kexec
Pratyush Anand <pan...@redhat.com> writes:
> On 21/06/2016:10:05:42 AM, Vitaly Kuznetsov wrote:
>> Pratyush Anand <pan...@redhat.com> writes:
>>
>> > On 21/06/2016:05:43:29 AM, Atsushi Kumagai wrote:
>> >> Hello Vitaly,
>> >>
&
_refcount") and this
>> >broke makedumpfile. The reason for making the change was to find all users
>> >accessing it directly and not through the recommended API. I tried
>> >suggesting to revert the change but failed, I see no other choice than to
>> >start supportin
suggesting to revert the change but failed, I see no other choice than to
start supporting both _count and _refcount in makedumpfile.
Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
---
Changes since 'v1':
- Make '_refcount' the default [Atsushi Kumagai]
---
mak
making the change was to find all users
>>accessing it directly and not through the recommended API. I tried
>>suggesting to revert the change but failed, I see no other choice than to
>>start supporting both _count and _refcount in makedumpfile.
>>
>>Signed-off
son for making the change was to find all users
>> accessing it directly and not through the recommended API. I tried
>> suggesting to revert the change but failed, I see no other choice than to
>> start supporting both _count and _refcount in makedumpfile.
>>
>> Signe
I. I tried
suggesting to revert the change but failed, I see no other choice than to
start supporting both _count and _refcount in makedumpfile.
Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
---
- 'crash' tool is now broken as well.
---
makedumpfile.c | 18 +-
makedumpfile.h
Michal Hocko <mho...@kernel.org> writes:
> On Thu 16-06-16 12:30:16, Vitaly Kuznetsov wrote:
>> Christoph Hellwig <h...@infradead.org> writes:
>>
>> > On Thu, Jun 16, 2016 at 11:22:46AM +0200, Vitaly Kuznetsov wrote:
>> >> _count -> _refcount
Christoph Hellwig <h...@infradead.org> writes:
> On Thu, Jun 16, 2016 at 11:22:46AM +0200, Vitaly Kuznetsov wrote:
>> _count -> _refcount rename in commit 0139aa7b7fa12 ("mm: rename _count,
>> field of the struct page, to _refcount") broke kdump.
tool I'm not sure about
other tools which might be doing the same.
I suggest we remember the "we don't break userspace" rule and revert for
4.7 while it's not too late.
This is a partial revert, useful hunks in drivers which do
page_ref_{sub,add,inc} instead of open coded atomic_* operat
If some piece of code wants to check kexec_in_progress it has to be put
in #ifdef CONFIG_KEXEC block to not break the build in !CONFIG_KEXEC
case. Overcome this limitation by defining kexec_in_progress to false.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
include/linux/kexec.h | 1
kernel doesn't know about this memory and there is no way to
ask the host to bring all the memory back on cleanup (or at least I'm not
aware of such a way). Kexec with hotplugged memory leads to reboot (not
exactly sure why).
Vitaly Kuznetsov (5):
Drivers: hv: vmbus: remove hv_synic_free_cpu() call
consists of cleaning up clockevents, synic MSRs,
guest os id MSR, and hypercall MSR.
Kdump doesn't require all this stuff as it lives in a separate memory
space.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
arch/x86/include/asm/mshyperv.h | 2 ++
arch/x86/kernel/cpu/mshyperv.c | 24
of the do_hypercall() function. Unfortunately we have to write the
!hypercall_page check twice to not mix declarations and code.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
drivers/hv/hv.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/hv/hv.c b/drivers/hv
to perform some mandatory minimalistic
cleanup before we start new kernel.
Reported-by: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
arch/x86/include/asm/mshyperv.h | 2 ++
arch/x86/kernel/cpu/mshyperv.c | 22 ++
drivers/hv
We already have hv_synic_free() which frees all per-cpu pages for all
CPUs, let's remove the hv_synic_free_cpu() call from hv_synic_cleanup()
so it will be possible to do separate cleanup (writing to MSRs) and final
freeing. This is going to be used to assist kexec.
Signed-off-by: Vitaly
22 matches
Mail list logo
