Re: [Xen-devel] [RFC 1/4] HVM x86 deprivileged mode: Page allocation helper

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 10/08/2015 09:52, Tim Deegan wrote:
> At 09:50 +0100 on 10 Aug (1439200241), Tim Deegan wrote:
>> Hi,
>>
>> At 10:57 +0100 on 07 Aug (1438945038), Ben Catterall wrote:
>>> On 06/08/15 20:22, Andrew Cooper wrote:
>>>> On 06/08/15 17:45, Ben Catterall wrote:
>>>>> This allocation function is used by the deprivileged mode initialisation 
>>>>> code
>>>>> to allocate pages for the new page table mappings and page frames on the 
>>>>> HAP
>>>>> page heap.
>>>>>
>>>>> Signed-off-by: Ben Catterall <Ben.Catterall@xxxxxxxxxx>
>>>> This is fine for your test box, but isn't fine for systems out there
>>>> without hardware EPT/NPT support.  For older systems like that (or in
>>>> certain specific workloads), shadow paging is used instead.
>>>>
>>>> This feature is applicable to any HVM domain, which means that it
>>>> shouldn't depend on HAP or shadow paging.
>>>>
>>>> How much memory is allocated for the depriv area, and what exactly is
>>>> allocated in total?
>>> So, per-vcpu:
>>> - a user mode stack which, from your comments in [RFC 2/4], can be 2 pages
>>> - local data (may or may not be needed, depends on the device) which 
>>> will be around
>>>    a page or two.
>>>
>>> Text segment: as per your comments in RFC 2/4, this will be changed to 
>>> be an alias
>>> so no extra memory.
>>>> I expect it isn't very much, and would suggest using
>>>> d->arch.paging.alloc_page() instead (which is the generic "get me some
>>>> memory accounted against the domain" helper) which looks as if it should
>>>> suffice.
>> Whie I agree that it would be good to account this to the domain,
>> paging->alloc_page() is an internal _paging assistance_ helper. :)
>> This new allocation is nothing to do with mm/paging-assistance, so
>> either it should find its own memory or the hap/shadow pool needs to
>> be made more generic.
> ...at which point other HVM overheads - VMCx pages, bitmaps &c - could
> be allocated from it as well.

 I agree very much in principle, but I believe other threads have
settles on all allocations being global, or per-pcpu, which means no
per-domain allocation.

(Not that we shouldn't have a general per-domain pool longterm)

~Andrew

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