On Mon, Jun 10, 2013 at 06:31:11PM +0200, Igor Mammedov wrote:
> ===
> Could be the following an acceptable fix?
> ===
Read of kvmclock should return proper value from hypervisor: system
timestamp + tsc delta.
Should find the offender site and have it register MSR_KVM_SYSTEM_TIME
before reading
> > >>(2013/06/06 20:33), Gleb Natapov wrote:
> > >>>On Wed, Jun 05, 2013 at 09:23:22PM -0300, Marcelo Tosatti wrote:
> > >>>>On Tue, Jun 04, 2013 at 05:36:19PM +0900, Yoshihiro YUNOMAE wrote:
> > >>>>>Add a tracepoint write_tsc_offset f
On Fri, Jun 07, 2013 at 02:22:22PM +0900, Yoshihiro YUNOMAE wrote:
> (2013/06/06 20:33), Gleb Natapov wrote:
> >On Wed, Jun 05, 2013 at 09:23:22PM -0300, Marcelo Tosatti wrote:
> >>On Tue, Jun 04, 2013 at 05:36:19PM +0900, Yoshihiro YUNOMAE wrote:
> >>>Add a tracepoin
On Thu, Jun 06, 2013 at 02:33:06PM +0300, Gleb Natapov wrote:
> On Wed, Jun 05, 2013 at 09:23:22PM -0300, Marcelo Tosatti wrote:
> > On Tue, Jun 04, 2013 at 05:36:19PM +0900, Yoshihiro YUNOMAE wrote:
> > > Add a tracepoint write_tsc_offset for tracing TSC offset change.
>
tsc_offset
> # echo x86-tsc > trace_clock
> # echo 1 > events/kvm/kvm_write_tsc_offset/enable
>
> 2. boot a guest
>
> Signed-off-by: Yoshihiro YUNOMAE
> Cc: Marcelo Tosatti
> Cc: Gleb Natapov
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Pet
On Fri, May 31, 2013 at 08:36:19AM +0800, Xiao Guangrong wrote:
> Hi Gleb, Paolo, Marcelo,
>
> I have putted the potential controversial patches to the latter that are
> patch 8 ~ 10, patch 11 depends on patch 9. Other patches are fully reviewed,
> I think its are ready for being merged. If not lu
On Wed, May 29, 2013 at 10:42:04AM +0100, David Vrabel wrote:
> On 28/05/13 19:53, John Stultz wrote:
> > On 05/28/2013 11:22 AM, David Vrabel wrote:
> >> From: David Vrabel
> >>
> >> Currently the Xen wallclock is only updated every 11 minutes if NTP is
> >> synchronized to its clock source. If
On Wed, May 29, 2013 at 09:09:09PM +0800, Xiao Guangrong wrote:
> This information is I replied Gleb in his mail where he raced a question that
> why "collapse tlb flush is needed":
>
> ==
> It seems no.
> Since we have reloaded mmu before zapping the obsolete pages, the mmu-lock
> is easily c
On Wed, May 29, 2013 at 09:09:09PM +0800, Xiao Guangrong wrote:
> On 05/29/2013 07:11 PM, Marcelo Tosatti wrote:
> > On Tue, May 28, 2013 at 11:02:09PM +0800, Xiao Guangrong wrote:
> >> On 05/28/2013 08:18 AM, Marcelo Tosatti wrote:
> >>> On Mon, May 27, 2013 at 10
On Tue, May 28, 2013 at 10:51:38PM +0800, Xiao Guangrong wrote:
> On 05/28/2013 08:13 AM, Marcelo Tosatti wrote:
> > On Thu, May 23, 2013 at 03:55:58AM +0800, Xiao Guangrong wrote:
> >> It is only used to zap the obsolete page. Since the obsolete page
> >> will not be u
On Wed, May 29, 2013 at 11:03:19AM +0800, Xiao Guangrong wrote:
> >>> the pages since other vcpus may be doing locklessly shadow
> >>> page walking
> >
> > Ah, yes, i agree with you.
> >
> > We can introduce a list, say kvm->arch.obsolte_pages, to link all of the
> > zapped-page, the page-shrink
On Tue, May 28, 2013 at 11:02:09PM +0800, Xiao Guangrong wrote:
> On 05/28/2013 08:18 AM, Marcelo Tosatti wrote:
> > On Mon, May 27, 2013 at 10:20:12AM +0800, Xiao Guangrong wrote:
> >> On 05/25/2013 04:34 AM, Marcelo Tosatti wrote:
> >>> On Thu, May 23, 2013 at 03
On Mon, May 27, 2013 at 10:20:12AM +0800, Xiao Guangrong wrote:
> On 05/25/2013 04:34 AM, Marcelo Tosatti wrote:
> > On Thu, May 23, 2013 at 03:55:53AM +0800, Xiao Guangrong wrote:
> >> Zap at lease 10 pages before releasing mmu-lock to reduce the overload
> >&g
On Thu, May 23, 2013 at 03:55:59AM +0800, Xiao Guangrong wrote:
> kvm_zap_obsolete_pages uses lock-break technique to zap pages,
> it will flush tlb every time when it does lock-break
>
> We can reload mmu on all vcpus after updating the generation
> number so that the obsolete pages are not used
On Thu, May 23, 2013 at 03:55:58AM +0800, Xiao Guangrong wrote:
> It is only used to zap the obsolete page. Since the obsolete page
> will not be used, we need not spend time to find its unsync children
> out. Also, we delete the page from shadow page cache so that the page
> is completely isolated
On Sun, May 26, 2013 at 11:26:49AM +0300, Gleb Natapov wrote:
> On Fri, May 24, 2013 at 05:23:07PM -0300, Marcelo Tosatti wrote:
> > Hi Xiao,
> >
> > On Thu, May 23, 2013 at 03:55:52AM +0800, Xiao Guangrong wrote:
> > > The current kvm_mmu_zap_all is really sl
On Thu, May 23, 2013 at 03:55:53AM +0800, Xiao Guangrong wrote:
> Zap at lease 10 pages before releasing mmu-lock to reduce the overload
> caused by requiring lock
>
> After the patch, kvm_zap_obsolete_pages can forward progress anyway,
> so update the comments
>
> [ It improves kernel building 0
Hi Xiao,
On Thu, May 23, 2013 at 03:55:52AM +0800, Xiao Guangrong wrote:
> The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
> walk and zap all shadow pages one by one, also it need to zap all guest
> page's rmap and all shadow page's parent spte list. Particularly, things
> b
On Wed, May 22, 2013 at 09:34:13AM +0300, Gleb Natapov wrote:
> On Tue, May 21, 2013 at 10:33:30PM -0300, Marcelo Tosatti wrote:
> > On Tue, May 21, 2013 at 11:39:03AM +0300, Gleb Natapov wrote:
> > > > Any pages with stale information will be zapped by kvm_mmu_zap_all().
>
On Tue, May 21, 2013 at 11:39:03AM +0300, Gleb Natapov wrote:
> > Any pages with stale information will be zapped by kvm_mmu_zap_all().
> > When that happens, page faults will take place which will automatically
> > use the new generation number.
> >
> > So still not clear why is this necessary.
On Tue, May 21, 2013 at 11:36:57AM +0800, Xiao Guangrong wrote:
> On 05/21/2013 04:40 AM, Marcelo Tosatti wrote:
> > On Mon, May 20, 2013 at 11:15:45PM +0300, Gleb Natapov wrote:
> >> On Mon, May 20, 2013 at 04:46:24PM -0300, Marcelo Tosatti wrote:
> >>> On Fri, Ma
On Mon, May 20, 2013 at 11:15:45PM +0300, Gleb Natapov wrote:
> On Mon, May 20, 2013 at 04:46:24PM -0300, Marcelo Tosatti wrote:
> > On Fri, May 17, 2013 at 05:12:58AM +0800, Xiao Guangrong wrote:
> > > The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
>
On Fri, May 17, 2013 at 05:12:58AM +0800, Xiao Guangrong wrote:
> The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
> walk and zap all shadow pages one by one, also it need to zap all guest
> page's rmap and all shadow page's parent spte list. Particularly, things
> become wors
On Wed, May 15, 2013 at 07:02:24PM +0200, Paolo Bonzini wrote:
> As announced last week by Marcelo Tosatti, I will be co-maintaining
> KVM together with Gleb.
>
> Cc: Marcelo Tosatti
> Cc: Gleb Natapov
> Cc: k...@vger.kernel.org
> Signed-off-by: Paolo Bonzini
>
On Tue, May 07, 2013 at 05:56:08PM +0300, Gleb Natapov wrote:
> > > Yes, I am missing what Marcelo means there too. We cannot free memslot
> > > until we unmap its rmap one way or the other.
> >
> > I do not understand what are you optimizing for, given the four possible
> > cases we discussed at
On Tue, May 07, 2013 at 11:39:59AM +0800, Xiao Guangrong wrote:
> >>> Step 1) Fix kvm_mmu_zap_all's behaviour: introduce lockbreak via
> >>> spin_needbreak. Use generation numbers so that in case kvm_mmu_zap_all
> >>> releases mmu_lock and reacquires it again, only shadow pages
> >>> from the gen
On Tue, May 07, 2013 at 01:00:51PM +0300, Gleb Natapov wrote:
> On Tue, May 07, 2013 at 05:41:35PM +0800, Xiao Guangrong wrote:
> > On 05/07/2013 04:58 PM, Gleb Natapov wrote:
> > > On Tue, May 07, 2013 at 01:45:52AM +0800, Xiao Guangrong wrote:
> > >> On 05/07/2013 01:24 AM, Gleb Natapov wrote:
>
On Mon, May 06, 2013 at 11:39:11AM +0800, Xiao Guangrong wrote:
> On 05/04/2013 08:52 AM, Marcelo Tosatti wrote:
> > On Sat, May 04, 2013 at 12:51:06AM +0800, Xiao Guangrong wrote:
> >> On 05/03/2013 11:53 PM, Marcelo Tosatti wrote:
> >>> On Fri, May 03, 2013 at 01
On Fri, May 03, 2013 at 09:52:01PM -0300, Marcelo Tosatti wrote:
> On Sat, May 04, 2013 at 12:51:06AM +0800, Xiao Guangrong wrote:
> > On 05/03/2013 11:53 PM, Marcelo Tosatti wrote:
> > > On Fri, May 03, 2013 at 01:52:07PM +0800, Xiao Guangrong wrote:
> > >> On 05/03/
On Sat, May 04, 2013 at 12:51:06AM +0800, Xiao Guangrong wrote:
> On 05/03/2013 11:53 PM, Marcelo Tosatti wrote:
> > On Fri, May 03, 2013 at 01:52:07PM +0800, Xiao Guangrong wrote:
> >> On 05/03/2013 09:05 AM, Marcelo Tosatti wrote:
> >>
> >>>> +
> >
On Fri, May 03, 2013 at 01:52:07PM +0800, Xiao Guangrong wrote:
> On 05/03/2013 09:05 AM, Marcelo Tosatti wrote:
>
> >> +
> >> +/*
> >> + * Fast invalid all shadow pages belong to @slot.
> >> + *
> >> + * @slot != NULL means the invalidation i
On Sat, Apr 27, 2013 at 11:13:20AM +0800, Xiao Guangrong wrote:
> The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
> walk and zap all shadow pages one by one, also it need to zap all guest
> page's rmap and all shadow page's parent spte list. Particularly, things
> become wors
On Fri, Apr 26, 2013 at 11:51:40AM +0200, Borislav Petkov wrote:
> On Fri, Apr 26, 2013 at 08:42:50AM +0200, Ingo Molnar wrote:
> >
> > ... < take all review comments >
>
> Here it is:
>
> --
> >From 56880e448600ca1504df8c68c59f31153f7b5b0f Mon Sep 17 00:00:00 2001
> From: Borislav Petkov
> Date
On Mon, Apr 29, 2013 at 09:59:30AM -0700, Randy Dunlap wrote:
> On 04/29/13 09:54, Alex Williamson wrote:
> > Fix build with CONFIG_PCI unset by linking KVM_CAP_IOMMU to
> > device assignment config option. It has no purpose otherwise.
> >
> > Signed-off-by: Alex Williamson
>
> Reported-by: Ran
On Mon, Apr 22, 2013 at 10:45:53PM +0900, Takuya Yoshikawa wrote:
> On Mon, 22 Apr 2013 15:39:38 +0300
> Gleb Natapov wrote:
>
> > > > Do not want kvm_set_memory (cases: DELETE/MOVE/CREATES) to be
> > > > suspectible to:
> > > >
> > > > vcpu 1 | kvm_set_memory
> > > > crea
On Sun, Apr 21, 2013 at 04:03:46PM +0300, Gleb Natapov wrote:
> On Tue, Apr 16, 2013 at 02:32:38PM +0800, Xiao Guangrong wrote:
> > This patchset is based on my previous two patchset:
> > [PATCH 0/2] KVM: x86: avoid potential soft lockup and unneeded mmu reload
> > (https://lkml.org/lkml/2013/4/1/2
On Sun, Apr 21, 2013 at 10:09:29PM +0800, Xiao Guangrong wrote:
> On 04/21/2013 09:03 PM, Gleb Natapov wrote:
> > On Tue, Apr 16, 2013 at 02:32:38PM +0800, Xiao Guangrong wrote:
> >> This patchset is based on my previous two patchset:
> >> [PATCH 0/2] KVM: x86: avoid potential soft lockup and unnee
On Sun, Apr 21, 2013 at 12:27:51PM -0300, Marcelo Tosatti wrote:
> On Sun, Apr 21, 2013 at 04:03:46PM +0300, Gleb Natapov wrote:
> > On Tue, Apr 16, 2013 at 02:32:38PM +0800, Xiao Guangrong wrote:
> > > This patchset is based on my previous two patchset:
> > > [PATCH 0/2
On Thu, Apr 18, 2013 at 12:03:45PM +0800, Xiao Guangrong wrote:
> On 04/18/2013 08:08 AM, Marcelo Tosatti wrote:
> > On Tue, Apr 16, 2013 at 02:32:53PM +0800, Xiao Guangrong wrote:
> >> Use kvm_mmu_invalid_all_pages in kvm_arch_flush_shadow_all and
> >> rename kvm_zap_a
On Thu, Apr 18, 2013 at 07:36:03PM +0300, Gleb Natapov wrote:
> On Thu, Apr 18, 2013 at 11:01:18AM -0300, Marcelo Tosatti wrote:
> > On Thu, Apr 18, 2013 at 12:42:39PM +0300, Gleb Natapov wrote:
> > > > > that, but if not then less code is better.
> > > >
>
On Thu, Apr 18, 2013 at 12:42:39PM +0300, Gleb Natapov wrote:
> > > that, but if not then less code is better.
> >
> > The number of sp->role.invalid=1 pages is small (only shadow roots). It
> > can grow but is bounded to a handful. No improvement visible there.
> >
> > The number of shadow pages
On Thu, Apr 18, 2013 at 12:00:16PM +0800, Xiao Guangrong wrote:
> >
> > What is the justification for this?
>
> We want the rmap of being deleted memslot is removed-only that is
> needed for unmapping rmap out of mmu-lock.
>
> ==
> 1) do not corrupt the rmap
> 2) keep pte-list-descs availab
On Thu, Apr 18, 2013 at 11:46:29AM +0200, Borislav Petkov wrote:
> On Wed, Apr 17, 2013 at 08:25:07PM -0300, Marcelo Tosatti wrote:
> > On Tue, Apr 16, 2013 at 06:18:52PM +0200, Borislav Petkov wrote:
> > > On Sun, Apr 14, 2013 at 01:03:20PM +0200, Borislav Petkov wrote:
>
On Thu, Apr 18, 2013 at 10:03:06AM -0300, Marcelo Tosatti wrote:
> On Thu, Apr 18, 2013 at 12:00:16PM +0800, Xiao Guangrong wrote:
> > >
> > > What is the justification for this?
> >
> > We want the rmap of being deleted memslot is removed-only that is
> &g
On Tue, Apr 16, 2013 at 02:32:50PM +0800, Xiao Guangrong wrote:
> The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
> walk and zap all shadow pages one by one, also it need to zap all guest
> page's rmap and all shadow page's parent spte list. Particularly, things
> become wors
On Tue, Apr 16, 2013 at 02:32:53PM +0800, Xiao Guangrong wrote:
> Use kvm_mmu_invalid_all_pages in kvm_arch_flush_shadow_all and
> rename kvm_zap_all to kvm_free_all which is used to free all
> memmory used by kvm mmu when vm is being destroyed, at this time,
> no vcpu exists and mmu-notify has bee
On Tue, Apr 16, 2013 at 02:32:45PM +0800, Xiao Guangrong wrote:
> Invalid rmaps is the rmap of the invalid memslot which is being
> deleted, especially, we can treat all rmaps are invalid when
> kvm is being destroyed since all memslot will be deleted soon.
> MMU should remove all sptes on these rm
On Tue, Apr 16, 2013 at 06:18:52PM +0200, Borislav Petkov wrote:
> On Sun, Apr 14, 2013 at 01:03:20PM +0200, Borislav Petkov wrote:
> > On Sun, Apr 14, 2013 at 12:31:12PM +0300, Pekka Enberg wrote:
> > > I obviously support having something like this in mainline. I wonder
> > > though if we could j
3 07:47 PM, Gleb Natapov wrote:
> > >>> On Fri, Mar 22, 2013 at 07:39:24PM +0800, Xiao Guangrong wrote:
> > >>>> On 03/22/2013 07:28 PM, Gleb Natapov wrote:
> > >>>>> On Fri, Mar 22, 2013 at 07:10:44PM +
Linus,
Please pull from
git://git.kernel.org/pub/scm/virt/kvm/kvm.git master
To receive the following PPC and ARM KVM fixes
Marc Zyngier (2):
ARM: KVM: fix KVM_CAP_ARM_SET_DEVICE_ADDR reporting
ARM: KVM: fix L_PTE_S2_RDWR to actually be Read/Write
Marcelo Tosatti (1):
Merge
On Mon, Apr 15, 2013 at 03:00:27PM +0200, Paolo Bonzini wrote:
> KVM does not use the activity state VMCS field, and does not support
> it in nested VMX either (the corresponding bits in the misc VMX feature
> MSR are zero). Fail entry if the activity state is set to anything but
> "active".
>
>
On Mon, Apr 01, 2013 at 05:56:43PM +0800, Xiao Guangrong wrote:
> Changelog in v2:
> - rename kvm_mmu_invalid_mmio_spte to kvm_mmu_invalid_mmio_sptes
> - use kvm->memslots->generation as kvm global generation-number
> - fix comment and codestyle
> - init kvm generation close to mmio wrap-ar
Linus,
Please pull from
git://git.kernel.org/pub/scm/virt/kvm/kvm.git master
To fix compilation on PPC with !CONFIG_KVM
Marcelo Tosatti (1):
Revert "KVM: allow host header to be included even for !CONFIG_KVM"
include/linux/kvm_host.h |7 +--
1 file changed, 1 inser
On Fri, Mar 22, 2013 at 10:11:17AM +0800, Xiao Guangrong wrote:
> On 03/22/2013 06:21 AM, Marcelo Tosatti wrote:
> > On Wed, Mar 20, 2013 at 04:30:20PM +0800, Xiao Guangrong wrote:
> >> Changlog:
> >> V2:
> >> - do not reset n_requested_mmu_pages and n_ma
On Wed, Mar 20, 2013 at 04:30:20PM +0800, Xiao Guangrong wrote:
> Changlog:
> V2:
> - do not reset n_requested_mmu_pages and n_max_mmu_pages
> - batch free root shadow pages to reduce vcpu notification and mmu-lock
> contention
> - remove the first patch that introduce kvm->arch.mmu_cache
On Tue, Mar 19, 2013 at 04:30:26PM +0100, Paolo Bonzini wrote:
> The CS base was initialized to 0 on VMX (wrong, but usually overridden
> by userspace before starting) or 0xf on SVM. The correct value is
> 0x, and VMX is able to emulate it now, so use it.
>
> Signed-off-by: Paolo Bonz
On Mon, Mar 18, 2013 at 08:42:09PM +0800, Xiao Guangrong wrote:
> On 03/18/2013 07:19 PM, Paolo Bonzini wrote:
> > Il 15/03/2013 16:29, Xiao Guangrong ha scritto:
> >> +/*
> >> + * spte bits of bit 3 ~ bit 11 are used as low 9 bits of
> >> + * generation, the bits of bits 52 ~ bit 61 are used as
>
On Tue, Mar 19, 2013 at 11:37:38PM +0800, Xiao Guangrong wrote:
> On 03/19/2013 10:40 PM, Marcelo Tosatti wrote:
>
> >
> > I misunderstood the benefit of your idea (now i got it: zap root
> > and flush TLB guarantees vcpus will refault). What i'd like to avoid is
>
functions
(CVE-2013-1797)
KVM: Fix bounds checking in ioapic indirect register reads (CVE-2013-1798)
Kevin Hilman (1):
KVM: allow host header to be included even for !CONFIG_KVM
Marcelo Tosatti (1):
KVM: x86: fix deadlock in clock-in-progress request handling
arch/x86/include
On Tue, Mar 19, 2013 at 11:06:35AM +0800, Xiao Guangrong wrote:
> On 03/19/2013 04:46 AM, Marcelo Tosatti wrote:
> > On Wed, Mar 13, 2013 at 12:59:12PM +0800, Xiao Guangrong wrote:
> >> The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
> >> walk and
On Thu, Mar 14, 2013 at 05:13:46PM -0700, Kevin Hilman wrote:
> The new context tracking subsystem unconditionally includes kvm_host.h
> headers for the guest enter/exit macros. This causes a compile
> failure when KVM is not enabled.
>
> Fix by adding an IS_ENABLED(CONFIG_KVM) check to kvm_host
On Wed, Mar 13, 2013 at 12:59:12PM +0800, Xiao Guangrong wrote:
> The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
> walk and zap all shadow pages one by one, also it need to zap all guest
> page's rmap and all shadow page's parent spte list. Particularly, things
> become wors
On Wed, Mar 13, 2013 at 10:07:06PM -0300, Marcelo Tosatti wrote:
> On Wed, Mar 13, 2013 at 12:59:12PM +0800, Xiao Guangrong wrote:
> > The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
> > walk and zap all shadow pages one by one, also it need to zap all guest
On Wed, Mar 13, 2013 at 12:59:12PM +0800, Xiao Guangrong wrote:
> The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
> walk and zap all shadow pages one by one, also it need to zap all guest
> page's rmap and all shadow page's parent spte list. Particularly, things
> become wors
On Thu, Mar 07, 2013 at 10:54:37PM -0300, Marcelo Tosatti wrote:
> On Thu, Mar 07, 2013 at 04:34:16PM -0600, Michael Wolf wrote:
> > On Thu, 2013-03-07 at 18:25 -0300, Marcelo Tosatti wrote:
> > > On Thu, Mar 07, 2013 at 03:15:09PM -0600, Michael Wolf wrote:
> > >
On Thu, Mar 07, 2013 at 04:34:16PM -0600, Michael Wolf wrote:
> On Thu, 2013-03-07 at 18:25 -0300, Marcelo Tosatti wrote:
> > On Thu, Mar 07, 2013 at 03:15:09PM -0600, Michael Wolf wrote:
> > > >
> > > > Makes sense?
> > > >
> > > > Not
On Thu, Mar 07, 2013 at 03:15:09PM -0600, Michael Wolf wrote:
> >
> > Makes sense?
> >
> > Not sure what the concrete way to report stolen time relative to hard
> > capping is (probably easier inside the scheduler, where run_delay is
> > calculated).
> >
> > Reporting the hard capping to the gue
70532
> --+---+---+---++---+
> no ple ebizzy 1x result for reference : 7394.9 rec/sec
>
> Please let me know if you have any suggestions and comments.
>
> Raghavendra K T (2):
>kvm: Record the preemption status of vcpus using pr
On Wed, Mar 06, 2013 at 10:27:13AM -0600, Michael Wolf wrote:
> On Tue, 2013-03-05 at 22:41 -0300, Marcelo Tosatti wrote:
> > On Tue, Mar 05, 2013 at 02:22:08PM -0600, Michael Wolf wrote:
> > > Sorry for the delay in the response. I did not see the email
> > > righ
On Wed, Mar 06, 2013 at 10:29:12AM -0600, Michael Wolf wrote:
> On Wed, 2013-03-06 at 12:13 +0400, Glauber Costa wrote:
> > On 03/06/2013 05:41 AM, Marcelo Tosatti wrote:
> > > On Tue, Mar 05, 2013 at 02:22:08PM -0600, Michael Wolf wrote:
> > >> Sorry for the delay i
On Tue, Mar 05, 2013 at 02:22:08PM -0600, Michael Wolf wrote:
> Sorry for the delay in the response. I did not see the email
> right away.
>
> On Mon, 2013-02-18 at 22:11 -0300, Marcelo Tosatti wrote:
> > On Mon, Feb 18, 2013 at 05:43:47PM +0100, Frederic Weisbecker wrote:
>
On Tue, Mar 05, 2013 at 02:17:57PM -0600, Michael Wolf wrote:
> Sorry for the delay in the response. I did not see your question.
>
> On Mon, 2013-02-18 at 20:57 -0300, Marcelo Tosatti wrote:
> > On Tue, Feb 05, 2013 at 03:49:41PM -0600, Michael Wolf wrote:
> > >
On Sun, Mar 03, 2013 at 03:00:22PM +0200, Gleb Natapov wrote:
> On Fri, Mar 01, 2013 at 09:03:12PM -0300, Marcelo Tosatti wrote:
> > On Thu, Feb 28, 2013 at 04:54:25PM +0800, Hu Tao wrote:
> > > > > diff --git a/arch/x86/include/uapi/asm/kvm_para.h
> > > > >
On Thu, Feb 28, 2013 at 04:54:25PM +0800, Hu Tao wrote:
> > > diff --git a/arch/x86/include/uapi/asm/kvm_para.h
> > > b/arch/x86/include/uapi/asm/kvm_para.h
> > > index 06fdbd9..c15ef33 100644
> > > --- a/arch/x86/include/uapi/asm/kvm_para.h
> > > +++ b/arch/x86/include/uapi/asm/kvm_para.h
> > > @
On Wed, Feb 20, 2013 at 04:13:49PM +0800, Hu Tao wrote:
> On Thu, Feb 07, 2013 at 11:50:28PM -0200, Marcelo Tosatti wrote:
> > On Wed, Jan 23, 2013 at 03:19:23PM +0800, Hu Tao wrote:
> > > From: Wen Congyang
> > >
> > > The guest should run after rese
On Sun, Feb 24, 2013 at 04:23:44PM -0500, Peter Hurley wrote:
> On Tue, 2013-02-19 at 10:26 +0200, Gleb Natapov wrote:
> > On Mon, Feb 18, 2013 at 08:12:21PM -0500, Peter Hurley wrote:
> > > On Mon, 2013-02-18 at 19:59 -0300, Marcelo Tosatti wrote:
> > > > On Wed, Fe
On Thu, Feb 21, 2013 at 09:56:54AM +0100, Ingo Molnar wrote:
>
> * Shuah Khan wrote:
>
> > On Tue, Feb 19, 2013 at 7:27 PM, Linux Kernel Mailing List
> > wrote:
> > > Gitweb:
> > > http://git.kernel.org/linus/;a=commit;h=c3c186403c6abd32e719f005f0af950155a9e54d
> > > Commit: c3c186403c
n Kiszka (1):
KVM: nVMX: Remove redundant get_vmcs12 from nested_vmx_exit_handled_msr
Jesse Larrew (1):
x86: kvm_para: fix typo in hypercall comments
Marcelo Tosatti (3):
KVM: VMX: fix incorrect cached cpl value with real/v8086 modes
x86: pvclock kvm: align allocation size to page size
On Mon, Feb 18, 2013 at 05:43:47PM +0100, Frederic Weisbecker wrote:
> 2013/2/5 Michael Wolf :
> > In the case of where you have a system that is running in a
> > capped or overcommitted environment the user may see steal time
> > being reported in accounting tools such as top or vmstat. This can
On Tue, Feb 05, 2013 at 03:49:41PM -0600, Michael Wolf wrote:
> Add a helper routine to scheduler/core.c to allow the kvm module
> to retrieve the cpu hardlimit settings. The values will be used
> to set up a timer that is used to separate the consigned from the
> steal time.
1) Can you please de
On Wed, Feb 13, 2013 at 06:57:09AM -0500, Peter Hurley wrote:
> On Wed, 2013-02-13 at 12:51 +0200, Gleb Natapov wrote:
> > On Tue, Feb 12, 2013 at 04:39:03PM -0800, H. Peter Anvin wrote:
> > > On 02/12/2013 04:26 PM, Peter Hurley wrote:
> > > > With -next-20130204+ in ubuntu 12.10 VM (so the 80x25
On Tue, Feb 05, 2013 at 04:53:19PM +0800, Xiao Guangrong wrote:
> There is little different between walking parent pte and walking ramp:
> all spte in rmap must be present but this is not true on parent pte list,
> in kvm_mmu_alloc_page, we always link the parent list before set the spte
> to prese
On Tue, Feb 05, 2013 at 03:26:21PM +0800, Xiao Guangrong wrote:
> There are the simple cleanups for MMU, no function / logic changed.
>
> Marcelo, Gleb, please apply them after applying
> "[PATCH v3] KVM: MMU: lazily drop large spte"
>
> Changelog:
> no change, just split them from the previous p
On Tue, Feb 05, 2013 at 04:55:37PM +0800, Xiao Guangrong wrote:
> If a shadow page is being zapped or a host page is going to be freed, kvm
> will drop all the reverse-mappings on the shadow page or the gfn. Currently,
> it drops the reverse-mapping one by one - it deletes the first reverse
> mapp
On Wed, Jan 23, 2013 at 03:19:22PM +0800, Hu Tao wrote:
> This patch enables preservation of cpu runstate during save/load vm.
> So when a vm is restored from snapshot, the cpu runstate is restored,
> too.
>
> See following example:
>
> # save two vms: one is running, the other is paused
> (qemu)
Hi,
On Wed, Jan 23, 2013 at 03:19:21PM +0800, Hu Tao wrote:
> We can know the guest is panicked when the guest runs on xen.
> But we do not have such feature on kvm.
>
> Another purpose of this feature is: management app(for example:
> libvirt) can do auto dump when the guest is panicked. If mana
On Wed, Jan 23, 2013 at 03:19:23PM +0800, Hu Tao wrote:
> From: Wen Congyang
>
> The guest should run after resetting it, but it does not run if its
> old state is RUN_STATE_INTERNAL_ERROR or RUN_STATE_PAUSED.
>
> We don't set runstate to RUN_STATE_PAUSED when resetting the guest,
> so the runst
On Tue, Feb 05, 2013 at 03:11:09PM +0800, Xiao Guangrong wrote:
> Currently, kvm zaps the large spte if write-protected is needed, the later
> read can fault on that spte. Actually, we can make the large spte readonly
> instead of making them un-present, the page fault caused by read access can
> b
On Tue, Jan 29, 2013 at 10:55:24AM +0800, Xiao Guangrong wrote:
> On 01/29/2013 08:21 AM, Marcelo Tosatti wrote:
> > On Wed, Jan 23, 2013 at 06:05:29PM +0800, Xiao Guangrong wrote:
> >> In order to detecting spte remapping, we can simply check whether the
> >> spte has a
On Mon, Jan 28, 2013 at 10:07:15PM -0200, Marcelo Tosatti wrote:
> On Fri, Jan 25, 2013 at 10:46:31AM +0800, Xiao Guangrong wrote:
> > On 01/25/2013 08:15 AM, Marcelo Tosatti wrote:
> > > On Wed, Jan 23, 2013 at 06:07:20PM +0800, Xiao Guangrong wrote:
> > >> It
On Fri, Jan 25, 2013 at 10:46:31AM +0800, Xiao Guangrong wrote:
> On 01/25/2013 08:15 AM, Marcelo Tosatti wrote:
> > On Wed, Jan 23, 2013 at 06:07:20PM +0800, Xiao Guangrong wrote:
> >> It makes set_spte more clean and reduces branch prediction
> >>
> &g
On Wed, Jan 23, 2013 at 06:05:29PM +0800, Xiao Guangrong wrote:
> In order to detecting spte remapping, we can simply check whether the
> spte has already been pointing to the pfn even if the spte is not the
> last spte, for middle spte is pointing to the kernel pfn which can not
> be mapped to use
On Mon, Jan 28, 2013 at 08:25:00AM -0700, Alex Williamson wrote:
> On Mon, 2012-12-10 at 18:16 -0200, Marcelo Tosatti wrote:
> > On Thu, Dec 06, 2012 at 02:44:59PM -0700, Alex Williamson wrote:
> > > Typo for the next pointer means we're walking random data here.
> >
On Wed, Jan 23, 2013 at 06:07:20PM +0800, Xiao Guangrong wrote:
> It makes set_spte more clean and reduces branch prediction
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/kvm/mmu.c | 37 ++---
> 1 files changed, 26 insertions(+), 11 deletions(-)
Don't see
Linus,
Please pull from
git://git.kernel.org/pub/scm/virt/kvm/kvm.git master
To receive the following KVM bug fixes
Alexander Graf (1):
KVM: PPC: Emulate dcbf
arch/powerpc/kvm/emulate.c |2 ++
1 file changed, 2 insertions(+)
--
To unsubscribe from this list: send the line "unsubsc
and panic()'d. The behavior varied,
> though, depending on what got corrupted by the bad write.
>
> Signed-off-by: Dave Hansen
> Acked-by: Rik van Riel
> ---
>
> linux-2.6.git-dave/arch/x86/kernel/kvm.c |9 +----
> linux-2.6.git-dave/arch/x86/kernel/kvmclo
On Sun, Jan 13, 2013 at 11:44:12PM +0800, Xiao Guangrong wrote:
> Little cleanup for reexecute_instruction, also use gpa_to_gfn in
> retry_instruction
>
> Signed-off-by: Xiao Guangrong
Applied series, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
eletions(-)
Reviewed-by: Marcelo Tosatti
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Fri, Jan 11, 2013 at 10:12:58PM +0800, Xiao Guangrong wrote:
> On 01/11/2013 09:15 PM, Marcelo Tosatti wrote:
>
> >
> > This is cryptic. Its not obvious at all for someone modifying the code,
> > for example.
> >
> > Can you please clear it explicitly?
&
On Fri, Jan 11, 2013 at 08:46:35AM -0700, Alex Williamson wrote:
> On Fri, 2013-01-11 at 08:45 +, Pandarathil, Vijaymohan R wrote:
> >
> > > -Original Message-
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Wednesday, January 09, 2013 11:05 AM
> > > To: Pan
601 - 700 of 1340 matches
Mail list logo
