On 6/5/24 05:43, Kirill A. Shutemov wrote:
> Okay fair enough. Check out the fixup below. Is it what you mean?
Yes. Much better.
> One other thing I realized is that these callback are dead code if kernel
> compiled without kexec support. Do we want them to be wrapped with
> #ifdef
On 5/28/24 02:55, Kirill A. Shutemov wrote:
> +/* Stop new private<->shared conversions */
> +static void tdx_kexec_begin(bool crash)
> +{
> + /*
> + * Crash kernel reaches here with interrupts disabled: can't wait for
> + * conversions to finish.
> + *
> + * If race
On 5/28/24 02:55, Kirill A. Shutemov wrote:
> + x86_platform.guest.enc_kexec_begin(true);
> + x86_platform.guest.enc_kexec_finish();
I really despise the random, unlabeled true/false/0/1 arguments to
functions like this.
I'll bring it up in the non-noop patch though.
On 5/28/24 02:55, Kirill A. Shutemov wrote:
> Keep track of the number of shared pages. This will allow for
> cross-checking against the shared information in the direct mapping
> and reporting if the shared bit is lost.
It's probably also worth mentioning that conversions are slow and
On 6/4/24 08:32, Kirill A. Shutemov wrote:
> What about the comment below?
>
> /*
>* One possible reason for the failure is if kexec raced
>* with memory conversion. In this case shared bit in
>* page
On 4/24/24 07:35, Kirill A. Shutemov wrote:
>> Also, does this need to go to stable although it is kinda big for
>> stable. If stable, do we need a smaller fix first which is backportable?
> Correct me, if I am wrong, but I believe TDX guest is the only user of
> ACPI MADT wake up method. At least
On 2/25/24 06:58, Kirill A. Shutemov wrote:
> On Fri, Feb 23, 2024 at 11:39:07AM -0800, Dave Hansen wrote:
...
>> I'd really prefer we find a way to do this with actual locks, especially
>> 'conversion_allowed'.
>>
>> This is _awfully_ close to being able to
On 2/25/24 07:54, Kirill A. Shutemov wrote:
> Serializing is cumbersome here. I can also just drop the interface.
Just drop it for now. We can come back after the fact and debate how to
do the debugging.
___
kexec mailing list
On 2/12/24 02:44, Kirill A. Shutemov wrote:
> Despite the name, E820_TYPE_ACPI covers not only ACPI data, but also EFI
> tables and might be required by kernel to function properly.
Lovely. You learn something new every day.
Reviewed-by: Dave
On 2/12/24 02:44, Kirill A. Shutemov wrote:
> +static void tdx_kexec_stop_conversion(bool crash)
> +{
> + /* Stop new private<->shared conversions */
> + conversion_allowed = false;
> +
> + /*
> + * Make sure conversion_allowed is cleared before checking
> + *
On 2/12/24 02:44, Kirill A. Shutemov wrote:
> The kernel will convert all shared memory back to private during kexec.
> The direct mapping page tables will provide information on which memory
> is shared.
>
> It is extremely important to convert all shared memory. If a page is
> missed, it will
On 2/23/24 10:45, Dave Hansen wrote:
> Always filling out the level allows using lookup_address() to
> iterate over kernel page tables.
This doesn't parse very well. How about this instead:
Always filling out the level allows using lookup_address() to
precisel
dicate the size of the VA
covered by one PGD entry in 5-level paging mode.
With that fixed:
Reviewed-by: Dave Hansen
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
ce to the bools.
Reviewed-by: Dave Hansen
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On 9/27/23 17:38, Stanislav Kinsburskii wrote:
> On Thu, Sep 28, 2023 at 11:00:12AM -0700, Dave Hansen wrote:
>> On 9/27/23 17:02, Stanislav Kinsburskii wrote:
>>> On Thu, Sep 28, 2023 at 10:29:32AM -0700, Dave Hansen wrote:
>> ...
>>> Well, not exactly. That's
On 9/27/23 17:02, Stanislav Kinsburskii wrote:
> On Thu, Sep 28, 2023 at 10:29:32AM -0700, Dave Hansen wrote:
...
> Well, not exactly. That's something I'd like to have indeed, but from my
> POV this goal is out of scope of discussion at the moment.
> Let me try to express it the same
On 9/28/23 10:35, David Hildenbrand wrote:
> On 28.09.23 15:22, Dave Hansen wrote:
>> On 9/27/23 09:13, Stanislav Kinsburskii wrote:
>>> Once deposited, these pages can't be accessed by Linux anymore and thus
>>> must be preserved in "used" state across kex
On 9/27/23 16:25, Stanislav Kinsburskii wrote:
> On Thu, Sep 28, 2023 at 06:22:54AM -0700, Dave Hansen wrote:
>> On 9/27/23 09:13, Stanislav Kinsburskii wrote:
>>> Once deposited, these pages can't be accessed by Linux anymore and thus
>>> must be preserved i
On 9/27/23 09:13, Stanislav Kinsburskii wrote:
> Once deposited, these pages can't be accessed by Linux anymore and thus
> must be preserved in "used" state across kexec, as hypervisor state is
> unware of kexec.
If Linux can't access them, they're not RAM any more. I'd much rather
remove them
On 9/14/23 05:30, Kirill A. Shutemov wrote:
> +/*
> + * Total number of page table kernel_add_identity_map() can allocate,
> + * including page tables consumed by startup_32().
> + */
> +# define BOOT_PGT_SIZE (32*4096)
I agree that needing to know this in advance *exactly* is
On 9/11/23 01:09, David Hildenbrand wrote:
> So, making unaccepted memory similarly depend on "!DEVMEM ||
> STRICT_DEVMEM" does not sound too far off ...
Yeah, considering all of the invasive work folks want to do to "harden"
the kernel for TDX, doing that ^ is just about the best
On 9/7/23 08:44, Adrian Hunter wrote:
> On 7/09/23 18:39, Dave Hansen wrote:
>> On 9/6/23 00:39, Adrian Hunter wrote:
>>> @@ -559,7 +567,8 @@ static int vmcore_remap_oldmem_pfn(struct
>>> vm_area_struct *vma,
>>> * pages without a reason.
>>>
On 9/6/23 00:39, Adrian Hunter wrote:
> Do not map unaccepted memory because it can cause the guest to fail.
>
> For /proc/kcore, which is read-only and does not support mmap, this means a
> read of unaccepted memory will return zeros.
I'm confused by this changelog and subject.
What is getting
On 9/6/23 00:39, Adrian Hunter wrote:
> @@ -559,7 +567,8 @@ static int vmcore_remap_oldmem_pfn(struct vm_area_struct
> *vma,
>* pages without a reason.
>*/
> idx = srcu_read_lock(_cb_srcu);
> - if (!list_empty(_cb_list))
> + if (!list_empty(_cb_list) ||
> +
On 9/6/23 00:39, Adrian Hunter wrote:
> +static bool pfn_is_unaccepted_memory(unsigned long pfn)
> +{
> + phys_addr_t paddr = pfn << PAGE_SHIFT;
> +
> + return range_contains_unaccepted_memory(paddr, paddr + PAGE_SIZE);
> +}
Please just add this as an inline helper to common code rather
On 9/7/23 07:46, Dave Hansen wrote:
> Can a line of code in this patch even run in the face of IO_STRICT_DEVMEM=y?
Gah, I meant plain old STRICT_DEVMEM=y.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listi
On 9/7/23 07:25, Kirill A. Shutemov wrote:
> On Thu, Sep 07, 2023 at 07:15:21AM -0700, Dave Hansen wrote:
>> On 9/6/23 00:39, Adrian Hunter wrote:
>>> Support for unaccepted memory was added recently, refer commit
>>> dcdfdd40fa82 ("mm: Add support for unaccepted
On 9/6/23 00:39, Adrian Hunter wrote:
> Support for unaccepted memory was added recently, refer commit
> dcdfdd40fa82 ("mm: Add support for unaccepted memory"), whereby
> a virtual machine may need to accept memory before it can be used.
>
> Do not map unaccepted memory because it can cause the
On 3/25/23 09:01, Kirill A. Shutemov wrote:
> The last item is tricky. TDX guests use ACPI MADT MPWK to bring up
> secondary CPUs. The mechanism doesn't allow to put a CPU back offline if
> it has woken up.
I'm not sure I like this approach.
TDX uses the MADT exclusively.
MADT-based systems
On 3/25/23 12:25, Kirill A. Shutemov wrote:
> On Sat, Mar 25, 2023 at 09:25:36AM -0700, Dave Hansen wrote:
>> On 3/25/23 09:01, Kirill A. Shutemov wrote:
>>> The last item is tricky. TDX guests use ACPI MADT MPWK to bring up
>>> secondary CPUs. The mechanism doesn't allo
On 3/25/23 09:01, Kirill A. Shutemov wrote:
> The last item is tricky. TDX guests use ACPI MADT MPWK to bring up
> secondary CPUs. The mechanism doesn't allow to put a CPU back offline if
> it has woken up.
...
> +int arch_kexec_load(void)
> +{
> + if
On 2/24/23 06:30, Kirill A. Shutemov wrote:
> Ideally, it has to be addressed on BIOS level: it has to provide a way to
> offline CPUs, putting it back to pre-wakeup state.
Is there anything stopping us from just parking the CPUs in a loop
looking at 'acpi_mp_wake_mailbox_paddr'? Basically park
On 2/16/23 10:12, Kirill A. Shutemov wrote:
> On Thu, Feb 16, 2023 at 09:50:32AM -0800, Dave Hansen wrote:
>> On 2/13/23 15:48, Kirill A. Shutemov wrote:
>>> The patch brings basic enabling of kexec in TDX guests.
>>>
>>> By "basic enabling" I mean,
On 2/13/23 15:48, Kirill A. Shutemov wrote:
> The patch brings basic enabling of kexec in TDX guests.
>
> By "basic enabling" I mean, kexec in the guests with a single CPU.
> TDX guests use ACPI MADT MPWK to bring up secondary CPUs. The mechanism
> doesn't allow to put a CPU back offline if it
On 1/3/23 19:21, Baoquan He wrote:
>> Since it cleans up the last arch specific version of
>> arch_kexec_kernel_image_load in x86, maybe this patchset can go into x86
>> branch?
> Could you consider picking this patchset into x86 branch? This is a
> clean up on kexec, while the last ARCH using it
On 11/4/22 04:29, Coiby Xu wrote:
> + if (kexec_crash_image->luks_volume_key_addr) {
> + start = kexec_crash_image->luks_volume_key_addr;
> + end = start + kexec_crash_image->luks_volume_key_sz - 1;
> + page = pfn_to_page(start >> PAGE_SHIFT);
> +
On 6/28/22 16:51, Kirill A. Shutemov wrote:
> On Fri, Jun 24, 2022 at 05:00:05AM +0300, Kirill A. Shutemov wrote:
>>> If there is some deep and fundamental why this can not be supported
>>> then it probably makes sense to put some code in the arch_kexec_load
>>> hook that verifies that deep and
... adding kexec folks
On 6/14/22 05:02, Kirill A. Shutemov wrote:
> On kexec, the target kernel has to know what memory has been accepted.
> Information in EFI map is out of date and cannot be used.
>
> boot_params.unaccepted_memory can be used to pass the bitmap between two
> kernels on kexec,
On 5/30/22 01:40, Jonathan McDowell wrote:
> Borislav,
>
> I don't think there are any outstanding review comments for me to deal
> with on this, so is it safe to assume it'll get picked up at some point
> once the merge window calms down?
Nothing here looks too crazy, but it's still been _very_
On 2/16/22 19:54, Ross Philipson wrote:
> The larger focus of the TrenchBoot project (https://github.com/TrenchBoot) is
> to
> enhance the boot security and integrity in a unified manner. The first area of
> focus has been on the Trusted Computing Group's Dynamic Launch for
> establishing
> a
On 9/13/21 9:14 AM, Joerg Roedel wrote:
> On Mon, Sep 13, 2021 at 09:02:38AM -0700, Dave Hansen wrote:
>> On 9/13/21 8:55 AM, Joerg Roedel wrote:
>>> This does not work under SEV-ES, because the hypervisor has no access
>>> to the vCPU registers and can't make modificat
On 9/13/21 8:55 AM, Joerg Roedel wrote:
> This does not work under SEV-ES, because the hypervisor has no access
> to the vCPU registers and can't make modifications to them. So an
> SEV-ES guest needs to reset the vCPU itself and park it using the
> AP-reset-hold protocol. Upon wakeup the guest
of hacking in the crashdump code, this seems
sane to me. As the perpetrator of the "System RAM (kmem)" trick:
Acked-by: Dave Hansen
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On 10/12/20 9:19 AM, Eric Biggers wrote:
> On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
>>> And I still don't really understand. After this patchset, there is still
>>> code
>>> nearly identical to the above (doing a temporary mapping just for a memcpy)
>>> that
>>> would still be
On 11/27/18 7:51 PM, lijiang wrote:
> But now, the 'E820_TYPE_RESERVED' type is converted to the descriptor
> 'IORES_DESC_RESERVED'
> instead of 'IORES_DESC_NONE', it has been changed and the value of
> 'mem_flags.desc_other'
> is equal to 'true'. This is wrong.
Thanks for the improved
On 11/27/18 2:04 AM, lijiang wrote:
> What happens if we don't modify this functions
> __ioremap_check_desc_other()? -When SEV is active, it might map these
> reserved regions with the encryption mask. That is incorrect.
This is missing another sentence or two to "connect the dots".
SEV uses
On 11/23/18 9:12 PM, Lianbo Jiang wrote:
> The upstream kernel can not accurately add the e820 reserved type to> kdump
> krenel e820 table.
^ kernel
> Kdump uses walk_iomem_res_desc() to iterate io resources, then adds
> the matched resource ranges to the e820 table for kdump kernel.
On 11/23/18 9:12 PM, Lianbo Jiang wrote:
> These patches add the new I/O resource descriptor 'IORES_DESC_RESERVED'
> for the iomem resources search interfaces, and in order to make it still
> work after the new descriptor is added, these codes originally related
> to 'IORES_DESC_NONE' have been
On 11/23/18 9:12 PM, Lianbo Jiang wrote:
> These patches add the new I/O resource descriptor 'IORES_DESC_RESERVED'
> for the iomem resources search interfaces, and in order to make it still
> work after the new descriptor is added, these codes originally related
> to 'IORES_DESC_NONE' have been
On 04/27/2017 12:25 AM, Dave Young wrote:
> On 04/21/17 at 02:55pm, Dave Hansen wrote:
>> On 04/18/2017 02:22 PM, Tom Lendacky wrote:
>>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can
>>> determine if SME is active.
>>>
>>>
On 04/24/2017 08:53 AM, Tom Lendacky wrote:
> On 4/21/2017 4:52 PM, Dave Hansen wrote:
>> On 04/18/2017 02:17 PM, Tom Lendacky wrote:
>>> @@ -55,7 +57,7 @@ static inline void copy_user_page(void *to, void
>>> *from, unsigned long vaddr,
>>> __phys_addr_sym
On 04/18/2017 02:22 PM, Tom Lendacky wrote:
> Add sysfs support for SME so that user-space utilities (kdump, etc.) can
> determine if SME is active.
>
> A new directory will be created:
> /sys/kernel/mm/sme/
>
> And two entries within the new directory:
> /sys/kernel/mm/sme/active
>
On 04/18/2017 02:17 PM, Tom Lendacky wrote:
> @@ -55,7 +57,7 @@ static inline void copy_user_page(void *to, void *from,
> unsigned long vaddr,
> __phys_addr_symbol(__phys_reloc_hide((unsigned long)(x)))
>
> #ifndef __va
> -#define __va(x) ((void *)((unsigned
>
On 04/14/2013 09:52 PM, HATAYAMA Daisuke wrote:
This sounds like there's no such issue on x86 cache mechanism. Is it
correct? If so, what is the difference between ia64 and x86 cache
mechanisms?
I'm just going by the code comments:
drivers/char/mem.c
/*
* On
On 04/12/2013 07:56 AM, H. Peter Anvin wrote:
On 04/12/2013 07:31 AM, Vivek Goyal wrote:
I also have to admit that I don't see the difference between /dev/mem
and /dev/oldmem, as the former allows access to memory ranges outside
the ones used by the current kernel, which is what the oldmem
On Fri, 2011-10-28 at 15:41 -0700, Andrew Morton wrote:
+ } else if (!strncmp(buf, offline, min((int)count, 7))) {
ret = memory_block_change_state(mem, MEM_OFFLINE, MEM_ONLINE);
-
+ if (ret == 0)
+ kobject_uevent(dev-kobj, KOBJ_OFFLINE);
On Thu, 2011-10-27 at 09:30 +0200, Heiko Carstens wrote:
Are any events generated for memory add?
Looks like uevents are only genereted when memory gets registered and
unregistered, but not when when it gets set online or offline.
To achieve that you would need to add similar code to
On Sun, 2008-07-20 at 01:11 +0200, Vegard Nossum wrote:
Maybe the firmware memmap code can simply run a little later in the
boot sequence?
Heh, I'm catching up on this thread...
It is possible that it could run later. But, I do know that there are
at least a couple of these tables (on various
On Fri, 2008-06-27 at 13:12 +0200, Bernhard Walle wrote:
This patch adds /sys/firmware/memmap interface that represents the
BIOS
(or Firmware) provided memory map. The tree looks like:
/sys/firmware/memmap/0/start (hex number)
end (hex number)
59 matches
Mail list logo
