Re: [Xen-devel] Xen + VT

[Mark Williamson <Mark.Williamson@xxxxxxxxxxxx>]

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(&regs);
        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