lkml.org 
[lkml]   [2009]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 2/4] KVM: introduce "xinterface" API for external interaction with guests
Avi Kivity wrote:
> On 10/06/2009 09:40 PM, Gregory Haskins wrote:
>> Thinking about this some more over lunch, I think we (Avi and I) might
>> both be wrong (and David is right). Avi is right that we don't need
>> rmb() or barrier() for the reasons already stated, but I think David is
>> right that we need an smp_mb() to ensure the cpu doesn't do the
>> reordering. Otherwise a different cpu could invalidate the memory if it
>> reuses the freed memory in the meantime, iiuc. IOW: its not a compiler
>> issue but a cpu issue.
>>
>> Or am I still confused?
>>
>>
>
> The sequence of operations is:
>
> v = p->v;
> f();
> // rmb() ?
> g(v);
>
> You are worried that the compiler

No

> or cpu will fetch p->v after f() has executed?

Yes.

> The compiler may not, since it can't tell whether f() might
> change p->v.

Right, you were correct to say my barrier() suggestion was wrong.

> If f() can cause another agent to write to p (by freeing
> it to a global list, for example), then it is its responsibility to
> issue the smp_rmb(), otherwise no calculation that took place before f()
> and accessed p is safe.
>

IOW: David is right. You need a cpu-barrier one way or the other. We
can either allow ->release() to imply one (and probably document it that
way, like we did for slow-work), or we can be explicit. I chose to be
explicit since it is kind of self-documenting, and there is no need to
be worried about performance since the release is slow-path.

OTOH: If you feel strongly about it, we can take it out, knowing that
most anything the properly invalidates the memory will likely include an
implicit barrier of some kind.

Kind Regards,
-Greg


[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2009-10-07 14:57    [W:0.066 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site