[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <975a0c6f-fdff-556f-b447-06edf24141df@linux.alibaba.com>
Date: Fri, 25 Oct 2019 10:24:14 +0800
From: Shannon Zhao <shannon.zhao@...ux.alibaba.com>
To: James Morse <james.morse@....com>
Cc: kvmarm@...ts.cs.columbia.edu, maz@...nel.org,
suzuki.poulose@....com, christoffer.dall@....com,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH RFC 0/7] Support KVM being compiled as a kernel module on
arm64
Hi James,
On 2019/10/24 18:58, James Morse wrote:
> Hi Shannon,
>
> On 24/10/2019 11:27, Shannon Zhao wrote:
>> Curently KVM ARM64 doesn't support to compile as a kernel module. It's
>> useful to compile KVM as a module.
>
>> For example, it could reload kvm without rebooting host machine.
>
> What problem does this solve?
>
> KVM has some funny requirements that aren't normal for a module. On v8.0 hardware it must
> have an idmap. Modules don't usually expect their code to be physically contiguous, but
> KVM does. KVM influences they way some of the irqchip stuff is set up during early boot
> (EOI mode ... not that I understand it).
>
> (I think KVM-as-a-module on x86 is an artifact of how it was developed)
>
>
>> This patchset support this feature while there are some limitations
>> to be solved. But I just send it out as RFC to get more suggestion and
>> comments.
>
>> Curently it only supports for VHE system due to the hyp code section
>> address variables like __hyp_text_start.
>
> We still need to support !VHE systems, and we need to do it with a single image.
>
I didn't make it clear. With this patchset we still support !VHE systems
by choose CONFIG_KVM_ARM_HOST as y and by default CONFIG_KVM_ARM_HOST is
y. And during module init, I add a check to avoid wrong usage for kvm
module.
if (IS_MODULE(CONFIG_KVM_ARM_HOST) && !is_kernel_in_hyp_mode()) {
kvm_err("kvm arm kernel module only supports for VHE system\n");
return -ENODEV;
}
>
>> Also it can't call
>> kvm_update_va_mask when loading kvm module and kernel panic with below
>> errors. So I make kern_hyp_va into a nop funtion.
>
> Making this work for the single-Image on v8.0 is going to be a tremendous amount of work.
> What is the payoff?
>
Actually we can limit this feature only working for VHE systems and
don't influence !VHE systems.
Thanks,
Shannon
Powered by blists - more mailing lists