Re: [Xen-devel] [PATCH 0 of 2] Support for Paging/Sharing on AMD

["Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>]

> Hi,
>
>> diff -r 5a7e18e57c72 -r 228f7aebb0ff xen/arch/x86/mm/mem_event.c
>> --- a/xen/arch/x86/mm/mem_event.c
>> +++ b/xen/arch/x86/mm/mem_event.c
>> @@ -563,8 +563,11 @@ int mem_event_domctl(struct domain *d, x
>>              if ( !hap_enabled(d) )
>>                  break;
>>
>> -            /* Currently only EPT is supported */
>> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>> +            /* Currently EPT or AMD with no iommu/hap page table
>> sharing are
>> +             * supported. Further, AMD considered experimental atm. */
>> +            if ( !((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) ||
>> +                   ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
>> +                     !iommu_use_hap_pt(d))) )
>
> I think we can just drop the test for Intelness rather than adding one
> for AMDness.  hap_enabled() above is good enough to avoid Cyrix &c. :)
> Also, I think the cset I just checked in to interlock IOMMU vs
> sharing/paging should be enough that we don't need the
> !iommu_use_hap_pt(d) test either (or is there some concern about the
> pagetable layout?)

In AMD land, p2m type bits are taken over by iommu flags and reserved
bits. If iommu is not being used, it doesn't really matter. Being
paranoid.

I guess if someone were up for a small challenge, they could add
mem_access support for AMD. Most of the work is done by now. I have some
ugly draft work I can share.

>
> That is, can we just drop this whole test?

Ok. Do you need me to submit a patch for that?

>
> The right place to mark it experimental is in the user docs and example
> config files.

Mem_sharing is blatantly undocumented. When I find a few cycles I'll
submit some documentation.

Thanks,
Andres

>
> Cheers,
>
> Tim.
>



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