From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH v14 04/17] Introduce pv guest type and has_hvm_container macros Date: Mon, 4 Nov 2013 16:26:46 +0000 Message-ID: <5277CAC6.9090300@eu.citrix.com> References: <1383567306-6636-1-git-send-email-george.dunlap@eu.citrix.com> <1383567306-6636-5-git-send-email-george.dunlap@eu.citrix.com> <5277D75E02000078000FF305@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" 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 1VdMzO-0007Ku-6J for xen-devel@lists.xenproject.org; Mon, 04 Nov 2013 16:26:54 +0000 In-Reply-To: <5277D75E02000078000FF305@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , Keir Fraser , Tim Deegan List-Id: xen-devel@lists.xenproject.org On 04/11/13 16:20, Jan Beulich wrote: >>>> On 04.11.13 at 13:14, George Dunlap wrote: >> The goal of this patch is to classify conditionals more clearly, as to >> whether they relate to pv guests, hvm-only guests, or guests with an >> "hvm container" (which will eventually include PVH). >> >> This patch introduces an enum for guest type, as well as two new macros >> for switching behavior on and off: is_pv_* and has_hvm_container_*. At the >> moment is_pv_* <=> !has_hvm_container_*. The purpose of having two is that >> it seems to me different to take a path because something does *not* have PV >> structures as to take a path because it *does* have HVM structures, even if >> the >> two happen to coincide 100% at the moment. The exact usage is occasionally >> a bit >> fuzzy though, and a judgement call just needs to be made on which is >> clearer. >> >> In general, a switch should use is_pv_* (or !is_pv_*) if the code in >> question >> relates directly to a PV guest. Examples include use of pv_vcpu structs or >> other behavior directly related to PV domains. >> >> hvm_container is more of a fuzzy concept, but in general: > So sadly this is still being retained, despite its redundancy. I understood our discussion at XenSummit to be that I should send the series as-is, once I had fixed the outstanding bugs. I'm inclined to consider Tim's suggestion (as I understand it), that we get rid of the separate PVH mode, but instead have a number of features which can be enabled and disabled (apic, qemu, &c). But that shouldn't affect the interface to Linux. -George