OK, I understand. Well, in general then, taking the view that the virtual memory manager (VMM) is a separate device from the CPU, *ALL* addresses without exception in the CPU are, from the CPU's viewpoint, physical addresses not virtual. If the CPU requests data from location 0x12345678, then as far as the CPU is concerned, what comes back is at memory location 0x12345678 and that's the end of that.
Virtual memory then is something that happens separately from the CPU and in effect the CPU knows nothing about it. The VMM takes the CPU's physical address 0x12345678, *reinterprets* that as a virtual address, looks up where that would be in its page table, so let's say it has a page size of 64K then the address of the page would be 0x12340000 and the offset into that page is 0x5678.
So if the VMM page table links the virtual page at 0x12340000 to actual physical RAM at 0x44440000, then the VMM translates the CPU request for 0x12345678 to a request for 0x44445678 and returns the byte at 0x44445678 to the CPU, without letting it know anything about the change of address.
So this is the strength of the VMM design. No change in the CPU design is necessary, EXCEPT that it must be able to handle a page fault when it happens. That is where the CPU accesses memory that the VMM knows is not in physical RAM but swapped out to hard disk, and that can take a relatively long time to return the data as it must be loaded in from disk before the relevant value can be returned.
Relating this to, say, a Windows machine then. In Windows every process operates within its own 4GB address space. What's that? You've got 32 processes, but only 2GB of RAM? Well that's where the VMM steps in. Most of each of those 4GB address spaces will be unused; have a look in Task Manager, Processes tab, enable columns Mem Usage and VM Size, for example my browser (Firefox) has a Mem Usage of 129000K and a VM Size of 115000K, that's a total of 244MB, but I've got 4GB RAM and another 2GB or so swap space, so that's no problem. The VMM will retain lists of process pages and their corresponding addresses in RAM and in swap, so whenever something addresses memory, that will go to the VMM to be translated into a physical address and maybe a page fault will occur.
Mem Usage is what's in physical RAM, and VM Size is what's on the hard disk in the swap space.
Enable the column Page Faults in Task Manager and that will show you how many page faults each process has generated. If you're getting loads of page faults, that's a clear indication that you haven't got enough RAM on your system and need to increase it, or do less with the machine. Also have a look at the Performance tab; that shows PF Usage. PF is page file, another word for swap space, which is the disk space used as extra RAM. If that's high that's an indication that your page file is too small and needs extending.
The VMM is usually a separate chip from the CPU, even in modern PCs. Have a look at the Wiki article http://en.wikipedia.org/wiki/Motherboard
and scroll down to the diagram on the right that shows the CPU and two bridges, the Northbridge and Southbridge. The Northbridge is the VMM. So the FSB (front side bus) takes physical addresses from the CPU, which are reinterpreted as virtual addresses by the VMM, and the Memory bus takes physical addresses from the VMM. In that diagram, the CPU knows nothing about virtual memory; it just thinks it's accessing physical memory and the VMM is what implements the virtualisation.