From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [RFC PATCH 03/10] Add cpuid_vmware_leaves Date: Mon, 16 Dec 2013 08:13:39 +0000 Message-ID: <52AEC443020000780010D7AD@nat28.tlf.novell.com> References: <1386875718-28166-1-git-send-email-dslutz@terremark.com> <1386875718-28166-4-git-send-email-dslutz@terremark.com> <52AA383B.8000105@citrix.com> <52AAF59C020000780010CEC9@nat28.tlf.novell.com> <52AB0DDF.9050008@citrix.com> <52AB580E.9060504@terremark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VsTJC-0001cv-6i for xen-devel@lists.xenproject.org; Mon, 16 Dec 2013 08:13:46 +0000 In-Reply-To: <52AB580E.9060504@terremark.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Don Slutz Cc: Keir Fraser , Ian Campbell , StefanoStabellini , Jun Nakajima , Andrew Cooper , Eddie Dong , Suravee Suthikulpanit , xen-devel , Boris Ostrovsky , Ian Jackson List-Id: xen-devel@lists.xenproject.org >>> On 13.12.13 at 19:55, Don Slutz wrote: > On 12/13/13 08:38, Andrew Cooper wrote: >> On 13/12/2013 10:55, Jan Beulich wrote: >>>>>> On 12.12.13 at 23:27, Andrew Cooper wrote: >>>> On 12/12/2013 19:15, Don Slutz wrote: >>>>> + if ( is_viridian_domain(d) ) >>>>> + base += 0x100; >>>>> + if ( is_vmware_domain(d) ) >>>>> + base += 0x100; >>>>> + > As a related question: Should I reply to each e-mail, or is the reply at the > thread place (like here) ok? Generally per-mail answers are preferred, as that makes the context more obvious. Occasionally you'll find that overall effect is better if you reply to multiple levels of contexts at once. But please, for legibility's sake, include blank lines between quoted text and your responses. >>> And it seems highly questionable to me whether having both at the >>> same time makes much sense. >>> >>> Plus the new function doesn't belong in xen/arch/x86/traps.c ... > I read this as "Change to some sort of data structure to get the answer > instead of a function". This is because I do not see how to return the > correct data from a function if it is not in xen/arch/x86/traps.c (like > cpuid_hypervisor_leaves is) or called from there, which I would see as more > confusing. Just like cpuid_viridian_leaves() lives in xen/arch/x86/hvm/viridian.c, your new function should live in e.g. xen/arch/x86/hvm/vmware.c. Jan