qemu-ppc
[Top][All Lists]
Advanced

[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: Nicholas Piggin
Subject: Re: [PATCH 0/9] ppc: nested KVM HV for spapr virtual hypervisor
Date: Wed, 16 Feb 2022 19:09:58 +1000

Excerpts from Fabiano Rosas's message of February 16, 2022 5:20 am:
> 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.

Difficult to convey that in the L2 I think, but that is the case
no matter what we call it in the L0 AFAIKS.

> 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.

It provides the "nested HV" hypervisor API so it can support guests 
that use the nested HV KVM backend. The matter between TCG and real
metal is on top of that -- the user knows TCG is emulated.

So, not sure how to go. We could remove the KVM name. The cap itself
is just called nested-hv and that's what KVM uses. I think KVM here
was added in the description just so you would konw that KVM can be
run on it.

Thanks,
Nick



reply via email to

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