PARTNERSHIP
Hello Sir, My name is Reem E. Al-Hashimi, the Emirates Minister of State and Managing Director of the United Arab Emirates (Dubai) World Expo 2020 Committee. I am writing to you to stand as my partner to receive my share of gratification from foreign companies whom I helped during the bidding exercise towards the Dubai World Expo 2020 Committee and also i want to use this funds to assist Coronavirus Symptoms and Causes. Am a single Arab women and serving as a minister, there is a limit to my personal income and investment level and For this reason, I cannot receive such a huge sum back to my country or my personal account, so an agreement was reached with the foreign companies to direct the gratifications to an open beneficiary account with a financial institution where it will be possible for me to instruct further transfer of the fund to a third party account for investment purpose which is the reason i contacted you to receive the fund as my partner for investment in your country. The amount is valued at Euro 47,745,533.00 with a financial institution waiting my instruction for further transfer to a destination account as soon as I have your information indicating interest to receive and invest the fund, I will compensate you with 30% of the total amount and you will also get benefit from the investment. If you can handle the fund in a good investment.Reply to: r.alhash...@yandex.com Regards, Ms. Reem ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 2/2] makedumpfile: Fix --dry-run for incomplete dumps
When running out of space during a dry run, e.g. by limiting the output size using the -L option, makedumpfile fails with [...] Can't write the dump file(vmcore). Size limit(104857600) reached. get_nr_pages: Can't seek end of the dump file(vmcore). __read_disk_dump_header: Can't open a file(vmcore). No such file or directory [...] This is because for --dry-run no dump file is created and a dummy file descriptor of -1 is used. Thus the file operations in get_nr_pages and check_and_modify_*_headers fail. Fix the first error by using write_bytes as file size for the output file and the second one by always returning TRUE for check_and_modify_headers. Fixes: 3422e1d ("[PATCH 1/2] Add --dry-run option to prevent writing the dumpfile") Signed-off-by: Philipp Rudo --- makedumpfile.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/makedumpfile.c b/makedumpfile.c index 30f9725..c063267 100644 --- a/makedumpfile.c +++ b/makedumpfile.c @@ -5113,6 +5113,9 @@ check_and_modify_multiple_kdump_headers() { int check_and_modify_headers() { + if (info->flag_dry_run) + return TRUE; + if (info->flag_elf_dumpfile) return check_and_modify_elf_headers(info->name_dumpfile); else @@ -7996,7 +7999,11 @@ get_nr_pages(void *buf, struct cache_data *cd_page){ int size, file_end, nr_pages; page_desc_t *pd = buf; - file_end = lseek(cd_page->fd, 0, SEEK_END); + if (info->flag_dry_run) + file_end = write_bytes; + else + file_end = lseek(cd_page->fd, 0, SEEK_END); + if (file_end < 0) { ERRMSG("Can't seek end of the dump file(%s).\n", cd_page->file_name); return -1; -- 2.31.1 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 1/2] makedumpfile: Fix bad file descriptor error when using --dry-run
When running makedumpfile with the --dry-run option it fails with [...] write_and_check_space: Can't seek the dump file(vmcore). Bad file descriptor [...] This is because for --dry-run no dump file is created and a dummy file descriptor of -1 is used. Thus the lseek in write_and_check_space will fail. Fix this by treating a dry run as if writing to STDOUT. Fixes: f0cfa86 ("[PATCH v2 3/3] Add -L option to limit output file size") Signed-off-by: Philipp Rudo --- makedumpfile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/makedumpfile.c b/makedumpfile.c index b1b3b42..30f9725 100644 --- a/makedumpfile.c +++ b/makedumpfile.c @@ -4712,7 +4712,7 @@ write_and_check_space(int fd, void *buf, size_t buf_size, const char* desc, int retval = 0; off_t pos; - if (fd == STDOUT_FILENO) { + if (fd == STDOUT_FILENO || info->flag_dry_run) { pos = write_bytes; } else { pos = lseek(fd, 0, SEEK_CUR); -- 2.31.1 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 0/2] makedumpfile: fix two bugs with --dry-run
Hi, While playing with the --dry-run option I noticed two bugs. You can find the fixes below. Thanks Philipp Philipp Rudo (2): makedumpfile: Fix bad file descriptor error when using --dry-run makedumpfile: Fix --dry-run for incomplete dumps makedumpfile.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) -- 2.31.1 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 07/11] treewide: Replace the use of mem_encrypt_active() with prot_guest_has()
On Wed, Aug 11, 2021 at 10:52:55AM -0500, Tom Lendacky wrote: > On 8/11/21 7:19 AM, Kirill A. Shutemov wrote: > > On Tue, Aug 10, 2021 at 02:48:54PM -0500, Tom Lendacky wrote: > >> On 8/10/21 1:45 PM, Kuppuswamy, Sathyanarayanan wrote: > >>> > >>> > >>> On 7/27/21 3:26 PM, Tom Lendacky wrote: > diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c > index de01903c3735..cafed6456d45 100644 > --- a/arch/x86/kernel/head64.c > +++ b/arch/x86/kernel/head64.c > @@ -19,7 +19,7 @@ > #include > #include > #include > -#include > +#include > #include > #include > @@ -285,7 +285,7 @@ unsigned long __head __startup_64(unsigned long > physaddr, > * there is no need to zero it after changing the memory encryption > * attribute. > */ > - if (mem_encrypt_active()) { > + if (prot_guest_has(PATTR_MEM_ENCRYPT)) { > vaddr = (unsigned long)__start_bss_decrypted; > vaddr_end = (unsigned long)__end_bss_decrypted; > >>> > >>> > >>> Since this change is specific to AMD, can you replace PATTR_MEM_ENCRYPT > >>> with > >>> prot_guest_has(PATTR_SME) || prot_guest_has(PATTR_SEV). It is not used in > >>> TDX. > >> > >> This is a direct replacement for now. > > > > With current implementation of prot_guest_has() for TDX it breaks boot for > > me. > > > > Looking at code agains, now I *think* the reason is accessing a global > > variable from __startup_64() inside TDX version of prot_guest_has(). > > > > __startup_64() is special. If you access any global variable you need to > > use fixup_pointer(). See comment before __startup_64(). > > > > I'm not sure how you get away with accessing sme_me_mask directly from > > there. Any clues? Maybe just a luck and complier generates code just right > > for your case, I donno. > > Hmm... yeah, could be that the compiler is using rip-relative addressing > for it because it lives in the .data section? I guess. It has to be fixed. It may break with complier upgrade or any random change around the code. BTW, does it work with clang for you? > For the static variables in mem_encrypt_identity.c I did an assembler rip > relative LEA, but probably could have passed physaddr to sme_enable() and > used a fixup_pointer() style function, instead. Sounds like a plan. > > A separate point is that TDX version of prot_guest_has() relies on > > cpu_feature_enabled() which is not ready at this point. > > Does TDX have to do anything special to make memory able to be shared with > the hypervisor? Yes. But there's nothing that required any changes in early boot. It handled in ioremap/set_memory. > You might have to use something that is available earlier > than cpu_feature_enabled() in that case (should you eventually support > kvmclock). Maybe. > > I think __bss_decrypted fixup has to be done if sme_me_mask is non-zero. > > Or just do it uncoditionally because it's NOP for sme_me_mask == 0. > > For SNP, we'll have to additionally call the HV to update the RMP to make > the memory shared. But that could also be done unconditionally since the > early_snp_set_memory_shared() routine will check for SNP before doing > anything. -- Kirill A. Shutemov ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec