Then, those virtual addresses are get translated into physical addresses by Memory Management Unit (MMU).
A virtual address can only be translated into a physical memory address when that memory contents of the process are resident or mapped in.
Otherwise a (page) fault occurs, and either a new mapping is created and/or the memory contents (e.g. the required page) for that process must be retrieved from the backing store (e.g. the page file). This content retrieval is performed by the kernel using the device driver for the storage device (e.g. a HDD or SSD). Meanwhile the process scheduler will suspend the current process, and (try to) enable a ready-to-execute process to use the CPU.
We know that virtual memory allow to use some part of disk known as page file (Swap Space) as memory as well. So, virtual address is pointing to some space in memory (RAM) + page file (swap space).
Incorrect.
The virtual address (by itself) has no component or reference to the backing store.
The organization of the backing store (e.g. the page file) is under the control of the kernel of the operating system (i.e. software).
Also the memory contents of virtual memory may not even be held in the page file or swap area.
Program code that never changes does not have to be swapped out, and can be retrieved again from the program file.
Memory-mapped files would be accessed directly rather than have a duplicate in the page file or swap area.
So a virtual address by itself is insufficient information to identify its physical memory mapping, much less any backing store information.
But, How the program gets loaded from the disk which is neither in the memory nor in page file as CPU generates virtual address and that virtual address always point to some address in memory (RAM) + page file (swap space).
A program (or any file) is accessed by its filename using the filesystem interface and the underlying block device interface.
Data from peripheral device are transferred using input/output instructions/operations rather than (main) memory accesses.
The concept of I/O operations is blurred by the implementation of memory-mapped I/O, where device registers are accessed using special addresses in memory space rather than addresses in I/O (or port) space.
Device drivers are the low-level software in the kernel that handle the complexities of such devices for read and write operations.
These are fundamental digital computer architecture concepts not suited to a brief explanation in a simple Q&A format.
What that address is called.
Mass storage devices (e.g. HDD and SSD) (aka block devices) are accessed at the device level using LBA (Logical Block Address) (aka sector numbers). Each LBA references a Logical Block of fixed-size data, typically 512 bytes worth.
Initially I used to think that logical address/virtual address is the address that point to physical memory location in hard disk.
Incorrect.
Mass storage devices (e.g. HDD and SSD) are accessed at the device level using LBA (Logical Block Address).
At a higher level, the filesystem references the contents of files using the addresses of the filesystem allocation unit (e.g. cluster numbers). The filesystem provides organization by referencing files by filename and directories.
At an even higher level, volume or drive management handles which partitions and filesystems are accessible.
There is no fixed relationship or connection between LBAs and virtual memory addresses.
Any relationship between the contents of the backing store (e.g. page file) and virtual memory would be under control of the kernel using process information and information such as a page table.
Note that most implementations of modern virtual memory use fixed-size pages, but there are other schemes possible.
