Xen devel - Apr 2009 - VPIO device model for Xen guests

Hello,

For our research we are trying to come up with a Virtual - passthrough
model of device drivers in  PV guests. We are looking for 2 separate
implementations : 1 for transmitting and the other for receiving the
packets in the guest OS. We are relying on IOMMU to ensure isolation.

We need to add  these new hypercalls for communication between the
guest device driver and the hypervisor. The guest device drivers use
these hypercalls to read the state of the current physical device and
also request the ownership of the device. We need following
hypercalls:

HYPERVISOR_device_op, get device state. Before the device driver
accesses the device, it first issues this hypercall to check the state
of the device. The state could be “idle” or “busy”. “Idle” means no
other guest is currently using the device. “busy” means other guest is
using the device. We may use just one char or int value to denote the
state.

Note: it might be better implement using shareinfo_page of Xen. Then
the performance will be better.

HYPERVISOR_device_op, grab the device. This should be called after the
device driver checked the state of the device, and the state is
“idle”. In this case, the guest device driver issues this hypercall to
actually grab the device. If the device is “busy” and the guest does
this hypercall, the return value should indicate an error. Also, there
may be multiple guest OSes trying to grab the device at the same time,
the hypervisor should then be fair to all of them.  It may also be
possible that “HYPERVISOR_device_op, get device state” returns “idle”
but “HYPERVISOR_device_op, grab the device” fails. This happens when
multiple guest OSes compete for the same device.

Note that the hypervisor should also maintain an ownership filed for
the device and the device driver should maintain a state to indicate
if it holds the device or not. Also, the implementation details for
the above hypercalls can be re-designed for easy implementation.

We also need an upcall to let the hypervisor notify the guest device
driver when it used up all its time slice. At that time, the upcall
tells the guest device driver that it should stop using the device.
The guest device driver should then stop the device  usage as soon as
possible. The hypervisor should keep a timeout for this operation. If
a malicious driver ignores this upcall, the hypervisor should
forcibly stop the current guest OS and context switch to another guest
OS. The current guest OS may lose some data or crash. This is more
desirable than letting one guest OS keeping the device forever to
itself.

It would be great to know if there are any such resembling Hypercalls
in use ? I was going through the macro defined Hypercalls in
include/x86/x86_32/hypercall-x86_32.h
 and xen/arch/x86/platform_hypercall.c but was not sure where to
begin..any pointers would be appreciated.

thanks

regards
Sameer

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

I don''t think..my mail was received - so resending it.


---------- Forwarded message ----------
From: Sameer Niphadkar <dspn2012@gmail.com>
Date: Mon, Apr 27, 2009 at 6:01 PM
Subject: VPIO device model for Xen guests
To: xen-devel@lists.xensource.com


Hello all,

For our research we are trying to come up with a Virtual - passthrough
model of device drivers in  PV guests. We are looking for 2 separate
implementations : 1 for transmitting and the other for receiving the
packets in the guest OS. We are relying on IOMMU to ensure isolation.

We need to add  these new hypercalls for communication between the
guest device driver and the hypervisor. The guest device drivers use
these hypercalls to read the state of the current physical device and
also request the ownership of the device. We need following
hypercalls:

HYPERVISOR_device_op, get device state. Before the device driver
accesses the device, it first issues this hypercall to check the state
of the device. The state could be “idle” or “busy”. “Idle” means no
other guest is currently using the device. “busy” means other guest is
using the device. We may use just one char or int value to denote the
state.

Note: it might be better implement using shareinfo_page of Xen. Then
the performance will be better.

HYPERVISOR_device_op, grab the device. This should be called after the
device driver checked the state of the device, and the state is
“idle”. In this case, the guest device driver issues this hypercall to
actually grab the device. If the device is “busy” and the guest does
this hypercall, the return value should indicate an error. Also, there
may be multiple guest OSes trying to grab the device at the same time,
the hypervisor should then be fair to all of them.  It may also be
possible that “HYPERVISOR_device_op, get device state” returns “idle”
but “HYPERVISOR_device_op, grab the device” fails. This happens when
multiple guest OSes compete for the same device.

Note that the hypervisor should also maintain an ownership filed for
the device and the device driver should maintain a state to indicate
if it holds the device or not. Also, the implementation details for
the above hypercalls can be re-designed for easy implementation.

We also need an upcall to let the hypervisor notify the guest device
driver when it used up all its time slice. At that time, the upcall
tells the guest device driver that it should stop using the device.
The guest device driver should then stop the device  usage as soon as
possible. The hypervisor should keep a timeout for this operation. If
a malicious driver ignores this upcall, the hypervisor should
forcibly stop the current guest OS and context switch to another guest
OS. The current guest OS may lose some data or crash. This is more
desirable than letting one guest OS keeping the device forever to
itself.

It would be great to know if there are any such resembling Hypercalls
in use ? I was going through the macro defined Hypercalls in
include/x86/x86_32/hypercall-x86_32.h
 and xen/arch/x86/platform_hypercall.c but was not sure where to
begin..any pointers would be appreciated.

thanks

regards
Sameer

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