On Mon, Jan 14, 2019 at 11:54:30AM +0100, Vitaly Kuznetsov wrote:
> Vitaly Kuznetsov writes:
>
> > Eduardo Habkost writes:
> >
> >> On Wed, Dec 19, 2018 at 06:25:06PM +0100, Vitaly Kuznetsov wrote:
> >>> Eduardo Habkost writes:
> >>>
> >>> > On Mon, Dec 03, 2018 at 03:17:06PM +0100, Vitaly
Vitaly Kuznetsov writes:
> Eduardo Habkost writes:
>
>> On Wed, Dec 19, 2018 at 06:25:06PM +0100, Vitaly Kuznetsov wrote:
>>> Eduardo Habkost writes:
>>>
>>> > On Mon, Dec 03, 2018 at 03:17:06PM +0100, Vitaly Kuznetsov wrote:
>>> >> Eduardo Habkost writes:
>>> > [...]
>>> >> > But note that
Eduardo Habkost writes:
> On Wed, Dec 19, 2018 at 06:25:06PM +0100, Vitaly Kuznetsov wrote:
>> Eduardo Habkost writes:
>>
>> > On Mon, Dec 03, 2018 at 03:17:06PM +0100, Vitaly Kuznetsov wrote:
>> >> Eduardo Habkost writes:
>> > [...]
>> >> > But note that we might still be able to move the
On Wed, Dec 19, 2018 at 06:25:06PM +0100, Vitaly Kuznetsov wrote:
> Eduardo Habkost writes:
>
> > On Mon, Dec 03, 2018 at 03:17:06PM +0100, Vitaly Kuznetsov wrote:
> >> Eduardo Habkost writes:
> > [...]
> >> > But note that we might still be able to move the existing
> >> > "hyperv_*" features
Eduardo Habkost writes:
> On Mon, Dec 03, 2018 at 03:17:06PM +0100, Vitaly Kuznetsov wrote:
>> Eduardo Habkost writes:
> [...]
>> > But note that we might still be able to move the existing
>> > "hyperv_*" features to feature_word_info[].feat_names. We just
>> > need to keep the same semantics
Eduardo Habkost writes:
>>[...] Some time ago when merging direct mode stimers for KVM
>> Paolo suggested we stop adding capabilities to KVM for each individulat
>> feature and replace them with something like KVM_GET_SUPPORTED_HV_CPUID
>> ioctl returning all Hyper-V related feature
On Mon, Dec 03, 2018 at 03:17:06PM +0100, Vitaly Kuznetsov wrote:
> Eduardo Habkost writes:
[...]
> > But note that we might still be able to move the existing
> > "hyperv_*" features to feature_word_info[].feat_names. We just
> > need to keep the same semantics (e.g. enable
> >
Eduardo Habkost writes:
> On Thu, Nov 29, 2018 at 12:51:55PM +0100, Vitaly Kuznetsov wrote:
>> Paolo Bonzini writes:
>>
>> > On 26/11/18 14:59, Vitaly Kuznetsov wrote:
>> >> It was found that QMP users of QEMU (e.g. libvirt) may need
>> >>
On Thu, Nov 29, 2018 at 12:51:55PM +0100, Vitaly Kuznetsov wrote:
> Paolo Bonzini writes:
>
> > On 26/11/18 14:59, Vitaly Kuznetsov wrote:
> >> It was found that QMP users of QEMU (e.g. libvirt) may need
> >> HV_CPUID_ENLIGHTMENT_INFO.EAX/HV_CPUID_NESTED_FEATURES.EAX information. In
> >>
Paolo Bonzini writes:
> On 26/11/18 14:59, Vitaly Kuznetsov wrote:
>> It was found that QMP users of QEMU (e.g. libvirt) may need
>> HV_CPUID_ENLIGHTMENT_INFO.EAX/HV_CPUID_NESTED_FEATURES.EAX information. In
>> particular, 'hv_tlbflush' and 'hv_evmcs' enlightenments are only exposed in
>>
On 26/11/18 14:59, Vitaly Kuznetsov wrote:
> It was found that QMP users of QEMU (e.g. libvirt) may need
> HV_CPUID_ENLIGHTMENT_INFO.EAX/HV_CPUID_NESTED_FEATURES.EAX information. In
> particular, 'hv_tlbflush' and 'hv_evmcs' enlightenments are only exposed in
> HV_CPUID_ENLIGHTMENT_INFO.EAX.
>
>
On Mon, Nov 26, 2018 at 02:59:58PM +0100, Vitaly Kuznetsov wrote:
> It was found that QMP users of QEMU (e.g. libvirt) may need
> HV_CPUID_ENLIGHTMENT_INFO.EAX/HV_CPUID_NESTED_FEATURES.EAX information. In
> particular, 'hv_tlbflush' and 'hv_evmcs' enlightenments are only exposed in
>
It was found that QMP users of QEMU (e.g. libvirt) may need
HV_CPUID_ENLIGHTMENT_INFO.EAX/HV_CPUID_NESTED_FEATURES.EAX information. In
particular, 'hv_tlbflush' and 'hv_evmcs' enlightenments are only exposed in
HV_CPUID_ENLIGHTMENT_INFO.EAX.
HV_CPUID_NESTED_FEATURES.EAX is exposed for two
13 matches
Mail list logo