Why is my write to virtual memory not visible in Virtual Device Driver?

Question

I have a custom driver that I've written meant to facilitate a custom mapping of exact hardware ram memory addresses into user land. I am trying to test that common memory mmap'd as shared between two processes to the same hardware address facilitates visible memory operations that each side can see.

My code is approximately something like this:

  //placement: in a mmap callback to a file_operations facilitated
  //    character device
  //phys_addr - a variable that I will ioremap for a virtual addr
  virtaddr = ioremap(phys_addr, size);
  if (!virtaddr) {
    printk(KERN_INFO "could not remap page!");
    goto out;
  } else { 
    printk(KERN_INFO "attempting write");
    *((int *)virtaddr) = 0xdeadbeef;
    //wmb(); <--- I haven't tried this yet
  }

As it so turns out, I thought maybe the issue was the lack of a write barrier to force the cache to flush to ram. I have to boot the test on some special hardware due to OS specifics that are outside the scope of this question. I don't think that write barriers apply to main memory or ram quite like it does for device registers or device memory (ex: cache on a SSD or something). So, I haven't tested wmb, but I just wanted to get my question out there. I've searched around some as well through the Linux Device Drivers 3 book, and I've executed my code; the fragment from which I am pulling is in fact executing and I know it because I can see the printk. The driver executes the code, but then just appears to keep on going. Lastly, there's an analogous piece of code that performs on ioremap on a common piece of hardware memory, which it then tries to read from. That read doesn't contain the value that I wrote to it.

Why?

Answer 1

Can you please tell exactly what you mean by this statement "hardware ram memory addresses into user land".

What type of device you are simulating [PCIe, USB etc]

This all depends upon your CPU routing and as hardware is not connected then the translation will not cause fault instead it will send data over bus protocol which will just like fake packed generation from bus controller to device.

To verify you can check bus transactions and in case of IO port mapping you can check using signals coming from specific port address/bits.