On 06/28/2010 09:56 AM, Sheng Yang wrote:
On Monday 28 June 2010 14:56:38 Avi Kivity wrote:
On 06/28/2010 09:42 AM, Sheng Yang wrote:
+static void wbinvd_ipi(void *garbage)
+{
+ wbinvd();
+}
Like Jan mentioned, this is quite heavy. What about a clflush() loop
instead? That may take more time, but at least it's preemptible. Of
course, it isn't preemptible in an IPI.
I think this kind of behavior happened rarely, and most recent processor
should have WBINVD exit which means it's an IPI... So I think it's maybe
acceptable here.
Several milliseconds of non-responsiveness may not be acceptable for
some applications. So I think queue_work_on() and a clflush loop is
better than an IPI and wbinvd.
OK... Would update it in the next version.
Hm, the manual says (regarding clflush):
Invalidates the cache line that contains the linear address specified
with the source
operand from all levels of the processor cache hierarchy (data and
instruction). The
invalidation is broadcast throughout the cache coherence domain. If,
at any level of
the cache hierarchy, the line is inconsistent with memory (dirty) it
is written to
memory before invalidation.
So I don't think you need to queue_work_on(), instead you can work in
vcpu thread context. But better check with someone that really knows.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
