Paolo Bonzini writes:
> On 19/05/2015 16:25, Zhang, Yang Z wrote:
>> Paolo Bonzini wrote on 2015-04-30:
>>> This patch series introduces system management mode support.
>>
>> Just curious what's motivation to add vSMM supporting? Is there any
>> usage case inside guest requires SMM? Thanks.
>
>
> If there's active LBR users out there, we should refuse to enable PT and
> vice versa.
This doesn't work, e.g. hardware debuggers can take over at any time.
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body
On Wed, Jul 02, 2014 at 11:14:14AM -0700, kan.li...@intel.com wrote:
> From: Kan Liang
>
> If RTIT_CTL.TraceEn=1, any attempt to read or write the LBR or LER MSRs,
> including LBR_TOS, will result in a #GP.
> Since Intel PT can be enabled/disabled at runtime, LBR MSRs have to be
> protected by
> Signed-off-by: Andi Kleen
I did not contribute to this patch, so please remove that SOB.
> Signed-off-by: Kan Liang
> struct extra_reg *extra_regs;
> unsigned int er_flags;
> + boolextra_msr_access; /* EXTRA REG MSR can be
> acc
> > So it we take from it that translation should be present the same goes for
> > accessed and dirty. If Andi can clarify this within Intel it would be great.
>
> Andi?
There were some problems on really old CPUs with non dirty/accessed pages
(P4 generation) with PEBS. But PEBS virtualization is
Peter Zijlstra writes:
>
> So I really hate this patch, it makes the code hideous. Also, its a
> death by a thousand cuts adding endless branches in this code.
FWIW compared to the cost of a RDMSR (which is a very complex operation
for the CPU) the cost of a predicted branch is nearly in the noi
> First, it's not sufficient to pin the debug store area, you also
> have to pin the guest page tables that are used to map the debug
> store. But even if you do that, as soon as the guest fork()s, it
> will create a new pgd which the host will be free to swap out. The
> processor can then attemp
Andi Kleen writes:
>>
>>> Signed-off-by: Kan Liang
>>
>> And here I thought that Andi was of the opinion that if you set CPUID to
>> indicate a particular CPU you had better also handle all its MSRs.
>
> Yes, philosophically that would be the right w
> Userspace then can read/write these MSRs, and add them to the migration
> stream. QEMU has code for that.
Thanks. The PEBS setup always redoes its state, can be arbitarily often redone.
So the only change needed would be to add the MSRs to some list in qemu?
-Andi
--
a...@linux.intel.com --
> >+ * Failure to instantiate pages will abort guest entry.
> >+ *
> >+ * Page frames should be pinned with get_page in advance.
> >+ *
> >+ * Pinning is not guaranteed while executing as L2 guest.
>
> Does this undermine security?
It should not. In the worst case it'll randomly lose PEBS records
On Wed, Jun 18, 2014 at 08:12:03PM -0300, mtosa...@redhat.com wrote:
> Required by PEBS support as discussed at
>
> Subject: [patch 0/5] Implement PEBS virtualization for Silvermont
> Message-Id: <1401412327-14810-1-git-send-email-a...@firstfloor.org>
Thanks marcelo. I'll give it a stress test h
Peter Zijlstra writes:
>
> This order indicates Andi is the author; but there's no corresponding
> From.
I wrote an early version of the patch, but Kan took it over and extended
it. So both are authors.
BTW Kan you may want to use git send-email to get standard format.
>
>> Signed-off-by: K
On Tue, Jun 10, 2014 at 03:04:48PM -0300, Marcelo Tosatti wrote:
> On Thu, May 29, 2014 at 06:12:07PM -0700, Andi Kleen wrote:
> > {
> > struct kvm_pmu *pmu = &vcpu->arch.pmu;
> > @@ -407,6 +551,20 @@ int kvm_pmu_set_msr(struct kvm_vcpu *vcpu, st
> It seems to me that with this patch, there is no way to expose a
> PMU-without-PEBS to the guest if the host has PEBS.
If you clear the CPUIDs then noone would ilikely access it.
But fair enough, I'll add extra checks for CPUID.
> It would be a bigger concern if we expected virtual PMU migrati
BTW I found some more problems in the v1 version.
> > > With EPT it is less likely to happen (but still possible IIRC depending
> > > on memory
> > > pressure and how much memory shadow paging code is allowed to use),
> > > without EPT
> > > it will happen for sure.
> >
> > Don't care about th
On Fri, May 30, 2014 at 09:34:39AM +0200, Peter Zijlstra wrote:
> On Thu, May 29, 2014 at 06:12:06PM -0700, Andi Kleen wrote:
>
> > Note: in very rare cases with exotic events this may lead to spurious PMIs
> > in the guest.
>
> Qualify that statement so that if someone
> > To avoid any problems with guest pages being swapped by the host we
> > pin the pages when the PEBS buffer is setup, by intercepting
> > that MSR.
> It will avoid guest page to be swapped, but shadow paging code may still drop
> shadow PT pages that build a mapping from DS virtual address to th
On Fri, May 30, 2014 at 09:31:53AM +0200, Peter Zijlstra wrote:
> On Thu, May 29, 2014 at 06:12:05PM -0700, Andi Kleen wrote:
> > From: Andi Kleen
> >
> > Currently perf unconditionally disables PEBS for guest.
> >
> > Now that we have the infrastructure in pl
From: Andi Kleen
With PEBS virtualization the PEBS record gets delivered to the guest,
but the host sees the PMI. This would normally result in a spurious
PEBS PMI that is ignored. But we need to inject the PMI into the guest,
so that the guest PMI handler can handle the PEBS record.
Check for
From: Andi Kleen
Currently perf unconditionally disables PEBS for guest.
Now that we have the infrastructure in place to handle
it we can allow it for KVM owned guest events. For
the perf needs to know that a event is owned by
a guest. Add a new state bit in the perf_event for that.
The bit is
PEBS is very useful (e.g. enabling the more cycles:pp event or
memory profiling) Unfortunately it didn't work in virtualization,
which is becoming more and more common.
This patch kit implements simple PEBS virtualization for KVM on Silvermont
CPUs. Silvermont does not have the leak problems that
From: Andi Kleen
PEBS (Precise Event Bases Sampling) profiling is very powerful,
allowing improved sampling precision and much additional information,
like address or TSX abort profiling. cycles:p and :pp uses PEBS.
This patch enables PEBS profiling in KVM guests.
PEBS writes profiling records
From: Andi Kleen
To avoid various problems (like leaking counters) the PEBS
virtualization needs white listing per CPU model. Add state to the
x86_pmu for this and enable it for Silvermont.
Silvermont is currently the only CPU where it is safe
to virtualize PEBS, as it doesn't leak PEBS
kvm_rebooting is referenced from assembler code, thus
needs to be visible.
Cc: g...@redhat.com
Cc: pbonz...@redhat.com
Cc: kvm@vger.kernel.org
Signed-off-by: Andi Kleen
---
virt/kvm/kvm_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm
From: Andi Kleen
kvm_rebooting is referenced from assembler code, thus
needs to be visible.
Cc: g...@redhat.com
Cc: pbonz...@redhat.com
Cc: kvm@vger.kernel.org
Signed-off-by: Andi Kleen
---
virt/kvm/kvm_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/virt/kvm
>
> Should this go into 3.11 too? Or it never worked?
It's ok to keep it for .12. It was broken since it was merged,
but normal builds don't trigger the problem.
-andi
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More ma
> > static void kvm_io_bus_destroy(struct kvm_io_bus *bus);
> >
> >-bool kvm_rebooting;
> >+__visible bool kvm_rebooting;
> > EXPORT_SYMBOL_GPL(kvm_rebooting);
>
> How many of these are there kernel wide?
Not very many (at least on x86 allyes) <~10.
Also most users are not exported.
Probably n
From: Andi Kleen
kvm_rebooting is referenced from assembler code, thus
needs to be visible.
Signed-off-by: Andi Kleen
---
virt/kvm/kvm_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 1580dd4..eff6abd 100644
--- a/virt
From: Andi Kleen
[KVM maintainers:
The underlying support for this is in perf/core now. So please merge
this patch into the KVM tree.]
This is not arch perfmon, but older CPUs will just ignore it. This makes
it possible to do at least some TSX measurements from a KVM guest
v2: Various fixes to
On Sat, Jun 01, 2013 at 01:28:00PM -0700, Jeremy Fitzhardinge wrote:
> On 06/01/2013 01:14 PM, Andi Kleen wrote:
> > FWIW I use the paravirt spinlock ops for adding lock elision
> > to the spinlocks.
>
> Does lock elision still use the ticketlock algorithm/structure, or are
FWIW I use the paravirt spinlock ops for adding lock elision
to the spinlocks.
This needs to be done at the top level (so the level you're removing)
However I don't like the pv mechanism very much and would
be fine with using an static key hook in the main path
like I do for all the other lock
Rik van Riel writes:
>
> If we always incremented the ticket number by 2 (instead of 1), then
> we could use the lower bit of the ticket number as the spinlock.
Spinning on a single bit is very inefficient, as you need to do
try lock in a loop which is very unfriendly to the MESI state protocol.
On Thu, Sep 13, 2012 at 11:27:43AM +0300, Avi Kivity wrote:
> On 09/12/2012 10:17 PM, Andi Kleen wrote:
> > On Wed, Sep 12, 2012 at 05:50:41PM +0300, Avi Kivity wrote:
> >> vmx.c has an lto-unfriendly bit, fix it up.
> >>
> >> While there, clean up ou
s for me in my LTO build, thanks Avi.
I cannot guarantee I always hit the unit splitting case, but it looks
good so far.
I replaced my patches with yours.
Acked-by: Andi Kleen
-Andi
--
a...@linux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe
On Sun, Aug 19, 2012 at 06:12:57PM +0300, Avi Kivity wrote:
> On 08/19/2012 06:09 PM, Andi Kleen wrote:
> >> The reason we use a local label is so that we the function isn't split
> >> into two from the profiler's point of view. See cd2276a795b013d1.
> >
&g
> The reason we use a local label is so that we the function isn't split
> into two from the profiler's point of view. See cd2276a795b013d1.
Hmm that commit message is not very enlightening.
The goal was to force a compiler error?
With LTO there is no way to force two functions be in the same a
On Sat, Mar 31, 2012 at 01:04:41AM +0200, Thomas "Kubys" Gleixner wrote:
> On Sat, 31 Mar 2012, Andi Kleen wrote:
>
> > > So if a guest exits due to an external event it's easy to inspect the
> > > state of that guest and avoid to schedule away when it w
> So if a guest exits due to an external event it's easy to inspect the
> state of that guest and avoid to schedule away when it was interrupted
> in a spinlock held section. That guest/host shared state needs to be
On a large system under high contention sleeping can perform surprisingly
well. pt
On Wed, Sep 14, 2011 at 10:26:21PM +0300, Avi Kivity wrote:
> On 09/14/2011 08:28 PM, Andi Kleen wrote:
> >> If an NMI hits in an interrupt handler, or in the "after hlt" section
> >> before the write-to-last-nmi-rip, then we'll see that %rip has changed.
>
> If an NMI hits in an interrupt handler, or in the "after hlt" section
> before the write-to-last-nmi-rip, then we'll see that %rip has changed.
> If it hits after the write-to-last-nmi-rip instruction (or in the hlt
> itself), then we'll also see that %rip has changed, due to the effect of
>
On Wed, Sep 14, 2011 at 10:00:07AM +0300, Avi Kivity wrote:
> On 09/13/2011 10:21 PM, Don Zickus wrote:
> >Or are you saying an NMI in an idle system will have the same %rip thus
> >falsely detecting a back-to-back NMI?
> >
> >
>
> That's easy to avoid - insert an instruction zeroing the last nmi_
On Tue, Sep 13, 2011 at 04:53:18PM -0400, Don Zickus wrote:
> On Tue, Sep 13, 2011 at 09:58:38PM +0200, Andi Kleen wrote:
> > > Or are you saying an NMI in an idle system will have the same %rip thus
> > > falsely detecting a back-to-back NMI?
> >
> > Yup.
>
&
> Or are you saying an NMI in an idle system will have the same %rip thus
> falsely detecting a back-to-back NMI?
Yup.
Another problem is very long running instructions, like WBINVD and some others.
If there's a high frequency NMI it may well hit multiple times in a single
instance.
-Andi
--
> So I got around to implementing this and it seems to work great. The back
> to back NMIs are detected properly using the %rip and that info is passed to
> the NMI notifier. That info is used to determine if only the first
> handler to report 'handled' is executed or _all_ the handlers are
> exe
> But, erm, does that even make sense? I'm assuming the NMI reason port
> tells the CPU why it got an NMI. If multiple CPUs can get NMIs and
> there's only a single reason port, then doesn't that mean that either 1)
> they all got the NMI for the same reason, or 2) having a single port is
> inhe
>> Ok it looks like the 32bit kernel only handles 1/2/4. Maybe that
>> was the problem if you ran on 32bit.
>
> I'm happy with a slower copy_from_user() for that particular case.
It wouldn't be hard to fix.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of
> Do you think the following case would not differ so much
> from (1' 2') ?
>
> walk_addr_generic() ---1''
> copy_from_user() ---2''
Yes it should be the same and is cleaner.
If you do a make .../foo.i and look at the code coming out of the
preprocessor you'll see it
> Only I can guess for that reason is the reduction of some function calls
> by inlining some functions.
Yes once at a time cfu was inline too and just checked for the right
sizes and the used g*u, but it got lost in the "icache over everything else"
mania which is unfortunately en vogue for quit
Avi Kivity writes:
>
> Good optimization. copy_from_user() really isn't optimized for short
> buffers, I expect much of the improvement comes from that.
Actually it is equivalent to get_user for the lenghts supported by
get_user, assuming you pass in a constant length. You probably do not.
-And
Avi Kivity writes:
>
> With EPT or NPT you cannot detect if a page is read only.
Why not? You can always walk the page tables manually again.
> Furthermore, at least Linux (without highmem) maps all of memory with
> a read/write mapping in addition to the per-process mapping, so no
> page is rea
On Fri, Feb 11, 2011 at 02:29:40PM +0800, Lai Jiangshan wrote:
> The changelog of 104f226 said "adds the __noclone attribute",
> but it was missing in its patch. I think it is still needed.
Looks good. Thanks.
Acked-by: Andi Kleen
-Andi
--
To unsubscribe from this lis
> > Also longer term we'll get compilers that can do cross-file inlining
> > for optimized builds.
>
> Which we'll probably need to turn off all over the place :(
Why?
>
> > So please better avoid these kinds of micro optimizations unless
> > it's a really really extremly speed critical path.
I personally would consider it cleaner to have clearly
defined wrappers instead of complicted flags in the caller.
> The number of args to these functions is getting nutty - you'll
> probably find that it is beneficial to inline these wrapepr functions, if
> the number of callsites is small.
Real
> Can't you free and reallocate all guest memory instead, on reboot, if
> there's a hwpoisoned page? Then you don't need this interface.
I think that would be more efficient. You can potentially save a lot
of memory if the new guest doesn't need as much as the old one.
-Andi
--
To unsubscribe
On 11/18/2010 3:32 PM, Avi Kivity wrote:
On 11/18/2010 03:48 PM, Andi Kleen wrote:
On 11/18/2010 1:17 PM, Avi Kivity wrote:
cea15c2 ("KVM: Move KVM context switch into own function") split
vmx_vcpu_run()
to prevent multiple copies of the context switch from being
generated (causin
On 11/18/2010 1:17 PM, Avi Kivity wrote:
cea15c2 ("KVM: Move KVM context switch into own function") split vmx_vcpu_run()
to prevent multiple copies of the context switch from being generated (causing
problems due to a label). This patch folds them back together again and adds
the __noclone attri
> The issue of d) is that there are multiple ways to inject MCE. Now one
> software based, one APEI based, and maybe some others in the future.
> They all use different interfaces. And as debug interface, there are not
> considered kernel ABI too (some are in debugfs). So I think it is better
> to
On Wed, Nov 10, 2010 at 07:47:11PM +0200, Avi Kivity wrote:
> On 11/10/2010 07:44 PM, Andi Kleen wrote:
> >> Doing it in userspace in easier, since we can replace the vma for
> >> that section (and avoid mixed 4k/2M pages in hugetlbfs).
> >
> >You can't do t
> Doing it in userspace in easier, since we can replace the vma for
> that section (and avoid mixed 4k/2M pages in hugetlbfs).
You can't do that today, there's no way currently to access the non corrupted
portion of the 2MB page. Once it's poisoned it's all gone.
-Andi
--
a...@linux.intel.com --
> We need host kernel to break down the 2M huge page into 4k pages. Then
> send SIGBUS to QEMU with the poisoned 4k page. Because host kernel will
> poison the whole 2M virtual address space otherwise, and other 4k pages
> inside the 2M page can not used accessed in guest (will trigger SIGBUS
> and
> That is an issue too, as 3.x does a lot fewer optimizations than 4.x.
Well to be fair the default -Os build disables most of the fancy stuff
(and the resulting code is often terrible)
I guess it doesn't matter too much, at least not with the
CONFIG_CC_OPTIMIZE_SIZE default.
-Andi
--
a...@l
> Not unless they are actively known to break. People get huffy about it
Well they do -- i just found out.
> because even if it is known to have problems it doesn't break *their*
> particular configuration. I'm getting to be of the opinion that people
> who compile modern kernels with ancient c
> We have said 3.4 minimum for x86 for a long time now, and have an RFC
Ok makes sense. I thought it was still at 3.3. I should retire
this 3.3 fossil anyways, it's really only for old compat testing.
I don't remember seeing a warning -- aren't there supposed to be warnings
for unsupported compil
On Wed, Oct 20, 2010 at 06:12:11PM +0200, Avi Kivity wrote:
> On 10/20/2010 05:56 PM, Andi Kleen wrote:
> >From: Andi Kleen
> >
> >gcc 4.5 with some special options is able to duplicate the VMX
> >context switch asm in vmx_vcpu_run(). This results in a compile erro
From: Andi Kleen
gcc 4.5 with some special options is able to duplicate the VMX
context switch asm in vmx_vcpu_run(). This results in a compile error
because the inline asm sequence uses an on local label. The non local
label is needed because other code wants to set up the return address.
This
Anthony Liguori writes:
>
> If we extended integrated -mem-path with -numa such that a different
> path could be used with each numa node (and we let an explicit file be
> specified instead of just a directory), then if I understand
> correctly, we could use numactl without any specific integratio
> The point is about hotplug CPUs. Any hotplugged CPU will not have a
> perfectly synchronized TSC, ever, even on a single socket, single crystal
> board.
hotplug was in the next section, not in this.
Besides most systems do not support hotplug CPUs.
-Andi
--
To unsubscribe from this list: se
Zachary Amsden writes:
I think listing all the obscure bits in the PIT was an attempt to
weed out the weak and weary readers early, right?
> +this as well. Several hardware limitations make the problem worse - if it is
> +not possible to write the full 32-bits of the TSC, it may be impossible
> The page is fine, the page tables are not. Another task can munmap() the
> thing while is_hwpoison_address() is running.
Ok that boils down to me not seeing that source.
If it accesses the page tables yes then it's racy. But whoever
looked up the page tables in the first place should have
re
On Tue, Jun 15, 2010 at 02:22:06PM +0300, Avi Kivity wrote:
> Too much duplication. How about putting the tail end of the function in a
> common helper (with an inatomic flag)?
>
> btw, is_hwpoison_address() is racy. While it looks up the address, some
> other task can unmap the page tables und
Real bug fix.
When the user passed in a NULL mask pass this on from the ioctl
handler.
Found by gcc 4.6's new warnings.
Cc: a...@redhat.com
Cc: kvm@vger.kernel.org
Signed-off-by: Andi Kleen
---
virt/kvm/kvm_main.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index:
No real bugs in this one, the real bug I found is in a separate
patch.
Cc: a...@redhat.com
Cc: kvm@vger.kernel.org
Signed-off-by: Andi Kleen
---
arch/x86/kvm/paging_tmpl.h |1 +
arch/x86/kvm/vmx.c |3 +--
virt/kvm/assigned-dev.c|2 --
3 files changed, 2 insertions
Stephen Hemminger writes:
> Still not sure this is a good idea for a couple of reasons:
>
> 1. We already have lots of special cases with skb's (frags and fraglist),
>and skb's travel through a lot of different parts of the kernel. So any
>new change like this creates lots of exposed poi
> That would certainly be a part of it, I'm sure they have stronger
> fairness and guarantees at the expense of some performance. We saw the
> spinlock starvation first on 8-16 core Opterons I think, wheras Altix
> had been over 1024 cores and POWER7 1024 threads now apparently without
> reported p
On Thu, Jun 03, 2010 at 12:06:39PM +0100, David Woodhouse wrote:
> On Tue, 2010-06-01 at 21:36 +0200, Andi Kleen wrote:
> > > Collecting the contention/usage statistics on a per spinlock
> > > basis seems complex. I believe a practical approximation
> > > to this a
On Thu, Jun 03, 2010 at 10:38:32PM +1000, Nick Piggin wrote:
> And they aren't even using ticket spinlocks!!
I suppose they simply don't have unfair memory. Makes things easier.
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscrib
On Thu, Jun 03, 2010 at 09:50:51AM +0530, Srivatsa Vaddagiri wrote:
> On Wed, Jun 02, 2010 at 12:00:27PM +0300, Avi Kivity wrote:
> >
> > There are two separate problems: the more general problem is that
> > the hypervisor can put a vcpu to sleep while holding a lock, causing
> > other vcpus to sp
On Wed, Jun 02, 2010 at 05:51:14AM +0300, Avi Kivity wrote:
> On 06/01/2010 08:27 PM, Andi Kleen wrote:
>> On Tue, Jun 01, 2010 at 07:52:28PM +0300, Avi Kivity wrote:
>>
>>> We are running everything on NUMA (since all modern machines are now NUMA).
>>> A
> Collecting the contention/usage statistics on a per spinlock
> basis seems complex. I believe a practical approximation
> to this are adaptive mutexes where upon hitting a spin
> time threshold, punt and let the scheduler reconcile fairness.
That would probably work, except: how do you get the
On Tue, Jun 01, 2010 at 07:52:28PM +0300, Avi Kivity wrote:
> We are running everything on NUMA (since all modern machines are now NUMA).
> At what scale do the issues become observable?
On Intel platforms it's visible starting with 4 sockets.
>
>>> I understand that reason and do not propose t
On Tue, Jun 01, 2010 at 07:24:14PM +0300, Gleb Natapov wrote:
> On Tue, Jun 01, 2010 at 05:53:09PM +0200, Andi Kleen wrote:
> > Gleb Natapov writes:
> > >
> > > The patch below allows to patch ticket spinlock code to behave similar to
> > > old unfair spinloc
Gleb Natapov writes:
>
> The patch below allows to patch ticket spinlock code to behave similar to
> old unfair spinlock when hypervisor is detected. After patching unlocked
The question is what happens when you have a system with unfair
memory and you run the hypervisor on that. There it could b
Peter Lieven writes:
> Starting mail service (Postfix)
> NMI Watchdog detected LOCKUP on CPU 0
You could simply turn off the NMI watchdog (nmi_watchdog=0 at the kernel
command line)
Perhaps the PMU emulation is not complete and nmi watchdog
needs PMU. It's not really needed normally.
-Andi
On Wed, Mar 31, 2010 at 10:15:28AM +0200, Jiri Kosina wrote:
> On Wed, 31 Mar 2010, Andi Kleen wrote:
>
> > > booting 32bit guest on 32bit host on AMD system gives me the following
> > > warning when KVM is instructed to boot as SMP:
> >
> > I guess these w
> >I guess these warnings could be just disabled. With nearly everyone
> >using multi-core these days they are kind of obsolete anyways.
> Well, the warning refers to an old single-core only CPU model. Most of
> those were able to run in SMP boards, but only a subset of them was
> officially cert
On Wed, Mar 31, 2010 at 01:03:02AM +0200, Jiri Kosina wrote:
> Hi,
>
> booting 32bit guest on 32bit host on AMD system gives me the following
> warning when KVM is instructed to boot as SMP:
I guess these warnings could be just disabled. With nearly everyone
using multi-core these days they are
Avi Kivity writes:
> On 03/24/2010 09:38 AM, Andi Kleen wrote:
>>> If you're profiling a single guest it makes more sense to do this from
>>> inside the guest - you can profile userspace as well as the kernel.
>>>
>> I'm interested in debugging
> If you're profiling a single guest it makes more sense to do this from
> inside the guest - you can profile userspace as well as the kernel.
I'm interested in debugging the guest without guest cooperation.
In many cases qemu's new gdb stub works for that, but in some cases
I would prefer instr
Joerg Roedel writes:
>
> Sidenote: I really think we should come to a conclusion about the
> concept. KVM integration into perf is very useful feature to
> analyze virtualization workloads.
Agreed. I especially would like to see instruction/branch tracing
working this way. This
Soeren Sandmann writes:
>
> Examples:
>
> - What is going on inside QEMU?
That's something the JIT interface could answer.
> - Which client is the X server servicing?
>
> - What parts of a python/shell/scheme/javascript program is
> taking the most CPU time?
I
Soeren Sandmann writes:
>
> To fix that problem, it seems like we need some way to have python
> export what is going on. Maybe the same mechanism could be used to
> both access what is going on in qemu and python.
oprofile already has an interface to let JITs export
information about the JITed c
Peter Zijlstra writes:
>
> Whatever are we doing to end up in do_page_fault() as it stands? Surely
> we can tell the CPU to go elsewhere to handle faults?
>
> Isn't that as simple as calling set_intr_gate(14, my_page_fault)
> somewhere on the cpuinit instead of the regular page_fault handler?
Tha
> --- a/qemu-kvm-x86.c
> +++ b/qemu-kvm-x86.c
> @@ -1015,6 +1015,7 @@ void kvm_arch_load_regs(CPUState *env)
> #endif
> set_msr_entry(&msrs[n++], MSR_KVM_SYSTEM_TIME, env->system_time_msr);
> set_msr_entry(&msrs[n++], MSR_KVM_WALL_CLOCK, env->wall_clock_msr);
> +set_msr_entry(&msrs
"Ira W. Snyder" writes:
> (You'll quickly find that you must use DMA to transfer data across PCI.
> AFAIK, CPU's cannot do burst accesses to the PCI bus. I get a 10+ times
AFAIK that's what write-combining on x86 does. DMA has other
advantages of course.
-Andi
--
a...@linux.intel.com -- Speaki
Ingo Molnar writes:
> Yes, there's (obviously) compatibility requirements and artifacts and past
> mistakes (as with any software interface), but you need to admit it to
Yes that's exactly what I meant.
> yourself that your "virtualization is sloppy just like hardware" claim is
> just
In
On Wed, Dec 23, 2009 at 12:17:48PM -0500, Gregory Haskins wrote:
> On 12/23/09 12:10 PM, Andi Kleen wrote:
> >> And its moot, anyway, as I have already retracted my one outstanding
> >> pull request based on Linus' observation. So at this time, I am not
> >>
> > >It seems like there's definitely still potential for improvement
> > >with messages<4K. But for the large messages they indeed
> > >look rather good.
>
> You are misreading the graph. At <4K it is tracking bare metal (the
> green and yellow lines are bare metal, the red and blue bars are vir
> And its moot, anyway, as I have already retracted my one outstanding
> pull request based on Linus' observation. So at this time, I am not
> advocating _anything_ for upstream inclusion. And I am contemplating
> _never_ doing so again. It's not worth _this_.
That certainly sounds like the wro
> http://www.redhat.com/f/pdf/summit/cwright_11_open_source_virt.pdf
>
> See slide 32. This is without vhost-net.
Thanks. Do you also have latency numbers?
It seems like there's definitely still potential for improvement
with messages <4K. But for the large messages they indeed
look rather good
> i.e. it has all the makings of a stupid, avoidable, permanent fork. The thing
Nearly. There was no equivalent of a kernel based virtual driver host
before.
> - Are a pure software concept and any compatibility mismatch is
>
> self-inflicted. The patches
1 - 100 of 171 matches
Mail list logo
