Slashdot stories can be listened to in audio form via an RSS feed, as read by our own robotic overlord.

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:Can someone explain (Score 1) 95

by bouyer (#14761800) Attached to: Xen Hacker Interviewed
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.

There's no future in time travel.

Working...