[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 1/1] xen: move TLB-flush filtering out into populate_physmap
On 06/09/16 10:52, George Dunlap wrote: > 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. I think populate_physmap can replace existing p2m entries, and thus guest B may already have mappings. David _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |