tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Why NetBSD x86's bus_space_barrier does not use [sml]fence?



Thank you for your information.

> Are you using BUS_SPACE_MAP_PREFETCHABLE?

No, the driver does not use it.

> It no, the CALL instruction that calls bus_space_barrier() produces a
write
> to the stack when storing the return address.  On x86, stores are totally
> ordered, and loads are never reordered around stores.  No further barrier
> is needed.  This is the idea anyway, sometimes reality does not match..

Should NetBSD need to use the fences to *completely* prevent
a reorder as other BSDs although the CALL instruction can
typically avoid a reorder?

I have checked resolving the issue using the following diff.
And I would like to apply the diff to -current if it is correct.

diff --git a/sys/arch/x86/x86/bus_space.c b/sys/arch/x86/x86/bus_space.c
index 3d206df8548..0b697b49a27 100644
--- a/sys/arch/x86/x86/bus_space.c
+++ b/sys/arch/x86/x86/bus_space.c
@@ -878,7 +878,16 @@ bus_space_barrier(bus_space_tag_t tag,
bus_space_handle_t bsh,
                  bus_size_t offset, bus_size_t len, int flags)
 {

-       /* Function call is enough to prevent reordering of loads. */
+       switch (flags) {
+       case (BUS_SPACE_BARRIER_READ|BUS_SPACE_BARRIER_WRITE):
+               x86_mfence();
+               break;
+       case BUS_SPACE_BARRIER_WRITE:
+               x86_sfence();
+               break;
+       default:
+               x86_lfence();
+       }
 }


Regards,
yamaguchi



Home | Main Index | Thread Index | Old Index