[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.