[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171017082020.ctgjuo4xcvsaitdf@pd.tnic>
Date: Tue, 17 Oct 2017 10:20:20 +0200
From: Borislav Petkov <bp@...en8.de>
To: Brijesh Singh <brijesh.singh@....com>
Cc: x86@...nel.org, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
Tom Lendacky <thomas.lendacky@....com>,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [Part1 PATCH v6 16/17] X86/KVM: Decrypt shared per-cpu variables
when SEV is active
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.
> 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() ?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Powered by blists - more mailing lists