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/
Home Products Support Community News


Re: [Xen-devel] Xenoprof in an HVM domain

On Friday 21 April 2006 15:11, Steve Dobbelstein wrote:
> I'm looking into getting Xenoprof to tun in an HVM domain, since we will
> eventually need a profiler for HVM domains to track down areas of poor
> performance.  (HVMs have poor performance? :) )  Being relatively new to
> OProfile, Xenoprof, and Xen internals, I would appreciate any pointers,
> tips, and comments on how to work the implementation.  I see three basic
> areas of work.
> 1. Implement hypercalls in HVM domains.  This has been done by Steve
> Ofsthun of Virtual Iron who contributed his patches to the xen-devel list
> recently.  (Thanks, Steve.)
> 2. Implement the shared buffer that conveys profile events from the
> hypervisor to the domain.  From my initial crawl through the Xenoprof code
> (see for example linux-2.6-xen-sparse/arch/i386/oprofile/xenoprof.c) it
> appears that its setup of the shared buffer via hypercalls and page table
> updates should work in an HVM domain.  Correct me if I'm wrong.
> 3. Implement an interrupt mechanism for the hypervisor to signal the domain
> that it has more data in the shared buffer.  Xenoprof currently sets up an
> event channel for this.  In my initial hack of the code I discovered that
> the event channel used by Xenoprof conflicts with the 8259 support in the
> HVM kernel.  Since I use the serial interface to the HVM domain, I am
> hesitant to remove the 8259 support in my HVM kernel.  It appears that I
> need to either get an event channel to work through qemu, preserving the
> 8259 functionality, or change Xenoprof in the hypervisor to instruct qemu
> to issue an interrupt to the domain and change Xenoprof in the domain to
> run off an interrupt instead of an event channel.  Or maybe I don't know
> what I'm talking about and need to be enlightened by those who know better
> what the issues are.
> Any advice is appreciated.
> Thanks,
> Steve D.

I guess my question on this approach is whether or not it would still apply to 
an unmodified guest.   Were you thinking of putting all of this interface 
into a loadable kernel module for Linux (e. g. into the oprofile module)?

In some sense, I would like it better if I could just run an unmodified 
oprofile in an HVM domain (after all, it's supposed to be fully virtualized, 
right?).    But I could live with a situation where I run a modified oprofile 
under an unmodified HVM guest, with the exception that that guest allows one 
to load an HVM capable version of the oprofile driver.  [Unless the modified 
oprofile and module also work in a native environment, keeping track of these 
differences could be a headache for production environments that are 
sometimes run virtual and sometimes run native, though.]  This assumes, of 
course, that one can figure out how to virtualize the performance counters, 
and then the hypervisor would have to sort out conflicts, etc, between 
domains that wanted to use the performance counters (perhaps these would be a 
resource the hypervisor could dynamically allocate to a domain, by, for 
example, some kind of "xm" command).    

Or, I suppose xenoprof could be extended to allow the HVM domain to be a 
"controlling" domain in the xenoprof sense.

Comments, flames, discussion etc?

Ray Bryant
AMD Performance Labs                   Austin, Tx
512-602-0038 (o)                 512-507-7807 (c)

Xen-devel mailing list

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