Messages in this thread | | | From | "Michael Kelley (LINUX)" <> | Subject | RE: [Patch v4 05/13] init: Call mem_encrypt_init() after Hyper-V hypercall init is done | Date | Tue, 6 Dec 2022 20:13:08 +0000 |
| |
From: Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@linux.intel.com> > > > > On 12/1/22 7:30 PM, Michael Kelley wrote: > > Full Hyper-V initialization, including support for hypercalls, is done > > as an apic_post_init callback via late_time_init(). mem_encrypt_init() > > needs to make hypercalls when it marks swiotlb memory as decrypted. > > But mem_encrypt_init() is currently called a few lines before > > late_time_init(), so the hypercalls don't work. > > Did you consider moving hyper-v hypercall initialization before > mem_encrypt_init(). Is there any dependency issue?
Hyper-V initialization has historically been done using the callbacks that exist in the x86 initialization paths, rather than adding explicit Hyper-V init calls. As noted above, the full Hyper-V init is done on the apic_post_init callback via late_time_init(). Conceivably we could add an explicit call to do the Hyper-V init, but I think there's still a problem in putting that Hyper-V init prior to the current location of mem_encrypt_init(). I'd have to go check the history, but I think the Hyper-V init needs to happen after the APIC is initialized.
It seems like moving mem_encrypt_init() slightly later is the cleaner long-term solution. Are you aware of a likely problem arising in the future with moving mem_encrypt_init()?
Michael
> > > > > Fix this by moving mem_encrypt_init() after late_time_init() and > > related clock initializations. The intervening initializations don't > > do any I/O that requires the swiotlb, so moving mem_encrypt_init() > > slightly later has no impact. > >
| |