qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v4 16/21] i386: track explicit 'hv-*' features enablement/dis


From: Vitaly Kuznetsov
Subject: Re: [PATCH v4 16/21] i386: track explicit 'hv-*' features enablement/disablement
Date: Mon, 15 Feb 2021 19:12:52 +0100

Igor Mammedov <imammedo@redhat.com> writes:

> On Mon, 15 Feb 2021 09:56:19 +0100
> Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
>
>> Igor Mammedov <imammedo@redhat.com> writes:
>> 
>> > On Fri, 12 Feb 2021 16:26:03 +0100
>> > Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
>> >  
>> >> Vitaly Kuznetsov <vkuznets@redhat.com> writes:
>> >>   
>> >> > Igor Mammedov <imammedo@redhat.com> writes:
>> >> >    
>> >> >>
>> >> >> Please try reusing scratch CPU approach, see
>> >> >>   kvm_arm_get_host_cpu_features()
>> >> >> for an example. You will very likely end up with simpler series,
>> >> >> compared to reinventing wheel.    
>> >> >
>> >> > Even if I do that (and I serioulsy doubt it's going to be easier than
>> >> > just adding two 'u64's, kvm_arm_get_host_cpu_features() alone is 200
>> >> > lines long) this is not going to give us what we need to distinguish
>> >> > between
>> >> >
>> >> > 'hv-passthrough,hv-evmcs'
>> >> >
>> >> > and 
>> >> >
>> >> > 'hv-passthrough'
>> >> >
>> >> > when 'hv-evmcs' *is* supported by the host. When guest CPU lacks VMX we
>> >> > don't want to enable it unless it was requested explicitly (former but
>> >> > not the later).    
>> >> 
>> >> ... and if for whatever reason we decide that this is also bad/not
>> >> needed, I can just drop patches 16-18 from the series (leaving
>> >> 'hv-passthrough,hv-feature=off' problem to better times).  
>> > that's also an option,
>> > we would need to make sure that hv-passthrough is mutually exclusive
>> > with ''all'' other hv- properties to avoid above combination being
>> > ever (mis)used.  
>> 
>> That's an option to finally get these patches merged, not a good option
>> for end users. 
>> 
>> 'hv-passthrough,hv-feature' works today and it's useful. Should we drop
>> it?
> well,
> try suggested idea about using scratch CPU and it might get merged sooner.
> (it's not like I'm suggesting you to rewrite half of QEMU, just some of
> patches, which most likely would simplify series from my point of view
> and would be easier to maintain)
>

I don't see anything in the series which will go away if I implement
this idea but as I hate it deerly I'm likely not going to.

-- 
Vitaly




reply via email to

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