On 24/06/15 08:49, Jan Beulich wrote: >>>> On 24.06.15 at 04:34, <boris.ostrov...@oracle.com> wrote: >> On 06/23/2015 08:30 AM, Jan Beulich wrote: >>>>>> On 22.06.15 at 18:37, <elena.ufimts...@oracle.com> 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. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
