From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v4] x86/HVM: Merge HVM and PVH hypercall tables Date: Fri, 18 Dec 2015 21:24:27 +0000 Message-ID: <5674798B.8020406@citrix.com> References: <1450472960-5524-1-git-send-email-boris.ostrovsky@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1450472960-5524-1-git-send-email-boris.ostrovsky@oracle.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: Boris Ostrovsky , jbeulich@suse.com Cc: xen-devel@lists.xen.org, roger.pau@citrix.com List-Id: xen-devel@lists.xenproject.org On 18/12/2015 21:09, Boris Ostrovsky wrote: > The tables are almost identical and therefore there is little reason to > keep both sets. > > PVH needs 3 extra hypercalls: > * mmuext_op. MMUEXT_PIN_L_TABLE are required by control domain (dom0) > when building guests. We add MMUEXT_UNPIN_TABLE for completeness. > * platform_op. These are only available to privileged domains. We will > (eventually) have privileged HVMlite guests and therefore shouldn't > limit this to PVH only. > * xenpmu_op. any guest with !has_vlapic() (i.e. PV, PVH and HVMlite) > should be able to use it. > > Note that until recently PVH guests used mmuext_op's MMUEXT_INVLPG_MULTI and > MMUEXT_TLB_FLUSH_MULTI commands but it has been determined that using the > former was incorrect and using the latter is correct for now but is not > guaranteed to work in the future. > > Signed-off-by: Boris Ostrovsky Reviewed-by: Andrew Cooper