On 06/23/10 03:13, Zhang, Yanmin wrote:
On Tue, 2010-06-22 at 09:58 +0200, Jes Sorensen wrote:
Exposing the counters read-only would save a lot of overhead for sure.
Question is if it is safe to drop overflow support?
Not safe. One of PMU hardware design objectives is to use interrupt or NMI
On 06/22/10 03:49, Zhang, Yanmin wrote:
On Mon, 2010-06-21 at 14:45 +0300, Avi Kivity wrote:
Since the guest can use NMI to read the
counter, it should have the highest possible priority, and thus it
shouldn't see any overflow unless it configured the threshold really low.
If we drop
On Tue, 2010-06-22 at 09:14 +0200, Jes Sorensen wrote:
On 06/22/10 03:49, Zhang, Yanmin wrote:
On Mon, 2010-06-21 at 14:45 +0300, Avi Kivity wrote:
Since the guest can use NMI to read the
counter, it should have the highest possible priority, and thus it
shouldn't see any overflow
On Tue, 2010-06-22 at 15:47 +0800, Zhang, Yanmin wrote:
Besides the para virt perf interface, I'm also considering the direct
exposition
of PMU hardware to guest os.
NAK NAK NAK NAK, we've been over that, its not going to happen, full
stop!
Use MSR read/write traps and host perf to emulate
On 06/22/10 09:47, Zhang, Yanmin wrote:
On Tue, 2010-06-22 at 09:14 +0200, Jes Sorensen wrote:
On 06/22/10 03:49, Zhang, Yanmin wrote:
On Mon, 2010-06-21 at 14:45 +0300, Avi Kivity wrote:
So I think above discussion is around how to expose PMU hardware to guest
os. I will
also check this
On 06/22/10 09:55, Peter Zijlstra wrote:
On Tue, 2010-06-22 at 15:47 +0800, Zhang, Yanmin wrote:
Besides the para virt perf interface, I'm also considering the direct
exposition
of PMU hardware to guest os.
NAK NAK NAK NAK, we've been over that, its not going to happen, full
stop!
Use
On 06/22/2010 04:49 AM, Zhang, Yanmin wrote:
Is live migration necessary on pv perf support?
Yes.
Ok. With the PV perf interface, host perf saves all counter info into perf_event
structure. To support live migration, we need save all host perf_event
structure,
or at least
On Tue, 2010-06-22 at 10:00 +0200, Jes Sorensen wrote:
On 06/22/10 09:55, Peter Zijlstra wrote:
On Tue, 2010-06-22 at 15:47 +0800, Zhang, Yanmin wrote:
Besides the para virt perf interface, I'm also considering the direct
exposition
of PMU hardware to guest os.
NAK NAK NAK NAK,
On Tue, 2010-06-22 at 17:29 +0800, Zhang, Yanmin wrote:
On Tue, 2010-06-22 at 10:00 +0200, Jes Sorensen wrote:
On 06/22/10 09:55, Peter Zijlstra wrote:
On Tue, 2010-06-22 at 15:47 +0800, Zhang, Yanmin wrote:
Besides the para virt perf interface, I'm also considering the direct
On 06/22/10 11:31, Peter Zijlstra wrote:
On Tue, 2010-06-22 at 17:29 +0800, Zhang, Yanmin wrote:
On Tue, 2010-06-22 at 10:00 +0200, Jes Sorensen wrote:
On 06/22/10 09:55, Peter Zijlstra wrote:
On Tue, 2010-06-22 at 15:47 +0800, Zhang, Yanmin wrote:
Besides the para virt perf interface, I'm
On Tue, 2010-06-22 at 11:39 +0200, Jes Sorensen wrote:
On 06/22/10 11:31, Peter Zijlstra wrote:
On Tue, 2010-06-22 at 17:29 +0800, Zhang, Yanmin wrote:
On Tue, 2010-06-22 at 10:00 +0200, Jes Sorensen wrote:
On 06/22/10 09:55, Peter Zijlstra wrote:
On Tue, 2010-06-22 at 15:47 +0800, Zhang,
On 06/22/2010 12:46 PM, Peter Zijlstra wrote:
Avi's suggestion of using virtual MSRs makes a ton of sense for this
though, and it makes it possible to switch direct access on/off for the
cases where direct access is possible, and go emulated when it isn't.
/me has no clue what virtual
On Tue, 2010-06-22 at 12:53 +0300, Avi Kivity wrote:
/me has no clue what virtual MSRs are,
MSRs that are not defined by the hardware, but instead by the
hypervisor.
Uhm, but the PMU MSRs are all defined by the hardware, if you move the
PMU MSRs around nothing will work.. *confusion*
On 06/22/2010 01:02 PM, Peter Zijlstra wrote:
On Tue, 2010-06-22 at 12:53 +0300, Avi Kivity wrote:
/me has no clue what virtual MSRs are,
MSRs that are not defined by the hardware, but instead by the
hypervisor.
Uhm, but the PMU MSRs are all defined by the hardware, if
On Tue, 2010-06-22 at 13:06 +0300, Avi Kivity wrote:
You have a set of MSRs for real hardware (actually several sets)
discoverable by cpuid bits. You have another set of MSRs, using other
indexes, discoverable by more CPUID bits.
The new MSR indexes will always #GP on real hardware, but
On 06/22/2010 01:10 PM, Peter Zijlstra wrote:
On Tue, 2010-06-22 at 13:06 +0300, Avi Kivity wrote:
You have a set of MSRs for real hardware (actually several sets)
discoverable by cpuid bits. You have another set of MSRs, using other
indexes, discoverable by more CPUID bits.
The new MSR
On Tue, 2010-06-22 at 09:58 +0200, Jes Sorensen wrote:
On 06/22/10 09:47, Zhang, Yanmin wrote:
On Tue, 2010-06-22 at 09:14 +0200, Jes Sorensen wrote:
On 06/22/10 03:49, Zhang, Yanmin wrote:
On Mon, 2010-06-21 at 14:45 +0300, Avi Kivity wrote:
So I think above discussion is around how to
Here is the version 2.
ChangeLog since V1: Mostly changes based on Avi's suggestions.
1) Use a id to identify the perf_event between host and guest;
2) Changes lots of codes to deal with malicious guest os;
3) Add a perf_event number limitation per gust os instance;
On 06/21/2010 12:31 PM, Zhang, Yanmin wrote:
Here is the version 2.
ChangeLog since V1: Mostly changes based on Avi's suggestions.
1) Use a id to identify the perf_event between host and guest;
2) Changes lots of codes to deal with malicious guest os;
3) Add a perf_event
On Mon, 2010-06-21 at 14:45 +0300, Avi Kivity wrote:
On 06/21/2010 12:31 PM, Zhang, Yanmin wrote:
Here is the version 2.
ChangeLog since V1: Mostly changes based on Avi's suggestions.
1) Use a id to identify the perf_event between host and guest;
2) Changes lots of codes to deal
20 matches
Mail list logo
