Xen & VT

Xen & VT

[Deepak Manohar]

Hi all,

 I did see some previous threads regd Xen & VT. But cudnt find detailed answers.

So here is alist of questions:

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?

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?

3. External interrupts: With multiple domains and with VT how exactly
are external interrupts being demultiplexed to the different domains?

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.

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


thanks.
Deepak


-------------------------------------------------------
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 + VT

[Deepak Manohar]

Hi all,

I did see some previous threads regd Xen & VT. But cudnt find detailed answers.

So here is alist of questions:

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?

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?

3. External interrupts: With multiple domains and with VT how exactly
are external interrupts being demultiplexed to the different domains?

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.

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

thanks.
Deepak


-------------------------------------------------------
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

Re: Xen + VT

[Mark Williamson]

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