> > 1. Since we don't use "efi_rts_wq" for efi_reset_system(), the above > > solution doesn't work if efi_reset_system() is buggy. We cannot > > neglect it either because that's the issue faced by Al Stone and hence > > I started the patch set. So, I am thinking to use long jump technique *only* for > efi_reset_system(). Would you be OK with that? > > Or please propose a new solution. > > The long jump thing is super ugly. I'd be okay with it if it were somehow > factored out into a testable mechanism, but it's a nasty complicated bit of > assembly, it will only be used very very rarely, and it more or less duplicates > switch_to(). Yes, I agree that it's complicated assembly. But I tested it by hacking OVMF. And.. you are correct that it's very very rarely used.. so probably there is no point adding complicated code for it. > > Could you just do a fallback reboot from the fault handler if > efi_reset_system() fails? > Sure! I will try that and will update you on how that goes. Hopefully, well. > > > > 2. Also, as suggested, I haven’t used a dedicated "efi_kthread", I got > > this working with the existing "efi_rts_wq" setup. Please note that, > > the existing "efi_rts_wq", has only one worker thread. Could you > > please brief me on why we should have a dedicated kthread and not leverage > "efi_rts_wq" (I am unclear on this). > > Two reasons: > > 1. If you used a dedicated thread, then you could probably just set that thread's - > >mm to the EFI mm rather than manually switching the mm. That means, we don't need efi_switch_mm() anymore and could just get away by changing efi_kthread ->mm = efi_mm. Is that what you meant? Just wanted to make sure, I understood you correctly. > > 2. If you used a dedicated thread, you would be a lot closer to being able to call > into EFI at CPL 3. In x86 Linux (and probably most or all other arches), the kernel > never calls into CPL 3. Instead it > *returns* into CPL 3. So you would set up a thread and make that thread's > task_pt_regs() have the correct context for a little stub that calls into EFI and > then does "syscall". Then you would return all the way out of the kernel into the > stub. I got it.. not 100% though.. but I will surely work on this because it sounds very interesting to me. But still, I have a question, this article https://lwn.net/Articles/23634/ says that "each workqueue has one or more dedicated worker threads (one per CPU, by default) associated with it" So, do you think we still need our own efi dedicated kthread? Regards, Sai ��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
