>>> On 03.02.16 at 09:28, <haozhong.zh...@intel.com> wrote: > On 02/02/16 14:15, Konrad Rzeszutek Wilk wrote: >> > 3.1 Guest clwb/clflushopt/pcommit Enabling >> > >> > The instruction enabling is simple and we do the same work as in KVM/QEMU. >> > - All three instructions are exposed to guest via guest cpuid. >> > - L1 guest pcommit is never intercepted by Xen. >> >> I wish there was some watermarks like the PLE has. >> >> My fear is that an unfriendly guest can issue sfence all day long >> flushing out other guests MMC queue (the writes followed by pcommits). >> Which means that an guest may have degraded performance as their >> memory writes are being flushed out immediately as if they were >> being written to UC instead of WB memory. > > pcommit takes no parameter and it seems hard to solve this problem > from hardware for now. And the current VMX does not provide mechanism > to limit the commit rate of pcommit like PLE for pause. > >> In other words - the NVDIMM resource does not provide any resource >> isolation. However this may not be any different than what we had >> nowadays with CPU caches. >> > > Does Xen have any mechanism to isolate multiple guests' operations on > CPU caches?
No. All it does is disallow wbinvd for guests not controlling any actual hardware. Perhaps pcommit should at least be limited in a similar way? >> > - L1 hypervisor is allowed to intercept L2 guest pcommit. >> >> clwb? > > VMX is not capable to intercept clwb. Any reason to intercept it? I don't think so - otherwise normal memory writes might also need intercepting. Bus bandwidth simply is shared (and CLWB operates on a guest virtual address, so can only cause bus traffic for cache lines the guest has managed to dirty). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel