From: Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@xxxxxxxxxxxxxxx> > > > > 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. > >
