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

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



On 07/08/15 10:57, 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.

Plus pagetables for all of these.

The stack definitely doesn't need to be per-vcpu.  per-pcpu is fine, and
will reduce the overhead.

I still don't see why local data would be needed between calls into
depriv code.  Small enough data can live on the stack, and allowing data
to persist across calls risks getting state out-of-sync with the device
model under emulation.

(That is not to say that local data isn't needed.  I just can't see a
viable use for it at this stage.)

~Andrew

_______________________________________________
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®.