Follow Slashdot stories on Twitter


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:Can someone explain (Score 1) 95

Xen doens't trap access to real hardware (if a guest tries to access hardware it will get a kernel panic). Instead, Xen presents to the guest OSes fake devices with a custom interface designed to be efficient under Xen. So a Xen guest won't try to access your network adapter or disk controller, it will use the Xen interface to send a descriptor to the virtual device backend driver.
Privileged guests (usually the domain0 guest) are an exeption to this because they do have direct access to the real hardware (and the hypervisor doesn't do any work here, privileged domains write *directly* to the device's registers). Privileged domains also runs the virtual device backend drivers, which does the work for virtual devices in the guest OSes.
So unprivileged Xen guests don't think they have access to the real hardware, instead they use virtual devices though custom Xen drivers.
Also, another reason why you need Xen-modified kernels is virtual memory: guest OSes (privileged and non-privileged) don't have direct access to page tables, CR3 register, etc.
When they want to update a page table entry or do a context switch they have to ask the hypervisor to do it; so the VM system needs to be changed to this.

NetBSD on Xen is a port in the NetBSD terminology, the same way NetBSD/mac68k and NetBSD/sun3 are 2 different ports. The machine NetBSD/Xen runs on is different from the machine NetBSD/i386 (which should really be NetBSD/pci386 :) runs on: different MMU, different system bus.

Slashdot Top Deals

The IBM purchase of ROLM gives new meaning to the term "twisted pair". -- Howard Anderson, "Yankee Group"