MIPS Virtualization: VCPU Address Map
Xvisor sees and works on the actual address map as defined by the MIPS architecure. But for the virtual CPUs (VCPUs) the address space is different. The VCPU running the guest OS sees the KSEG0 (Mapped cached region) starting from 0x00000000. This is where the RAM for the VCPU is mapped. When VCPU is in Kernel Mode or its EXL bit is set, the 2GB region starting from 0x00000000 pretends to be the region enclosed between addresses 0x80000000 - 0xFFFFFFFF on an actual MIPS CPU. When not running in kernel mode, this 2GB region is the regular USEG0.
When a VCPU starts, its EXL bit is set and its essentially running in Kernel mode. So USEG0 of CPU is presented as usual kernel mode segments by the hypervisor. Since in this mode, 512 MB region starting at 0x20000000 becomes KSEG1 (mapped, uncached), the VCPU starts running at virtual address 0x3FC00000 (i.e. it becomes the start_pc of VCPU).This is the region marked as "ROM" region under guest in DTS file. The physical address mapped to this virtual address can be a pointing to a partition in NOR/Boot Flash or it can be a regular memory. A bootloader typically U-Boot is supposed to be present at this address. The important thing go note here is that, since this u-boot will be runnign in guest mode, it can't be linked at regular boot address i.e. 0xBFC00000. Rather it must be linked at 0x3FC00000. Since this is the new virtual address where the VCPU will start executing. This U-boot will also be suitably modified so that it expects the RAM's physical address in one of the parameter registers (a0, a1, a2, a4). Also, this modified u-boot shouldn't try to initialize DRAM. It can though initialize a uart and other stuff. This U-Boot will then load the guest operating system.
The point of making USEG0 appear as regular KSEG regions, when VCPU's EXL bit is set, is that we should be able to boot VCPU's like a regular MIPS CPUs and do major dirty work in the boot code. Also, needless to say, this make the picture more comprehensible.