| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Virtual passthrough I/O for Xen
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
|
|
|
| |
|
Home