WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Full virtualization and I/O

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Full virtualization and I/O
From: Thomas Heinz <thomasheinz@xxxxxxx>
Date: Tue, 21 Nov 2006 00:39:08 +0100
Delivery-date: Wed, 22 Nov 2006 07:31:43 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.5
Hi

Full virtualization is about providing multiple virtual ISA level 
environments and mapping them to a single physical one. One particular 
aspect of this mapping are I/O instructions (explicit or mmapped I/O). In 
general, there are two strategies to partition the devices, either in time 
or in space. Partitioning a device in space means that the device (or a 
part of it) is exclusively available to a single VM. Partitioning a device 
in time (or time multiplexing) means that it can be used by multiple VMs 
but only one VM may use it at any point in time.

I am trying to understand how I/O virtualization on the ISA level works if 
a device is shared between multiple VM instances. On a very high level, it 
should be as follows. First of all, the VMM has to intercept the VM's I/O 
commands (I/O instructions or load/store to dedicated memory addresses - 
let's ignore interrupts for the moment). This could be done by traps or by 
replacing the resp. instructions by VMM calls to I/O primitives. The VMM 
keeps multiple device model instances (one for each VM using the device) 
in memory. The models somehow reflect the low level I/O API of the device. 
Depending on which I/O command is issued by the VM, either the memory 
model is changed or a number of I/O instructions are executed to make the 
physical device state reflect the one represented in the memory model.

This approach brings up a number of questions. It would be great if some of 
the virtualization experts here could shed some light on them (even though 
they are not immediately related to Xen, I know):

- How do these device memory models look like? Is there a common
  (automata) theory behind or are they done ad hoc?
- What kind of strategies/algorithms are used in the merge phase, i.e. the
  phase where the virtual memory model and the physical one are
  synchronized? What kind of problems can occur in this phase?
- Are specific usage patterns used in real world implementations (e.g.
  VMWare) to simplify the virtualization (model or merge phase)?
- Do you have any interesting pointers to literature dealing with full I/O
  virtualization? In particular, how does VMWare's full virtualization
  works with respect to I/O?
- Is every device time partitionable? If not, which requirements does it
  have to meet to be time partitionable?
  -> I don't think every device is. What about a device which supports
     different modes of operation. If two VMs drive the virtual device in
     different modes, it may not be possible to constantly switch between
     them. Ok, this is pretty artificial.

Thanks a lot for your help!


Best wishes

Thomas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel