High-Level API

High-Level API

[John D. Ramsdell]

> From: Harry Butterworth <harry@hebutterworth.freeserve.co.uk>
...
> But, whatever the low-level API, whether grant-tables or something
> which has better support for revocation and n-way communication, I
> think there needs to be a small library to implement a higher level
> API that is more convenient for driver authors to use directly.

Harry,

I curious to know what abstractions you would want to collected
together in a high-level API.  Is there a common pattern of usage that
can be easily packaged as a high-level API?  I tried the think of a
generic, but high-level API for establishing communication between
domains, which I have enclosed.  Is this the kind of API you're
talking about?  Rather than dwelling on my proposal, perhaps it would
be most interesting if you proposed an API at the same level of detail.

John

Name: advertise_endpoint

Inputs:
    domid_t buddy      // The domain with which to share information
    void (*a_handler)(domid_t buddy, void *data) // Handler invoked 
    // when a notification is received on the read port
    void *data         // Application specific data given to handlers

Outputs:
    void *write_page   // Page written in this domain, and read by the buddy
    evtchn_port_t read_port  // port used to notify the buddy that data
    // in the read page has been read.

Implementation:
    The write_page and an unbound port is allocated.  A grant ref is
    generated for the write page, and the ref and the port is
    published using XenBus.
    
Name: connect_to_endpoint

Inputs:
    domid_t buddy      // The domain with which to share information
    void (*a_handler)(domid_t buddy, void *data) // Handler invoked 
    // when a notification is received on the write port
    void *data         // Application specific data given to handlers

Outputs:
    void *read_page    // Page read in this domain, and written by the buddy
    evtchn_port_t write_port  // port used to notify that data is ready
    // for the other domain in the write page
    grant_handle_t handle    // Handle for mapped read page

Implementation:
    A grant ref and port associated with the buddy domain is obtained
    via XenBus.  The mapped page is returned as the read page, and the
    result of performing an interdomain bind is the write port.

Re: High-Level API

[Harry Butterworth]

On Wed, 2006-07-19 at 13:54 -0400, John D. Ramsdell wrote:
> > From: Harry Butterworth <harry@hebutterworth.freeserve.co.uk>
> ...
> > But, whatever the low-level API, whether grant-tables or something
> > which has better support for revocation and n-way communication, I
> > think there needs to be a small library to implement a higher level
> > API that is more convenient for driver authors to use directly.
> 
> Harry,
> 
> I curious to know what abstractions you would want to collected
> together in a high-level API.  Is there a common pattern of usage that
> can be easily packaged as a high-level API?  I tried the think of a
> generic, but high-level API for establishing communication between
> domains, which I have enclosed.  Is this the kind of API you're
> talking about?  Rather than dwelling on my proposal, perhaps it would
> be most interesting if you proposed an API at the same level of detail.

I already had a go at this...

Initial discussion:
http://lists.xensource.com/archives/html/xen-devel/2005-05/msg00154.html

Documentation and implementation and example usb driver using the API:
http://lists.xensource.com/archives/html/xen-devel/2005-12/msg00601.html

Sketchy example block driver using the API:
http://lists.xensource.com/archives/html/xen-devel/2006-01/msg00472.html

...there is more if you search in the archives.

Some random thoughts now that a bit of time has passed:

In addition to the high-performance asynchronous comms provided by
xenidc, I think there is a requirement for synchronous comms for the
pciback/front driver.  This could be implemented as something like a
synchronous invocation of the core xenidc code with polling rather than
interrupts for completions.

You'd want to reimplement the API on top of something with better
revocation than grant-tables.  There's a place where the code sets up an
interval timer to poll indefinitely waiting for the remote domain to
free up resources before the channel can be reestablished.

Use-cases like a shared framebuffer don't really fit into the kind of
channel model presented by the xenidc API.  I think this is a bit of a
special case.  VNC is a good fit of course.

The xenidc implementation is fairly tricky mainly because of the lossy,
level sensitive communication through xenbus and xenstore.

I think the xenbus API needs to be fixed in a separate effort.

