On 10/17/17 3:20 AM, Borislav Petkov wrote: > On Mon, Oct 16, 2017 at 08:43:15PM -0500, Brijesh Singh wrote: >> Actually, I worked to enable the kvmclock support before the >> kvm-stealtime, eoi and apf_reason. The kvmclock uses memblock_alloc() to >> allocate the shared memory and since the memblock_alloc() returns the >> physical address hence I used the same input type as a argument to the >> early_set_memory_decrypted(). If you want me to change the input to >> accept the virtual address then I have no issue doing so. But the >> changes need to propagated to kvmclock (i.e PATCH 17/17) to use __va(). > And? You already convert addresses you've gotten from memblock with > __va there. > >> Please let me know if you want me to pass the virtual address. > Yes please. The kernel generally handles virtual addresses and the > physical addresses you get from memblock, you simply convert once and > hand in for decryption. Will do. Do you want me to send v7 with that addressed. Because this require changes in 3 patches (PATCH 14, 16, 17) > >> IIRC, we tried clearing C bit in kvm_guest_init() but since the >> kvm_guest_init() is called before setup_per_cpu_areas() hence >> per_cpu_ptr(var, cpu_id) was not able to get another processors copy of >> the variable. > But you are still calling it in kvm_guest_init(). So that second call > can be removed and you can call it only in kvm_smp_prepare_boot_cpu() ? > The second call is for UP cases. The kvm_smp_prepapre_boot_cpu() is called only when CONFIG_SMP is enabled. Am I missing something ?
