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

[Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>]

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




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