> 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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
shobha ranganathan
2006-Jul-19 20:41 UTC
[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. --0-1094365814-1153341688=:74465 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit <div>I wanted to understand how xenoprof handles (if at all) saving of PMC/PMDs (data related to PMU) during a context switch.</div> <div> </div> <div>I am looking at xenoprof.c and other files in oprofile code in xen-unstable/xen/...</div> <div> </div> <div>I would like to know how it interacts with hypervisor..</div> <div> </div> <div>Please let me know which files I should look at to understand hypervisor interactions.</div> <div> </div> <div>Thanks</div> <div>Shobha<BR></div><p>  <hr size=1>Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. <a href="http://us.rd.yahoo.com/mail_us/taglines/postman7/*http://us.rd.yahoo.com/evt=39666/*http://messenger.yahoo.com"> Great rates starting at 1¢/min. --0-1094365814-1153341688=:74465-- --===============0975763028=Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0975763028==--
Santos, Jose Renato G
2006-Jul-20 03:42 UTC
RE: [Xen-devel] Understanding capabilites of xenoprof
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> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel