From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [PATCH 6/18 V2]: PVH xen: Introduce PVH guest type Date: Mon, 25 Mar 2013 15:04:13 -0700 Message-ID: <20130325150413.69c9d18b@mantra.us.oracle.com> References: <20130325120507.5621a913@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Keir Fraser Cc: Jan Beulich , xen-devel List-Id: xen-devel@lists.xenproject.org On Mon, 25 Mar 2013 20:07:10 +0000 Keir Fraser wrote: > On 25/03/2013 19:05, "Mukesh Rathor" wrote: > > >> These are all ugly, and I don't see why the triplet I suggested > >> (is_pv, is_pvh, and is_hvm), including their intended use, wouldn't > >> be acceptable. > > > > Because this implies pvh is a new type, whereas like I said before, > > PVH is a PV guest. Ok, lets go with your suggestion above, and if > > people find it confusing, we can change in future. > > It's not really PV -- the interfaces and execution environment are > somewhat different, evidence being that a legacy PV guest will not > boot in PVH mode! There are certainly similarities, but then there > are between HVM and PV too (e.g., many hypercalls), so at the end of > the day a guest is one of PV/PVH/HVM. So I have to agree with Jan. LOL... which is why originally I had called it hybrid (neither PV nor HVM), but then many here convinced me it should be called a PV something because it was a PV. Anyways, no more on this. { is_pv, is_pvh, is_hvm } it is. Thanks, Mukesh