* Joerg Roedel wrote:
> I personally don't like a self-defined event-set as the only solution
> because that would probably only work with linux and perf. [...]
The 'soft-PMU' i suggested is transparent on the guest side - if you want to
enable non-Linux and legacy-Linux.
It's basically a PM
Huang Ying wrote:
> MCE registers are saved/load into/from CPUState in
> kvm_arch_save/load_regs. Because all MCE registers except for
> MCG_STATUS should be preserved, MCE registers are saved before
> kvm_arch_load_regs in kvm_arch_cpu_reset. To simulate the MCG_STATUS
> clearing upon reset, env->
* Zhang, Yanmin wrote:
> On Thu, 2010-02-25 at 17:26 +0100, Ingo Molnar wrote:
> > * Jan Kiszka wrote:
> >
> > > Jes Sorensen wrote:
> > > > Hi,
> > > >
> > > > It looks like several of us have been looking at how to use the PMU
> > > > for virtualization. Rather than continuing to have discu
On Fri, Feb 26, 2010 at 10:55:17AM +0800, Zhang, Yanmin wrote:
> On Thu, 2010-02-25 at 18:34 +0100, Joerg Roedel wrote:
> > On Thu, Feb 25, 2010 at 04:04:28PM +0100, Jes Sorensen wrote:
> >
> > > 1) Add support to perf to allow it to monitor a KVM guest from the
> > >host.
> >
> > This should
* Zhang, Yanmin wrote:
> 2) We couldn't get guest os kernel/user stack data in an easy way, so we
> might not support callchain feature of tool perf. A work around is KVM
> copies kernel stack data out, so we could at least support guest os kernel
> callchain.
If the guest is Linux, KVM can
* Joerg Roedel wrote:
> On Fri, Feb 26, 2010 at 10:55:17AM +0800, Zhang, Yanmin wrote:
> > On Thu, 2010-02-25 at 18:34 +0100, Joerg Roedel wrote:
> > > On Thu, Feb 25, 2010 at 04:04:28PM +0100, Jes Sorensen wrote:
> > >
> > > > 1) Add support to perf to allow it to monitor a KVM guest from the
On 02/26/2010 10:42 AM, Ingo Molnar wrote:
* Joerg Roedel wrote:
I personally don't like a self-defined event-set as the only solution
because that would probably only work with linux and perf. [...]
The 'soft-PMU' i suggested is transparent on the guest side - if you want to
enable
On 02/26/2010 11:01 AM, Ingo Molnar wrote:
* Zhang, Yanmin wrote:
2) We couldn't get guest os kernel/user stack data in an easy way, so we
might not support callchain feature of tool perf. A work around is KVM
copies kernel stack data out, so we could at least support guest os kernel
callc
On 02/25/2010 07:15 PM, Joerg Roedel wrote:
The algorithm to find the offset in the msrpm for a given
msr is needed at other places too. Move that logic to its
own function.
#define MAX_INST_SIZE 15
@@ -417,23 +439,22 @@ err_1:
static void set_msr_interception(u32 *msrpm, unsigned msr,
On Fri, Feb 26, 2010 at 12:20:10PM +0200, Avi Kivity wrote:
> On 02/25/2010 07:15 PM, Joerg Roedel wrote:
> >The algorithm to find the offset in the msrpm for a given
> >msr is needed at other places too. Move that logic to its
> >own function.
> >
> > #define MAX_INST_SIZE 15
> >
> >@@ -417,23 +4
On 02/25/2010 07:15 PM, Joerg Roedel wrote:
This patch optimizes the way the msrpm of the host and the
guest are merged. The old code merged the 2 msrpm pages
completly. This code needed to touch 24kb of memory for that
operation. The optimized variant this patch introduces
merges only the parts
On 02/25/2010 07:15 PM, Joerg Roedel wrote:
There is a generic function now to calculate msrpm offsets.
Use that function in nested_svm_exit_handled_msr() remove
the duplicate logic.
Hm, if the function would also calculate the mask, then it would be
useful for set_msr_interception() as w
On 02/25/2010 07:15 PM, Joerg Roedel wrote:
This patch adds the correct handling of the nested io
permission bitmap. Old behavior was to not lookup the port
in the iopm but only reinject an io intercept to the guest.
Signed-off-by: Joerg Roedel
---
arch/x86/kvm/svm.c | 25 +++
* Avi Kivity wrote:
> On 02/26/2010 11:01 AM, Ingo Molnar wrote:
> >* Zhang, Yanmin wrote:
> >
> >>2) We couldn't get guest os kernel/user stack data in an easy way, so we
> >>might not support callchain feature of tool perf. A work around is KVM
> >>copies kernel stack data out, so we could at
On Fri, Feb 26, 2010 at 11:46:34AM +0200, Avi Kivity wrote:
> On 02/26/2010 10:42 AM, Ingo Molnar wrote:
>> Note that the 'soft PMU' still sucks from a design POV as there's no generic
>> hw interface to the PMU. So there would have to be a 'soft AMD' and a 'soft
>> Intel' PMU driver at minimum.
>>
On Fri, Feb 26, 2010 at 10:17:32AM +0100, Ingo Molnar wrote:
> My suggestion, as always, would be to start very simple and very minimal:
>
> Enable 'perf kvm top' to show guest overhead. Use the exact same kernel image
> both as a host and as guest (for testing), to not have to deal with the
> s
* Avi Kivity wrote:
> Right, this will severely limit migration domains to hosts of the same
> vendor and processor generation. There is a middle ground, though, Intel
> has recently moved to define an "architectural pmu" which is not model
> specific. I don't know if AMD adopted it. [...]
* Joerg Roedel wrote:
> On Fri, Feb 26, 2010 at 11:46:34AM +0200, Avi Kivity wrote:
> > On 02/26/2010 10:42 AM, Ingo Molnar wrote:
> >> Note that the 'soft PMU' still sucks from a design POV as there's no
> >> generic
> >> hw interface to the PMU. So there would have to be a 'soft AMD' and a 's
On 02/26/2010 12:35 PM, Ingo Molnar wrote:
One additional step needed is to get symbol information from the guest, and to
integrate it into the symbol cache on the host side in ~/.debug. We already
support cross-arch symbols and 'perf archive', so the basic facilities are
there for that. So you
On 02/26/2010 12:46 PM, Ingo Molnar wrote:
Right, this will severely limit migration domains to hosts of the same
vendor and processor generation. There is a middle ground, though,
Intel has recently moved to define an "architectural pmu" which is not
model specific. I don't know if AMD adop
* Joerg Roedel wrote:
> On Fri, Feb 26, 2010 at 10:17:32AM +0100, Ingo Molnar wrote:
> > My suggestion, as always, would be to start very simple and very minimal:
> >
> > Enable 'perf kvm top' to show guest overhead. Use the exact same kernel
> > image
> > both as a host and as guest (for tes
On 02/25/10 17:26, Ingo Molnar wrote:
Given that perf can apply the PMU to individual host tasks, I don't see
fundamental problems multiplexing it between individual guests (which can
then internally multiplex it again).
In terms of how to expose it to guests, a 'soft PMU' might be a usable
app
On 02/25/10 18:34, Joerg Roedel wrote:
The biggest problem I see here is teaching the guest about the available
events. The available event sets are dependent on the processor family
(at least on AMD).
A simple approach would be shadowing the perf msrs which is a simple
thing to do. More problema
On Fri, Feb 26, 2010 at 11:46:59AM +0100, Ingo Molnar wrote:
>
> * Joerg Roedel wrote:
>
> > On Fri, Feb 26, 2010 at 11:46:34AM +0200, Avi Kivity wrote:
> > > On 02/26/2010 10:42 AM, Ingo Molnar wrote:
> > >> Note that the 'soft PMU' still sucks from a design POV as there's no
> > >> generic
>
On 02/26/2010 12:44 PM, Ingo Molnar wrote:
Far cleaner would be to expose it via hypercalls to guest OSs that are
interested in instrumentation.
It's also slower - you can give the guest direct access to the various
counters so no exits are taken when reading the counters (though perhaps
* Avi Kivity wrote:
> > Do you have (or plan) any turn-key 'access to all files of the guest' kind
> > of guest-transparent facility that could be used for such purposes?
>
> Not really. The guest and host admins are usually different people, who
> may, being admins, even actively hate each
On 02/26/2010 06:57 AM, Zachary Amsden wrote:
Anyone seeing list_add corruption running qemu-kvm with -smp 2 on
Intel hardware?
Debugging some local changes, which don't appear related. Running
module from latest git on F12.
Can you post a trace? Which list appears to be involved?
--
Do
On 02/26/10 12:06, Joerg Roedel wrote:
Isn't there a cpuid bit indicating the availability of architectural
perfmon?
Nope, the perfmon flag is a fake Linux flag, set based on the contents
on cpuid 0x0a
Jes
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a mess
* Joerg Roedel wrote:
> On Fri, Feb 26, 2010 at 11:46:59AM +0100, Ingo Molnar wrote:
> >
> > * Joerg Roedel wrote:
> >
> > > On Fri, Feb 26, 2010 at 11:46:34AM +0200, Avi Kivity wrote:
> > > > On 02/26/2010 10:42 AM, Ingo Molnar wrote:
> > > >> Note that the 'soft PMU' still sucks from a desi
* Jes Sorensen wrote:
> On 02/26/10 12:06, Joerg Roedel wrote:
>
> > Isn't there a cpuid bit indicating the availability of architectural
> > perfmon?
>
> Nope, the perfmon flag is a fake Linux flag, set based on the contents on
> cpuid 0x0a
There is a way to query the CPU for 'architectural
On 02/26/10 11:44, Ingo Molnar wrote:
Direct access to counters is not something that is a big issue. [ Given that i
sometimes can see KVM redraw the screen of a guest OS real-time i doubt this
is the biggest of performance challenges right now ;-) ]
By far the biggest instrumentation issue is:
On 02/26/10 12:24, Ingo Molnar wrote:
There is a way to query the CPU for 'architectural perfmon' though, via CPUID
alone - that is how we set the X86_FEATURE_ARCH_PERFMON shortcut. The logic
is:
if (c->cpuid_level> 9) {
unsigned eax = cpuid_eax(10);
/
* Avi Kivity wrote:
> On 02/26/2010 12:44 PM, Ingo Molnar wrote:
> >>>Far cleaner would be to expose it via hypercalls to guest OSs that are
> >>>interested in instrumentation.
> >>It's also slower - you can give the guest direct access to the various
> >>counters so no exits are taken when read
* Jes Sorensen wrote:
> On 02/26/10 11:44, Ingo Molnar wrote:
> >Direct access to counters is not something that is a big issue. [ Given that
> >i
> >sometimes can see KVM redraw the screen of a guest OS real-time i doubt this
> >is the biggest of performance challenges right now ;-) ]
> >
> >B
On 02/26/2010 01:17 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
Do you have (or plan) any turn-key 'access to all files of the guest' kind
of guest-transparent facility that could be used for such purposes?
Not really. The guest and host admins are usually different people, who
ma
On Fri, 2010-02-26 at 12:47 +0200, Avi Kivity wrote:
> Not really. The guest and host admins are usually different people, who
> may, being admins, even actively hate each other. The guest admin would
> probably regard it as a security hole. It's probably useful for the
> single-host scenario
On 02/26/2010 01:26 PM, Ingo Molnar wrote:
By far the biggest instrumentation issue is:
- availability
- usability
- flexibility
Exposing the raw hw is a step backwards in many regards.
In a way, virtualization as a whole is a step backwards. We take the nice
firesystem/timer/
On 02/26/2010 01:42 PM, Ingo Molnar wrote:
* Jes Sorensen wrote:
On 02/26/10 11:44, Ingo Molnar wrote:
Direct access to counters is not something that is a big issue. [ Given that i
sometimes can see KVM redraw the screen of a guest OS real-time i doubt this
is the biggest of perfor
On 02/26/2010 01:48 PM, Peter Zijlstra wrote:
On Fri, 2010-02-26 at 12:47 +0200, Avi Kivity wrote:
Not really. The guest and host admins are usually different people, who
may, being admins, even actively hate each other. The guest admin would
probably regard it as a security hole. It's pr
* Avi Kivity wrote:
> A native API to the host will lock out 100% of the install base now, and a
> large section of any future install base.
... which is why i suggested the soft-PMU approach.
And note that _any_ solution we offer locks out 100% of the installed base
right now, as no solutio
On 02/26/2010 02:07 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
A native API to the host will lock out 100% of the install base now, and a
large section of any future install base.
... which is why i suggested the soft-PMU approach.
Not sure I understand it completely.
Do you
On 26.02.2010, at 13:25, Joerg Roedel wrote:
> On Fri, Feb 26, 2010 at 12:28:24PM +0200, Avi Kivity wrote:
>>> +static void add_msr_offset(u32 offset)
>>> +{
>>> + u32 old;
>>> + int i;
>>> +
>>> +again:
>>> + for (i = 0; i< MSRPM_OFFSETS; ++i) {
>>> + old = msrpm_offsets[i];
>>>
When this was merged in qemu-kvm/master (commit
6249f61a891b6b003531ca4e459c3a553faa82bc) it removed Avi's compile fix when
!CONFIG_EVENTFD (db311e8619d310bd7729637b702581d3d8565049).
So current master fails to build:
CCosdep.o
cc1: warnings being treated as errors
osdep.c: In function 'qem
* Avi Kivity wrote:
> On 02/26/2010 02:07 PM, Ingo Molnar wrote:
> >* Avi Kivity wrote:
> >
> >>A native API to the host will lock out 100% of the install base now, and a
> >>large section of any future install base.
> >... which is why i suggested the soft-PMU approach.
>
> Not sure I underst
On Fri, Feb 26, 2010 at 12:28:24PM +0200, Avi Kivity wrote:
> >+static void add_msr_offset(u32 offset)
> >+{
> >+u32 old;
> >+int i;
> >+
> >+again:
> >+for (i = 0; i< MSRPM_OFFSETS; ++i) {
> >+old = msrpm_offsets[i];
> >+
> >+if (old == offset)
> >+
On 02/26/2010 02:25 PM, Joerg Roedel wrote:
On Fri, Feb 26, 2010 at 12:28:24PM +0200, Avi Kivity wrote:
+static void add_msr_offset(u32 offset)
+{
+ u32 old;
+ int i;
+
+again:
+ for (i = 0; i< MSRPM_OFFSETS; ++i) {
+ old = msrpm_offsets[i];
+
+
* Avi Kivity wrote:
> > You basically have given up control over the quality of KVM by pushing so
> > many aspects of it to user-space and letting it rot there.
>
> That's wrong on so many levels. First, nothing is rotting in userspace,
> qemu is evolving faster than kvm is. If I pushed it
On 02/26/10 12:42, Ingo Molnar wrote:
* Jes Sorensen wrote:
I have to say I disagree on that. When you run perfmon on a system, it is
normally to measure a specific application. You want to see accurate numbers
for cache misses, mul instructions or whatever else is selected.
You can still ge
On 02/26/2010 02:46 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
You basically have given up control over the quality of KVM by pushing so
many aspects of it to user-space and letting it rot there.
That's wrong on so many levels. First, nothing is rotting in userspace,
qemu is evol
On 02/26/10 13:20, Avi Kivity wrote:
On 02/26/2010 02:07 PM, Ingo Molnar wrote:
... which is why i suggested the soft-PMU approach.
Not sure I understand it completely.
Do you mean to take the model specific host pmu events, and expose them
to the guest via trap'n'emulate? In that case we may
On Fri, Feb 26, 2010 at 01:28:29PM +0100, Alexander Graf wrote:
>
> On 26.02.2010, at 13:25, Joerg Roedel wrote:
>
> > On Fri, Feb 26, 2010 at 12:28:24PM +0200, Avi Kivity wrote:
> >>> +static void add_msr_offset(u32 offset)
> >>> +{
> >>> + u32 old;
> >>> + int i;
> >>> +
> >>> +again:
> >>> + f
On 02/26/2010 02:38 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
On 02/26/2010 02:07 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
A native API to the host will lock out 100% of the install base now, and a
large section of any future install base.
... which is why
* Jes Sorensen wrote:
> On 02/26/10 12:42, Ingo Molnar wrote:
> >
> >* Jes Sorensen wrote:
> >>
> >> I have to say I disagree on that. When you run perfmon on a system, it is
> >> normally to measure a specific application. You want to see accurate
> >> numbers for cache misses, mul instructi
On 26.02.2010, at 14:04, Joerg Roedel wrote:
> On Fri, Feb 26, 2010 at 01:28:29PM +0100, Alexander Graf wrote:
>>
>> On 26.02.2010, at 13:25, Joerg Roedel wrote:
>>
>>> On Fri, Feb 26, 2010 at 12:28:24PM +0200, Avi Kivity wrote:
> +static void add_msr_offset(u32 offset)
> +{
> + u32
On 02/26/2010 03:04 PM, Joerg Roedel wrote:
I'm still not convinced on this way of doing things. If it's static,
make it static. If it's dynamic, make it dynamic. Dynamically
generating a static list just sounds plain wrong to me.
Stop. I had a static list in the first version of the pat
On 02/26/10 14:04, Avi Kivity wrote:
On 02/26/2010 02:38 PM, Ingo Molnar wrote:
Yes, something like Core2 with 2 generic events.
That would leave 2 extra generic events on Nehalem and better. (which is
really the target CPU type for any new feature we are talking about
right now.
Plus performan
* Avi Kivity wrote:
> > That was not what i suggested tho. tools/kvm/ would work plenty fine.
>
> I'll wait until we have tools/libc and tools/X. After all, they affect a
> lot more people and are concerned with a lot more kernel/user interfaces
> than kvm.
So your answer can be summed up a
* Avi Kivity wrote:
> Can you emulate the Core 2 pmu on, say, a P4? [...]
How about the Pentium? Or the i486?
As long as there's perf events support, the CPU can be supported in a soft
PMU. You can even cross-map exotic hw events if need to be - but most of the
tooling (in just about any OS)
On Fri, Feb 26, 2010 at 02:08:25PM +0100, Alexander Graf wrote:
>
> On 26.02.2010, at 14:04, Joerg Roedel wrote:
>
> > On Fri, Feb 26, 2010 at 01:28:29PM +0100, Alexander Graf wrote:
> >>
> >> On 26.02.2010, at 13:25, Joerg Roedel wrote:
> >>
> >>> On Fri, Feb 26, 2010 at 12:28:24PM +0200, Avi
On Fri, Feb 26, 2010 at 03:10:13PM +0200, Avi Kivity wrote:
> On 02/26/2010 03:04 PM, Joerg Roedel wrote:
> >
> >>I'm still not convinced on this way of doing things. If it's static,
> >>make it static. If it's dynamic, make it dynamic. Dynamically
> >>generating a static list just sounds plain wro
On 26.02.2010, at 14:21, Joerg Roedel wrote:
> On Fri, Feb 26, 2010 at 03:10:13PM +0200, Avi Kivity wrote:
>> On 02/26/2010 03:04 PM, Joerg Roedel wrote:
>>>
I'm still not convinced on this way of doing things. If it's static,
make it static. If it's dynamic, make it dynamic. Dynamical
* Jes Sorensen wrote:
> > Agree about favouring modern processors.
>
> You certainly cannot emulate the Core2 on a P4. The Core2 is Perfmon v2,
> whereas Nehalem and Atom are v3 if I remember correctly. [...]
Of course you can emulate a good portion of it, as long as there's perf
support on
On Fri, Feb 26, 2010 at 02:26:32PM +0100, Alexander Graf wrote:
>
> On 26.02.2010, at 14:21, Joerg Roedel wrote:
>
> > On Fri, Feb 26, 2010 at 03:10:13PM +0200, Avi Kivity wrote:
> >> On 02/26/2010 03:04 PM, Joerg Roedel wrote:
> >>>
> I'm still not convinced on this way of doing things. If
On 02/26/2010 03:06 PM, Ingo Molnar wrote:
Firstly, an emulated PMU was only the second-tier option i suggested. By far
the best approach is native API to the host regarding performance events and
good guest side integration.
Secondly, the PMU cannot be 'given' to the guest in the general case
On 02/26/10 14:06, Ingo Molnar wrote:
* Jes Sorensen wrote:
Well you cannot steal the PMU without collaborating with perf_event.c, but
thats quite feasible. Sharing the PMU between the guest and the host is very
costly and guarantees incorrect results in the host. Unless you completely
emulate
* Avi Kivity wrote:
> Or do you mean to define a new, kvm-specific pmu model and feed it off the
> host pmu? In this case all the guests will need to be taught about it,
> which raises the compatibility problem.
You are missing two big things wrt. compatibility here:
1) The first upgrade o
On 02/26/2010 03:27 PM, Ingo Molnar wrote:
For Linux<->Linux the sanest, tier-1 approach would be to map sys_perf_open()
on the guest side over to the host, transparently, via a paravirt driver.
Let us for the purpose of this discussion assume that we are also
interested in supporting Win
On 02/26/10 14:30, Avi Kivity wrote:
On 02/26/2010 03:06 PM, Ingo Molnar wrote:
That's precisely my point: the guest should obviously not get raw
access to
the PMU. (except where it might matter to performance, such as RDPMC)
That's doable if all counters are steerable. IIRC some counters are
On Fri, 2010-02-26 at 13:51 +0200, Avi Kivity wrote:
> It would be the other way round - the host would steal the pmu from the
> guest. Later we can try to time-slice and extrapolate, though that's
> not going to be easy.
Right, so perf already does the time slicing and interpolating thing, s
On 02/26/10 14:18, Ingo Molnar wrote:
* Avi Kivity wrote:
Can you emulate the Core 2 pmu on, say, a P4? [...]
How about the Pentium? Or the i486?
As long as there's perf events support, the CPU can be supported in a soft
PMU. You can even cross-map exotic hw events if need to be - but most
On 02/26/10 14:31, Ingo Molnar wrote:
You are missing two big things wrt. compatibility here:
1) The first upgrade overhead a one time overhead only.
2) Once a Linux guest has upgraded, it will work in the future, with _any_
future CPU - _without_ having to upgrade the guest!
Dont you
On 02/26/2010 03:31 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
Or do you mean to define a new, kvm-specific pmu model and feed it off the
host pmu? In this case all the guests will need to be taught about it,
which raises the compatibility problem.
You are missing two big things wr
* Avi Kivity wrote:
> On 02/26/2010 03:06 PM, Ingo Molnar wrote:
> >
> >>>Firstly, an emulated PMU was only the second-tier option i suggested. By
> >>>far
> >>>the best approach is native API to the host regarding performance events
> >>>and
> >>>good guest side integration.
> >>>
> >>>Second
On 02/26/2010 03:28 PM, Peter Zijlstra wrote:
On Fri, 2010-02-26 at 13:51 +0200, Avi Kivity wrote:
It would be the other way round - the host would steal the pmu from the
guest. Later we can try to time-slice and extrapolate, though that's
not going to be easy.
Right, so perf alread
On 02/26/10 14:28, Peter Zijlstra wrote:
On Fri, 2010-02-26 at 13:51 +0200, Avi Kivity wrote:
It would be the other way round - the host would steal the pmu from the
guest. Later we can try to time-slice and extrapolate, though that's
not going to be easy.
Right, so perf already does the tim
On 02/26/2010 03:44 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
On 02/26/2010 03:06 PM, Ingo Molnar wrote:
Firstly, an emulated PMU was only the second-tier option i suggested. By far
the best approach is native API to the host regarding performance events and
good guest side
On 02/26/2010 03:37 PM, Jes Sorensen wrote:
On 02/26/10 14:31, Ingo Molnar wrote:
You are missing two big things wrt. compatibility here:
1) The first upgrade overhead a one time overhead only.
2) Once a Linux guest has upgraded, it will work in the future,
with _any_
future CPU - _
On 02/26/10 14:16, Ingo Molnar wrote:
* Avi Kivity wrote:
That was not what i suggested tho. tools/kvm/ would work plenty fine.
I'll wait until we have tools/libc and tools/X. After all, they affect a
lot more people and are concerned with a lot more kernel/user interfaces
than kvm.
So y
On 02/26/2010 03:30 PM, Joerg Roedel wrote:
So the msrpm bitmap changes dynamically for each vcpu? Great, make it
fully dynamic then, changing the vcpu->arch.msrpm only from within its
vcpu context. No need for atomic ops.
The msrpm_offsets table is global. But I think I will follow Avis
* Avi Kivity wrote:
> On 02/26/2010 03:31 PM, Ingo Molnar wrote:
> >* Avi Kivity wrote:
> >
> >>Or do you mean to define a new, kvm-specific pmu model and feed it off the
> >>host pmu? In this case all the guests will need to be taught about it,
> >>which raises the compatibility problem.
> >Y
On 02/26/2010 03:16 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
That was not what i suggested tho. tools/kvm/ would work plenty fine.
I'll wait until we have tools/libc and tools/X. After all, they affect a
lot more people and are concerned with a lot more kernel/user interfaces
t
On 02/26/10 14:27, Ingo Molnar wrote:
* Jes Sorensen wrote:
You certainly cannot emulate the Core2 on a P4. The Core2 is Perfmon v2,
whereas Nehalem and Atom are v3 if I remember correctly. [...]
Of course you can emulate a good portion of it, as long as there's perf
support on the host side
Hi list,
While trying to upgrade some internal infrastructure to qemu-kvm-0.12 I
stumbled across this really weird problem that I see with current qemu-kvm git
too:
I start qemu-kvm using:
./qemu-system-x86_64 -L ../pc-bios/ -m 512 -net nic,model=virtio -net
tap,ifname=tap0,script=/bin/true -
On 02/26/2010 04:07 PM, Jes Sorensen wrote:
On 02/26/10 14:27, Ingo Molnar wrote:
* Jes Sorensen wrote:
You certainly cannot emulate the Core2 on a P4. The Core2 is Perfmon
v2,
whereas Nehalem and Atom are v3 if I remember correctly. [...]
Of course you can emulate a good portion of it, as
* Avi Kivity wrote:
> On 02/26/2010 03:44 PM, Ingo Molnar wrote:
> >* Avi Kivity wrote:
> >
> >>On 02/26/2010 03:06 PM, Ingo Molnar wrote:
> >Firstly, an emulated PMU was only the second-tier option i suggested. By
> >far
> >the best approach is native API to the host regarding per
On 02/26/2010 04:01 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
On 02/26/2010 03:31 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
Or do you mean to define a new, kvm-specific pmu model and feed it off the
host pmu? In this case all the guests will need to be taught about it
* Avi Kivity wrote:
> On 02/26/2010 03:16 PM, Ingo Molnar wrote:
> >* Avi Kivity wrote:
> >
> >>> That was not what i suggested tho. tools/kvm/ would work plenty fine.
> >>>
> >> I'll wait until we have tools/libc and tools/X. After all, they affect a
> >> lot more people and are concerned wi
On Fri, 2010-02-26 at 15:55 +0200, Avi Kivity wrote:
>
> That actually works on the Intel-only architectural pmu. I'm beginning
> to like it more and more.
Only for the arch defined events, all _7_ of them.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a mes
* Avi Kivity wrote:
> >> Certainly guests that we don't port won't be able to use this. I doubt
> >> we'll be able to make Windows work with this - the only performance tool
> >> I'm
> >> familiar with on Windows is Intel's VTune, and that's proprietary.
> >
> > Dont you see the extreme irony
On Fri, 2010-02-26 at 14:51 +0100, Jes Sorensen wrote:
>
> > Furthermore, when KVM doesn't virtualize the physical system topology,
> > some PMU features cannot even be sanely used from a vcpu.
>
> That is definitely an issue, and there is nothing we can really do about
> that. Having two guests
On Fri, 2010-02-26 at 15:30 +0200, Avi Kivity wrote:
>
> Even if there were no security considerations, if the guest can observe
> host data in the pmu, it means the pmu is inaccurate. We should expose
> guest data only in the guest pmu. That's not difficult to do, you stop
> the pmu on exit
On Fri, 2010-02-26 at 15:30 +0200, Avi Kivity wrote:
>
> Scheduling at event granularity would be a good thing. However we need
> to be able to handle the guest using the full pmu.
Does the full PMU include things like LBR, PEBS and uncore? in that
case, there is no way you're going to get tha
On 26.02.2010, at 15:12, Alexander Graf wrote:
> Hi list,
>
> While trying to upgrade some internal infrastructure to qemu-kvm-0.12 I
> stumbled across this really weird problem that I see with current qemu-kvm
> git too:
>
> I start qemu-kvm using:
>
> ./qemu-system-x86_64 -L ../pc-bios/ -m
On 02/26/2010 04:12 PM, Ingo Molnar wrote:
Again you are making an incorrect assumption: that information leakage via the
PMU only occurs while the host is running on that CPU. It does not - the PMU
can leak general system details _while the guest is running_.
You mean like bus transact
On 02/26/2010 04:27 PM, Peter Zijlstra wrote:
On Fri, 2010-02-26 at 15:55 +0200, Avi Kivity wrote:
That actually works on the Intel-only architectural pmu. I'm beginning
to like it more and more.
Only for the arch defined events, all _7_ of them.
That's 7 more than what we supp
On 02/26/2010 04:23 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
On 02/26/2010 03:16 PM, Ingo Molnar wrote:
* Avi Kivity wrote:
That was not what i suggested tho. tools/kvm/ would work plenty fine.
I'll wait until we have tools/libc and tools/X. After all, t
On Fri, 2010-02-26 at 16:54 +0200, Avi Kivity wrote:
> On 02/26/2010 04:27 PM, Peter Zijlstra wrote:
> > On Fri, 2010-02-26 at 15:55 +0200, Avi Kivity wrote:
> >
> >> That actually works on the Intel-only architectural pmu. I'm beginning
> >> to like it more and more.
> >>
> > Only for t
On 02/26/2010 05:08 PM, Peter Zijlstra wrote:
That's 7 more than what we support now, and 7 more than what we can
guarantee without it.
Again, what windows software uses only those 7? Does it pay to only have
access to those 7 or does it limit the usability to exactly the same
subset a par
On Fri, 2010-02-26 at 16:53 +0200, Avi Kivity wrote:
> > If you give a full PMU to a guest it's a whole different dimension and
> > quality
> > of information. Literally hundreds of different events about all sorts of
> > aspects of the CPU and the hardware in general.
> >
>
> Well, we filter
On Fri, 2010-02-26 at 17:11 +0200, Avi Kivity wrote:
> On 02/26/2010 05:08 PM, Peter Zijlstra wrote:
> >> That's 7 more than what we support now, and 7 more than what we can
> >> guarantee without it.
> >>
> > Again, what windows software uses only those 7? Does it pay to only have
> > access
1 - 100 of 129 matches
Mail list logo
