[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC 00/12] Nested p2m: allow sharing between vCPUs
On Mon, 2017-08-28 at 18:03 +0100, George Dunlap wrote: > On 07/18/2017 11:34 AM, Sergey Dyasli wrote: > > Nested p2m (shadow EPT) is an object that stores memory address > > translations from L2 GPA directly to L0 HPA. This is achieved by > > combining together L1 EPT tables with L0 EPT during L2 EPT violations. > > > > In the usual case, L1 uses the same EPTP value in VMCS12 for all vCPUs > > of a L2 guest. But unfortunately, in current Xen's implementation, each > > vCPU has its own n2pm object which cannot be shared with other vCPUs. > > This leads to the following issues if a nested guest has SMP: > > > > 1. There will be multiple np2m objects (1 per nested vCPU) with > > the same np2m_base (L1 EPTP value in VMCS12). > > > > 2. Same EPT violations will be processed independently by each vCPU. > > > > 3. Since MAX_NESTEDP2M is defined as 10, if a domain has more than > > 10 nested vCPUs, performance will be extremely degraded due to > > constant np2m LRU list thrashing and np2m flushing. > > > > This patch series makes it possible to share one np2m object between > > different vCPUs that have the same np2m_base. Sharing of np2m objects > > improves scalability of a domain from 10 nested vCPUs to 10 nested > > guests (with arbitrary number of vCPUs per guest). > > On the whole this looks like a decent approach. > > Were you planning on re-sending it with the RFC removed, or would you > like me to do a detailed review of this series as it is? Thanks for review! My current plan is to re-send the series as v1 after addressing your and Christoph's comments. Let's wait for that before detailed review :) Oh and there is a possibility I may do some AMD testing. -- Thanks, Sergey _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |