On Monday 28 June 2010 11:56:08 Avi Kivity wrote:
On 06/28/2010 06:36 AM, Sheng Yang wrote:
Some guest device driver may leverage the Non-Snoop I/O, and explicitly
WBINVD or CLFLUSH to a RAM space. Since migration may occur before WBINVD
or
CLFLUSH, we need to maintain data consistency
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.
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
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
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
On Monday 28 June 2010 15:08:56 Avi Kivity wrote:
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
On 06/28/2010 10:41 AM, Sheng Yang wrote:
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
Dong, Eddie wrote:
Avi Kivity wrote:
On 06/28/2010 10:30 AM, Dong, Eddie wrote:
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.
Probably we should make it configurable.
On 06/28/2010 06:36 AM, Sheng Yang wrote:
Some guest device driver may leverage the Non-Snoop I/O, and explicitly
WBINVD or CLFLUSH to a RAM space. Since migration may occur before WBINVD or
CLFLUSH, we need to maintain data consistency either by:
Don't we always force enable snooping? Or