[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v12 for-xen-4.5 16/20] x86/VPMU: Handle PMU interrupts for PV guests
>>> On 01.10.14 at 20:06, <boris.ostrovsky@xxxxxxxxxx> wrote: > On 10/01/2014 10:26 AM, Jan Beulich wrote: >> >>>>>> Looking at the separation of hypervisor vs guest context to report >>>>>> again >>>>>> >>>>>> /* Non-privileged domains are always in XENPMU_MODE_SELF >>>>>> mode > */ >>>>>> if ( (vpmu_mode & XENPMU_MODE_SELF) || >>>>>> (!is_hardware_domain(sampled->domain) && >>>>>> !is_idle_vcpu(sampled)) ) >>>>>> cur_regs = guest_cpu_user_regs(); >>>>>> else >>>>>> cur_regs = regs; >>>>>> >>>>>> I now additionally wonder why the condition here isn't just the SELF >>>>>> check: If the interrupt happened while in the hypervisor, why would >>>>>> you override this unconditionally to report a guest sample instead? >>>>>> Shouldn't the profiling domain tell you what it wants in that case >>>>>> (global vs guest local view)? >>>>> The second part of the check (!is_hardware_domain(sampled->domain) && >>>>> !is_idle_vcpu(sampled)) is to prevent sending hypervisor sample to a >>>>> non-privileged guest. vpmu_mode may be, for example, XENPMU_MODE_HV but >>>>> that only means that dom0 can get hypervisor samples. >>>> Right, but that's not what the code above does: Instead of sending >>>> the hypervisor sample to Dom0 it converts it to a guest mode one. >>> Oh, I see --- when we get interrupted while in a non-privileged guest's >>> context (but in hypervisor) I send guest's registers, not Xen's. >>> >>> I think just SELF check is not sufficient though, we need to make sure >>> that we are not sending hypervisor sample to non-dom0. So >>> if ( (vpmu_mode & XENPMU_MODE_SELF) || >>> !is_hardware_domain(sampling->domain) ) >> Actually I think instead the determination of sampling needs to >> depend on the register context rather than solely on the current >> domain's ID. > > Not sure I follow this --- we do need to take domainID into account to > avoid sending non-dom0 a hypervisor sample. > > Or are you saying that what to send depends on both RIP and domainID?, Yes - that's what I'm trying to say. Or, as said above, make the determination of "sampling" dependent on register state. And in the end, considering that a model where there's both a local and a global profiler active, one sample referring to hypervisor context could easily result in two events: One (with the hypervisor register state) to the global profiled, and a second (with the surrounding guest register state) to the guest one. But iiuc your current implementation doesn't allow that (yet). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |