On 2024/12/13 7:08, David Woodhouse wrote:
From: David Woodhouse
The kernel switches to a new set of page tables during kexec. The global
mappings (_PAGE_GLOBAL==1) can remain in the TLB after this switch. This
is generally not a problem because the new page tables use a different
portion of
On 2024/12/13 14:45, Ning, Hongyu wrote:
On 2024/12/12 18:13, David Woodhouse wrote:
On Thu, 2024-12-12 at 11:03 +0800, Ning, Hongyu wrote:
Hi David,
I've hit some kdump/kexec regression issue for guest kernel in KVM/QEMU
based VM and reported in https://bugzilla.kernel.org/show_bug.cgi?
On 13 December 2024 06:45:18 GMT, "Ning, Hongyu"
wrote:
>
>
>On 2024/12/12 18:13, David Woodhouse wrote:
>> On Thu, 2024-12-12 at 11:03 +0800, Ning, Hongyu wrote:
>>>
>>> Hi David,
>>>
>>> I've hit some kdump/kexec regression issue for guest kernel in KVM/QEMU
>>> based VM and reported in https
On 2024/12/13 4:11, David Woodhouse wrote:
From: David Woodhouse
The virtual mapping of the control page may have been _PAGE_GLOBAL and
thus its PTE might not have been flushed on the %cr3 switch and it might
effectively still be read-only. Move the writes to it down into the
identity_mapped
On 2024/12/12 18:13, David Woodhouse wrote:
On Thu, 2024-12-12 at 11:03 +0800, Ning, Hongyu wrote:
Hi David,
I've hit some kdump/kexec regression issue for guest kernel in KVM/QEMU
based VM and reported in https://bugzilla.kernel.org/show_bug.cgi?id=219592.
based on further git bisect, it
On Thu, Dec 12 2024 at 19:19, David Woodhouse wrote:
> On Thu, 2024-12-12 at 19:04 +0100, Thomas Gleixner wrote:
> Build current master (231825b2e1ff here). The config I'm using is at
> http://david.woodhou.se/config-x86-kjump-irqs although I don't think
> there's anything special other than CONFIG
From: David Woodhouse
The kernel switches to a new set of page tables during kexec. The global
mappings (_PAGE_GLOBAL==1) can remain in the TLB after this switch. This
is generally not a problem because the new page tables use a different
portion of the virtual address space than the normal kerne
On Thu, Dec 12, 2024 at 11:56 AM Daniel P. Smith
wrote:
>
> Hey Luto!
>
> Let me try to address your concerns below.
>
> On 11/18/24 15:02, Andy Lutomirski wrote:
> > On Mon, Nov 18, 2024 at 11:12 AM James Bottomley
> > wrote:
> >>
> >> On Mon, 2024-11-18 at 10:43 -0800, Andy Lutomirski wrote:
>
On 12 December 2024 21:43:57 GMT, Dave Hansen wrote:
>On 12/12/24 13:32, David Woodhouse wrote:
>> On 12 December 2024 21:18:10 GMT, Dave Hansen wrote:
>>> On 12/12/24 12:11, David Woodhouse wrote:
From: David Woodhouse
The virtual mapping of the control page may have been _PAGE_G
On 12/12/24 13:32, David Woodhouse wrote:
> On 12 December 2024 21:18:10 GMT, Dave Hansen wrote:
>> On 12/12/24 12:11, David Woodhouse wrote:
>>> From: David Woodhouse
>>>
>>> The virtual mapping of the control page may have been _PAGE_GLOBAL and
>>> thus its PTE might not have been flushed on th
On 12 December 2024 21:18:10 GMT, Dave Hansen wrote:
>On 12/12/24 12:11, David Woodhouse wrote:
>> From: David Woodhouse
>>
>> The virtual mapping of the control page may have been _PAGE_GLOBAL and
>> thus its PTE might not have been flushed on the %cr3 switch and it might
>> effectively still b
zstd is becoming a popular zlib replacement because it both tends to
get a better compression ratio as well performs considerably
better. As such, zstd is now one of the options that can be used to
compress the Linux kernel.
Lets enable it by using a system provided shared library, creating the
re
On 12/12/24 12:11, David Woodhouse wrote:
> From: David Woodhouse
>
> The virtual mapping of the control page may have been _PAGE_GLOBAL and
> thus its PTE might not have been flushed on the %cr3 switch and it might
> effectively still be read-only. Move the writes to it down into the
> identity_
The kexec decompression routines support detecting zlib or lzma
compressed images. Lets add the ability to automatically decompress
zstd ones as well. The zstd attempt is made after gzip because its
fairly inexpensive relative lzma, and gzip remains a popular option.
Signed-off-by: Jeremy Linton
This set adds zstd compressed image support to the image decompression
logic. This enables kexec with PE-ZBOOT images compressed with
zstd. zstd is one of those algorithms which is better in most regards
than zlib because it both compresses data better an is at the same
time faster. This is in larg
On Thu, Dec 12, 2024 at 08:11:19PM +, David Woodhouse wrote:
> From: David Woodhouse
>
> The virtual mapping of the control page may have been _PAGE_GLOBAL and
> thus its PTE might not have been flushed on the %cr3 switch and it might
> effectively still be read-only. Move the writes to it do
From: David Woodhouse
The virtual mapping of the control page may have been _PAGE_GLOBAL and
thus its PTE might not have been flushed on the %cr3 switch and it might
effectively still be read-only. Move the writes to it down into the
identity_mapped() function where the same %rip-relative address
Hey Luto!
Let me try to address your concerns below.
On 11/18/24 15:02, Andy Lutomirski wrote:
On Mon, Nov 18, 2024 at 11:12 AM James Bottomley
wrote:
On Mon, 2024-11-18 at 10:43 -0800, Andy Lutomirski wrote:
Linux should not use TPM2_PCR_Extend *at all*. Instead, Linux should
exclusively
On Thu, 2024-12-12 at 10:42 -0700, Nathan Chancellor wrote:
>
> > What CPU is this? Shouldn't loading %cr3 have caused the existing TLB
> > entry to be flushed?
>
> The machine I have mainly been reproducing and testing this issue on is
> an Intel Xeon Gold 6314U but I initially noticed this pro
On Thu, 2024-12-12 at 19:04 +0100, Thomas Gleixner wrote:
>
> I tried to reproduce, but failed. Do you have a simple reproducer
> recipe?
Build current master (231825b2e1ff here). The config I'm using is at
http://david.woodhou.se/config-x86-kjump-irqs although I don't think
there's anything spec
On Thu, Dec 12 2024 at 13:46, David Woodhouse wrote:
> On Thu, 2024-12-12 at 14:34 +0100, Thomas Gleixner wrote:
>>
>> David, can you retest with the debug patch below? That should pin-point
>> the real culprit.
>
> B[1.545489] [ cut here ]
> [1.546338] DEBUG_LOCKS_
On Thu, Dec 12, 2024 at 05:00:00PM +, David Woodhouse wrote:
> >
> > Here is the output that I see with that patch applied when rebooting via
> > 'systemctl kexec':
> >
> > RAX=00010c070001 RBX= RCX=
> > RDX=00047fffb1a0
> > RSI=00011c444000 RDI=00
>
> Here is the output that I see with that patch applied when rebooting via
> 'systemctl kexec':
>
> RAX=00010c070001 RBX= RCX=
> RDX=00047fffb1a0
> RSI=00011c444000 RDI=00011c450002 RBP=ff1cd0424d6e8c00
> RSP=ff4178d5c5aebc60
> R8 =0
On Thu, 2024-12-12 at 14:34 +0100, Thomas Gleixner wrote:
>
> David, can you retest with the debug patch below? That should pin-point
> the real culprit.
B[1.545489] [ cut here ]
[1.546338] DEBUG_LOCKS_WARN_ON(suspend_syscore_active)
[1.546375] WARNING: CPU: 0
CC+ printk folks
On Thu, Dec 12 2024 at 11:07, David Woodhouse wrote:
> On Wed, 2024-12-11 at 07:42 -0500, Stefan Hajnoczi wrote:
>> On Tue, Dec 10, 2024 at 09:56:43AM +0800, Jason Wang wrote:
>> > Adding more virtio-blk people here.
>>
>> Please try Ming Lei's recent fix in Jens' tree:
>>
>>
On Thu, Dec 12, 2024 at 3:01 AM Stefan Hajnoczi wrote:
>
> On Tue, Dec 10, 2024 at 09:56:43AM +0800, Jason Wang wrote:
> > Adding more virtio-blk people here.
>
> Please try Ming Lei's recent fix in Jens' tree:
>
> virtio-blk: don't keep queue frozen during system suspend
> commit: 7678abee086
On Wed, 2024-12-11 at 07:42 -0500, Stefan Hajnoczi wrote:
> On Tue, Dec 10, 2024 at 09:56:43AM +0800, Jason Wang wrote:
> > Adding more virtio-blk people here.
>
> Please try Ming Lei's recent fix in Jens' tree:
>
> virtio-blk: don't keep queue frozen during system suspend
> commit: 7678abee0
On Wed, 2024-12-11 at 18:44 -0700, Nathan Chancellor wrote:
> Hi David,
>
> On Thu, Dec 05, 2024 at 03:05:19PM +, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > All writes to the page now happen before it gets marked as executable
> > (or after it's already switched to the identmap
On Thu, 2024-12-12 at 11:03 +0800, Ning, Hongyu wrote:
>
> Hi David,
>
> I've hit some kdump/kexec regression issue for guest kernel in KVM/QEMU
> based VM and reported in https://bugzilla.kernel.org/show_bug.cgi?id=219592.
>
> based on further git bisect, it seems to be related with this commi
On Thu, 2024-12-12 at 11:02 +0800, Baoquan He wrote:
> Hi David,
>
> On 12/09/24 at 02:07pm, David Woodhouse wrote:
> > In https://git.kernel.org/torvalds/c/07fa619f2a40c there is a test
> > program which uses kexec to invoke a 4-instruction 'executable' which
> > merely writes a byte to a serial
30 matches
Mail list logo
