[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/9] ppc: nested KVM HV for spapr virtual hypervisor

From: Fabiano Rosas
Subject: Re: [PATCH 0/9] ppc: nested KVM HV for spapr virtual hypervisor
Date: Tue, 15 Feb 2022 16:20:04 -0300

Daniel Henrique Barboza <danielhb413@gmail.com> writes:

> On 2/15/22 15:33, Cédric Le Goater wrote:
>> On 2/15/22 04:16, Nicholas Piggin wrote:
>>> Here is the rollup of patches in much better shape since the RFC.
>>> I include the 2 first ones unchanged from independent submission
>>> just to be clear that this series requires them.
>>> Thanks Cedric and Fabiano for wading through my poor quality RFC
>>> code, very good changes suggested and I hope I got most of them
>>> and this one is easier to follow.
>> This is in good shape and functional. I will try to propose a small
>> buildroot environment for it, so that we don't have to start a full
>> distro to test.
>> I would like to talk about the naming. KVM-HV is I think "reserved"
>> to the PowerNV platform (baremetal). We also have KVM-PR which runs
>> KVM guests on various platforms, including pseries.
>> How can we call this yet another KVM PPC implementation ?
> Do we need a new name? I believe Nick uses the stock kvm_hv kernel module in 
> this
> implementation.
> If we want a name to differ between the different KVM-HV usages, well, I'd 
> suggest
> KVM-EHV (Emulated HV) or KVM-NHV (Nested HV) or KVM-VHV (Virtual HV) or 
> anything
> that suggests that this is a different flavor of using KVM-HV.

I'd say it's imperative to have a clear indication that this is
TCG. Otherwise we'll have people trying to weird stuff with it and
complaining that Nested KVM is bugged.

Some ideas:

Emulated Nested KVM
Emulated Nested HV
Nested TCG

The first one is perhaps more accurate, but we'd end up having "kvm"
mentioned in TCG code and that is super confusing.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]