[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4b38ad68-b6fe-0087-25f6-7820588de94d@redhat.com>
Date: Tue, 17 Mar 2020 18:51:06 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Sean Christopherson <sean.j.christopherson@...el.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>
Cc: Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, Xiaoyao Li <xiaoyao.li@...el.com>
Subject: Re: [PATCH 10/10] KVM: VMX: Convert vcpu_vmx.exit_reason to a union
On 17/03/20 06:28, Sean Christopherson wrote:
>>>
>>> +union vmx_exit_reason {
>>> + struct {
>>> + u32 basic : 16;
>>> + u32 reserved16 : 1;
>>> + u32 reserved17 : 1;
>>> + u32 reserved18 : 1;
>>> + u32 reserved19 : 1;
>>> + u32 reserved20 : 1;
>>> + u32 reserved21 : 1;
>>> + u32 reserved22 : 1;
>>> + u32 reserved23 : 1;
>>> + u32 reserved24 : 1;
>>> + u32 reserved25 : 1;
>>> + u32 reserved26 : 1;
>>> + u32 enclave_mode : 1;
>>> + u32 smi_pending_mtf : 1;
>>> + u32 smi_from_vmx_root : 1;
>>> + u32 reserved30 : 1;
>>> + u32 failed_vmentry : 1;
>> Just wondering, is there any particular benefit in using 'u32' instead
>> of 'u16' here?
> Not that I know of. Paranoia that the compiler will do something weird?
Since we have an "u32 full" it makes sense to have u32 here too, it
documents that we're matching an u32 field in the other side of the union.
Paolo
Powered by blists - more mailing lists