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