| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
I have glanced through the code but not in detail...
Apologies for inevitably telling you some things you already know but this all
seems like useful stuff to have in the archive.
> 1. Wht is the device access model with XenVT and unmod Linux .
> Obviously it cannot be using the front end back end, becos there is no
> front end in unmod Linux. So how exactly is Xen still controlling
> access to devices by unmod Linux?
Xen will trap IO accesses and notify dom0 of them. A userspace IO emulator in
dom0 emulates device behaviour based on these IO accesses. The ioemu process
signals to Xen if it should inject any events (e.g. interrupts) into the
domain.
> 2. System calls: How are system calls within unmod Linux being
> serviced now? Since unmod Linux runs in ring 0 - the sys call int can
> go directly to unmod Linux itself instead of via Xen. How is it being
> done?
In fact, they go directly already. Xen allows a guest to install its own
syscall handler so that most syscalls are handled directly (Xen verifies to
make sure that the guest is not submitting malicious details here).
VT makes a distinction of "root" and "non-root" execution. Although the guest
thinks it runs in ring 0, it's also running in VT "non-root" mode - this
means it doesn't have full privileges over the machine. Only Xen will run in
"root" mode AND in ring 0, so only Xen has total control.
I imagine syscalls will continue to be handled directly, the difference being
that the guest doesn't explicitly ask Xen to install the trap handler - it
just installs it on it's virtual hardware.
I think VT-x allows the guest to deal with all its own syscalls transparently,
or for the VMM to intercept them (which might be useful for various
applications).
> 3. External interrupts: With multiple domains and with VT how exactly
> are external interrupts being demultiplexed to the different domains?
A fully virtualised guest doesn't really care about real hardware interrupts,
so you wouldn't usually want VT-x to "pass through" interrupts from the real
hardware (although I guess it could be useful for driver domains). Usually,
Xen would be entered for each "real" interrupt and would deal with it like it
does now.
Emulated devices will deliver fake interrupts to the guest by signalling to
Xen, which can then inject a fake interrupt into the virtual machine.
> 4. Task switches. How was task switching happening in XenoLinux? Now
> VT specifically mentions that Task switches are not allowed in VMX
> Non-root mode is there any change in the way Task switches are done.
I looked at the code for this bit (xen/arch/x86/vmx.c):
---
case EXIT_REASON_TASK_SWITCH:
__vmx_bug(®s);
break;
---
"How strange", I thought. Obviously, Xen/VT *does* support task switching,
really :-) One of the more surprising features of x86 is that it can
actually do task switching _in hardware_ (!). This is what the VT docs are
referring to and it's what isn't supported under Xen.
HW task switching has some limitations, so Linux (and I imagine the BSDs,
Windows) don't use it. They'll be able to switch tasks quite happily under
Xen/VT. Some smaller OSs (Syllable springs to mind) do use the h/w task
switching feature but it's not technically impossible to support.
A trap into Xen might still occur if page tables need to be switched (I'm not
so clear on this bit).
> 5. Shadow page tables: How exactly has this changed from the existing
> handling of the page tables & directories. I didnt quite understand
> the explanation in /docs/misc/VMX_changes.txt
Page tables in vanilla Xen are exposed to the guest - it *knows* it's not
running in a contiguous memory that starts at 0... Xen/VT uses "full shadow
mode" to hide this from the guest.
HTH,
Mark
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home