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

Re: [Xen-devel] Virtual passthrough I/O for Xen

To: Sameer Niphadkar <dspn2012@xxxxxxxxx>
Subject: Re: [Xen-devel] Virtual passthrough I/O for Xen
From: Espen Skoglund <espen.skoglund@xxxxxxxxxxxxx>
Date: Mon, 23 Mar 2009 11:04:52 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 23 Mar 2009 04:06:29 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <6e28a01d0903220941l231ccccex6ec0e4754dac2356@xxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <6e28a01d0903220941l231ccccex6ec0e4754dac2356@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Given a network device, how do you intend to deal with incoming
packets?

        eSk


[Sameer Niphadkar]
> Design:
> We assume that most guest OSes already have the device drivers for a
> device.  We modify these drivers to work with our scheduler. In
> essence, before the device driver tries to start a control
> operation, such as DMA, it has to add a hypercall to ?obtain? the
> device. If the device is busy, the device driver should wait for
> it. In servicing this hypercall, the scheduler (running in the
> hypervisor) can determine whether to allow this access and maintain
> a context for the guest OS. The scheduler maintain the state
> (context) of a device (or a VF) and switch it to other guest OS when
> necessary.  We claim that the modification to the device driver is
> minimum. Another benefit is that the device driver of a guest OS may
> be blocked but other parts of the guest OS may keep running. While
> in the VPIO paper, a whole guest OS has to be blocked when the
> device is not available, because they didn?t modify the device
> driver.  The benefit of our approach when comparing with other
> driver models is that there is no central controller of the
> device. The scheduler is not a full-fledged device driver but only
> maintain the minimum context of the device. All the guest OSes are
> equal and independent. If one of the guest OS is compromised, it may
> launch DoS attack against other guest OSes but cannot steal
> information from other guest OSes.

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

<Prev in Thread] Current Thread [Next in Thread>