From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [PATCH v2 04/13] KVM: x86: API changes for SMM support Date: Thu, 28 May 2015 15:48:24 +0200 Message-ID: <20150528134821.GA6974@potion.brq.redhat.com> References: <1432746314-50196-1-git-send-email-pbonzini@redhat.com> <1432746314-50196-5-git-send-email-pbonzini@redhat.com> <5566D93C.8090306@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, guangrong.xiao@linux.intel.com, bdas@redhat.com To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:50149 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752606AbbE1Ns2 (ORCPT ); Thu, 28 May 2015 09:48:28 -0400 Content-Disposition: inline In-Reply-To: <5566D93C.8090306@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 2015-05-28 11:00+0200, Paolo Bonzini: > On 27/05/2015 19:05, Paolo Bonzini wrote: > > This patch includes changes to the external API for SMM support. > > All the changes are predicated by the availability of a new > > capability, KVM_CAP_X86_SMM, which is added at the end of the > > patch series. > > > > Signed-off-by: Paolo Bonzini > > Radim, I forgot to change flags to u8 in this patch. However, I am > thinking that it's just as good to leave it as u16. The reason is that > the other two fields in this 32-bit word were just 1-bit flags that were > expanded to 8 bits for no particular reasons. (Yeah, it's sad that we have wasted all those bits.) > If we make it now > > u8 flags; > u8 padding2; > > chances are that in due time it will become simply > > u8 flags; > u8 flags2; True, I forgot that big endian exists, so we can't just say u16 later. (u8 avoids endianess problems of C bit-fields, but I wouldn't have brought it up when u8 isn't strictly better ...) > and then it's nicer to just have an u16. On the other hand, your > argument that KVM_RUN has very little free space is also a good one. Thinking more about it ... we don't forbid multi-bit flags, so u16 can be used fairly the same way. (u16 would be a bit worse for an 8 bit vector, but nicer for >8 bit vector.) > What do you think? I have already done the change in my local repo, but > I can change it back too. I'd be glad if we were more bit-field friendly, but whatever is the least work for you is the best :)