Re: [Xen-devel] [PATCH v2 1/1] xen: move TLB-flush filtering out into populate_physmap

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 06/09/16 10:39, David Vrabel wrote:
> On 06/09/16 09:42, Dongli Zhang wrote:
>> This patch implemented parts of TODO left in commit id
>> a902c12ee45fc9389eb8fe54eeddaf267a555c58. It moved TLB-flush filtering out
>> into populate_physmap.
>>
>> Because of TLB-flush in alloc_heap_pages, it's very slow to create a guest
>> with memory size of more than 100GB on host with 100+ cpus.
>>
>> This patch introduced a "MEMF_no_tlbflush" bit to memflag to indicate
>> whether TLB-flush should be done in alloc_heap_pages or its caller
>> populate_physmap.  Once this bit is set in memflag, alloc_heap_pages will
>> ignore TLB-flush.
> 
> This makes pages accessible to the guest B, when guest A may still have
> a cached mapping to them.
>
> I think it is only safe to do this when guest B is being constructed.

Only before the populate_physmap hypercall returns, right?  In order to
run afoul of this, a second vcpu on the guest would have to map and then
put something secret / sensitive in the memory (such as a private key
which guest A could then read, or code it intended to execute that guest
A could then modify) before the hypercall finished.  That seems like
something we should be able to document as undefined / unsafe behavior
if we want.

OTOH, unless we care about the ability to balloon up and down by
hundreds of gigabytes at a time, it probably wouldn't hurt to limit the
optimization only to domain build time.

 -George

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