> John
> 
> Name: advertise_endpoint
> 
> Inputs:
>     domid_t buddy      // The domain with which to share information
>     void (*a_handler)(domid_t buddy, void *data) // Handler invoked 
>     // when a notification is received on the read port
>     void *data         // Application specific data given to handlers
> 
> Outputs:
>     void *write_page   // Page written in this domain, and read by the buddy
>     evtchn_port_t read_port  // port used to notify the buddy that data
>     // in the read page has been read.
> 
> Implementation:
>     The write_page and an unbound port is allocated.  A grant ref is
>     generated for the write page, and the ref and the port is
>     published using XenBus.
>     
> Name: connect_to_endpoint
> 
> Inputs:
>     domid_t buddy      // The domain with which to share information
>     void (*a_handler)(domid_t buddy, void *data) // Handler invoked 
>     // when a notification is received on the write port
>     void *data         // Application specific data given to handlers
> 
> Outputs:
>     void *read_page    // Page read in this domain, and written by the buddy
>     evtchn_port_t write_port  // port used to notify that data is ready
>     // for the other domain in the write page
>     grant_handle_t handle    // Handle for mapped read page
> 
> Implementation:
>     A grant ref and port associated with the buddy domain is obtained
>     via XenBus.  The mapped page is returned as the read page, and the
>     result of performing an interdomain bind is the write port.

Your API is still a low level API.  You need to deal with arbitrary
sized bulk data transfer, concurrency, request-response coupling,
multiple data phases, channel lifecycle, resource management,
abstraction of the memory model and probably some other stuff that
doesn't immediately come to mind.

It's probably not worth reopening this discussion unless the core xen
team are interested.

Harry.

Re: High-Level API

[John D. Ramsdell]

Harry Butterworth <harry@hebutterworth.freeserve.co.uk> writes:

> > Harry,
> > 
> > ... what abstractions you would want to collected together in a
> > high-level API. 
>
> I already had a go at this...
> 
> Initial discussion:

I now see your API suggestions are quite ambitious.  All of these
messages were submitted before I read the list, which is why I didn't
know how to understand your recent comment about high-level APIs, but
I now see what your driving at.

> It's probably not worth reopening this discussion unless the core xen
> team are interested.

Agreed.

John

Understanding capabilites of xenoprof

[shobha ranganathan]

[-- Attachment #1.1: Type: text/plain, Size: 524 bytes --]

I wanted to understand how xenoprof handles (if at all) saving of PMC/PMDs (data related to PMU) during a context switch.
   
  I am looking at xenoprof.c and other files in oprofile code in xen-unstable/xen/...
   
  I would like to know how it interacts with hypervisor..
   
  Please let me know which files I should look at to understand hypervisor interactions.
   
  Thanks
  Shobha


 		
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at 1¢/min.

[-- Attachment #1.2: Type: text/html, Size: 751 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

RE: Understanding capabilites of xenoprof

[Santos, Jose Renato G]

[-- Attachment #1.1: Type: text/plain, Size: 1334 bytes --]

Shobha,
 
XenOprofile does not save/restore performance counter state on context switches.
Currently, Xenoprofile uses peformance counters for global system-wide profiling, i.e no performance counter virtualization are provided to guests today.
Support for performance counter virtualization would be nice, but as far as I know nobody is actively working on this
Renato 


________________________________

	From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of shobha ranganathan
	Sent: Wednesday, July 19, 2006 1:41 PM
	To: xen-devel@lists.xensource.com
	Subject: [Xen-devel] Understanding capabilites of xenoprof
	
	
	I wanted to understand how xenoprof handles (if at all) saving of PMC/PMDs (data related to PMU) during a context switch.
	 
	I am looking at xenoprof.c and other files in oprofile code in xen-unstable/xen/...
	 
	I would like to know how it interacts with hypervisor..
	 
	Please let me know which files I should look at to understand hypervisor interactions.
	 
	Thanks
	Shobha
	

	
________________________________

	Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. <http://us.rd.yahoo.com/mail_us/taglines/postman7/*http://us.rd.yahoo.com/evt=39666/*http://messenger.yahoo.com> 


[-- Attachment #1.2: Type: text/html, Size: 2719 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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