Xen devel - Sep 2006 - TLB flushing in blktap kernel driver?

Hi all,

I''ve been fixing blktap to build as a kernel module, and have come
across one un-exported symbol that blktap needs: flush_tlb_all(), used
in

static unsigned int blktap_poll(struct file *file, poll_table *wait)
{
...
	poll_wait(file, &info->wait, wait);
	if (info->ufe_ring.req_prod_pvt != info->ufe_ring.sring->req_prod) {
		flush_tlb_all();
		RING_PUSH_REQUESTS(&info->ufe_ring);
		return POLLIN | POLLRDNORM;
	}
	return 0;
}

However, I can''t understand right now why we need the tlb flush here.
If we''re doing any grant table operations between dom0 and domU, then
the HV should be doing the tlb flushes for us, shouldn''t it?  And mere
SMP synchronisation on a ring buffer requires a physical memory barrier,
not a TLB synchronisation (and RING_PUSH_REQUESTS already does a wmb.)

--Stephen



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> However, I can''t understand right now why we need the tlb flush
here.
> If we''re doing any grant table operations between dom0 and domU,
then
> the HV should be doing the tlb flushes for us, shouldn''t it?  And
mere
> SMP synchronisation on a ring buffer requires a physical memory barrier,
> not a TLB synchronisation (and RING_PUSH_REQUESTS already does a wmb.)
Grant unmapping certainly guarantees to flush TLB entries.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi,

On Wed, 2006-09-27 at 14:30 +0100, Keir Fraser wrote:
> > However, I can''t understand right now why we need the tlb
flush here.
> > If we''re doing any grant table operations between dom0 and
domU, then
> > the HV should be doing the tlb flushes for us, shouldn''t it? 
And mere
> > SMP synchronisation on a ring buffer requires a physical memory
barrier,
> > not a TLB synchronisation (and RING_PUSH_REQUESTS already does a wmb.)
> 
> Grant unmapping certainly guarantees to flush TLB entries.
Right.  I can''t see why a simple ring buffer poll would *ever* need to
flush tlbs.  I may be missing something, which is why I asked, but it
looks like this was perhaps just intended to be a memory barrier, in
which case the flush call is entirely superfluous (and a significant
performance hit to boot.)

--Stephen



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Agreed -- not sure why that''s there, possibly from before the days of
grant tables.  I agree that it can go though.  good catch.

a.

On 9/27/06, Stephen C. Tweedie <sct@redhat.com>
wrote:
> Hi,
>
> On Wed, 2006-09-27 at 14:30 +0100, Keir Fraser wrote:
> > > However, I can''t understand right now why we need the
tlb flush here.
> > > If we''re doing any grant table operations between dom0
and domU, then
> > > the HV should be doing the tlb flushes for us, shouldn''t
it?  And mere
> > > SMP synchronisation on a ring buffer requires a physical memory
barrier,
> > > not a TLB synchronisation (and RING_PUSH_REQUESTS already does a
wmb.)
> >
> > Grant unmapping certainly guarantees to flush TLB entries.
>
> Right.  I can''t see why a simple ring buffer poll would *ever*
need to
> flush tlbs.  I may be missing something, which is why I asked, but it
> looks like this was perhaps just intended to be a memory barrier, in
> which case the flush call is entirely superfluous (and a significant
> performance hit to boot.)
>
> --Stephen
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel