[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 6/6] AMD-PVH: enable pvh if requirements met



On Wed, Jun 24, 2015 at 02:41:54PM -0700, Mukesh Rathor wrote:
> On Wed, 24 Jun 2015 16:26:44 -0400
> Elena Ufimtseva <elena.ufimtseva@xxxxxxxxxx> wrote:
> 
> > On Wed, Jun 24, 2015 at 07:24:18PM +0100, Andrew Cooper wrote:
> > > On 24/06/15 08:49, Jan Beulich wrote:
> > > >>>> On 24.06.15 at 04:34, <boris.ostrovsky@xxxxxxxxxx> wrote:
> > > >> On 06/23/2015 08:30 AM, Jan Beulich wrote:
> > > >>>>>> On 22.06.15 at 18:37, <elena.ufimtseva@xxxxxxxxxx> wrote:
> > > >>>> --- a/xen/arch/x86/hvm/svm/svm.c
> > > >>>> +++ b/xen/arch/x86/hvm/svm/svm.c
> > > >>>> @@ -1444,6 +1444,9 @@ const struct hvm_function_table * __init
> > > >>>> start_svm(void)
> > > >>>>       svm_function_table.hap_capabilities =
> > > >>>> HVM_HAP_SUPERPAGE_2MB | ((cpuid_edx(0x80000001) &
> > > >>>> 0x04000000) ? HVM_HAP_SUPERPAGE_1GB : 0); 
> > > >>>> +    if ( cpu_has_svm_npt  && cpu_has_svm_decode )
> > > >>>> +        svm_function_table.pvh_supported = 1;
> > > >>> If svm_decode indeed is a prereq, then the earlier patch dealing
> > > >>> with the handle_mmio() invocations doesn't need to fiddle with
> > > >>> VMEXIT_INVLPG other than to maybe add a documenting ASSERT().
> > > >>>
> > > >> I am not sure we should require decode feature to be required
> > > >> for PVH support. I can't remember exactly but I think this
> > > >> feature was first introduced in family 15h so requiring it will
> > > >> leave at least family 10h processors as not supporting PVH.
> > > > The question was why the dependency was added in the first place.
> > > > Indeed only fam 12, 15, and 16 have the field documented. Otoh
> > > > PVH isn't being supported universally on all VMX variants
> > > > either...
> > > 
> > > Right, but this is a bug (feature?) of the current implementation
> > > and need fixing.
> > > 
> > > There are no technical reasons to prevent PVH guests running in any
> > > case where an HVM guest currently runs.
> > > 
> > > The only technical restriction I can think of is that a PVH hardware
> > > domain needs IOMMU support, but that is it.
> > > 
> > 
> > CCing Mukesh, maybe he will reply to as why that restriction is here.
> 
> Hi Elena,
> 
> Basically, the restriction was to allow AMD to come on par with intel and
> get phase I working on it. Then, I could just focus on handle_mmio for
> INS/OUTS for both intel and amd, and if supporting !svm_decode family
> of CPUs was important, then extend handle_mmio further...  
> 
> http://xen-devel.narkive.com/liQjEoV2/rfh-amd-cr-intercept-for-lmsw-clts
> 
> [In the absence of svm_decode, "mov cr" would need to go thru handle_mmio..]

Thanks Mukesh! 

> 
> thanks,
> Mukesh
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.