On Fri, Apr 04, 2014 at 06:31:04AM +0300, Nadav Amit wrote:
> KVM does not handle the reserved bits of x86 page tables correctly:
> In PAE, bits 5:8 are reserved in the PDPTE.
> In IA-32e, bit 8 is not reserved.
>
> Signed-off-by: Nadav Amit
> ---
> arch/x86/kvm/mmu.c |6 +++---
> 1 file cha
CR4_RESERVED_BITS
KVM: Add SMAP support when setting CR4
KVM: Disable SMAP for guests in EPT realmode and EPT unpaging mode
KVM: expose SMAP feature to guest
KVM: Rename variable smep to cr4_smep
Marcelo Tosatti (1):
KVM: x86: remove WARN_ON from get_kernel_ns()
Paolo Bonzini (2
On Mon, Mar 10, 2014 at 10:01:49PM +0800, Xiao Guangrong wrote:
> Now we can flush all the TLBs out of the mmu lock without TLB corruption when
> write-proect the sptes, it is because:
> - we have marked large sptes readonly instead of dropping them that means we
> just change the spte from writa
On Tue, Apr 01, 2014 at 05:46:34PM -0700, Andy Lutomirski wrote:
> On Tue, Apr 1, 2014 at 5:29 PM, Marcelo Tosatti wrote:
> > On Tue, Apr 01, 2014 at 12:17:16PM -0700, Andy Lutomirski wrote:
> >> On Tue, Apr 1, 2014 at 11:01 AM, Marcelo Tosatti
> >> wrote:
> >
On Tue, Apr 01, 2014 at 12:17:16PM -0700, Andy Lutomirski wrote:
> On Tue, Apr 1, 2014 at 11:01 AM, Marcelo Tosatti wrote:
> > On Mon, Mar 31, 2014 at 10:33:41PM -0700, Andy Lutomirski wrote:
> >> On Mar 31, 2014 8:45 PM, "Marcelo Tosatti" wrote:
> >> >
&
On Mon, Mar 31, 2014 at 10:33:41PM -0700, Andy Lutomirski wrote:
> On Mar 31, 2014 8:45 PM, "Marcelo Tosatti" wrote:
> >
> > On Mon, Mar 31, 2014 at 10:52:25AM -0700, Andy Lutomirski wrote:
> > > On 03/29/2014 01:47 AM, Zhanghailiang wrote:
> > > >
On Mon, Mar 31, 2014 at 10:52:25AM -0700, Andy Lutomirski wrote:
> On 03/29/2014 01:47 AM, Zhanghailiang wrote:
> > Hi,
> > I found when Guest is idle, VDSO pvclock may increase host consumption.
> > We can calcutate as follow, Correct me if I am wrong.
> > (Host)250 * update_pvclock_gtod = 1
On Sat, Mar 29, 2014 at 08:47:27AM +, Zhanghailiang wrote:
> Hi,
> I found when Guest is idle, VDSO pvclock may increase host consumption.
> We can calcutate as follow, Correct me if I am wrong.
> (Host)250 * update_pvclock_gtod = 1500 * gettimeofday(Guest)
> In Host, VDSO pvclock introdu
On Wed, Mar 12, 2014 at 11:40:48AM +0100, Radim Krčmář wrote:
> 2014-03-11 22:05-0300, Marcelo Tosatti:
> > On Tue, Mar 11, 2014 at 07:11:18PM +0100, Radim Krčmář wrote:
> > > We always disable cr8 intercept in its handler, but only re-enable it
> > > if handling KVM_R
On Tue, Mar 11, 2014 at 07:11:18PM +0100, Radim Krčmář wrote:
> We always disable cr8 intercept in its handler, but only re-enable it
> if handling KVM_REQ_EVENT, so there can be a window where we do not
> intercept cr8 writes, which allows an interrupt to disrupt a higher
> priority task.
>
> Fix
On Fri, Mar 07, 2014 at 10:08:52PM +, Li, Bin (Bin) wrote:
> Fully agree.
> It will be a very helpful feature to make ple setting per VM.
> This feature will provide more flexible control to the VM user. All KVM user
> will love to have it.
>
> The enhancement we proposed is neither overlapp
On Fri, Mar 07, 2014 at 02:26:19PM +, Li, Bin (Bin) wrote:
> Can we have "per-VM PLE values"?
>
> My understanding is that the ple values are kvm module setting which applying
> to all VMs in the system.
> And all vms must be stopped first, then unload kvm-intel, reload kvm-intel
> with new
On Wed, Mar 05, 2014 at 09:16:45PM +, Li, Bin (Bin) wrote:
> Did you also find out here why this is the case?
>
> Binl:
> Yes. The application running in our customized embedded OS is also real time
> application which is timing sensitive.
> The timing sensitive level varies among the applic
On Fri, Feb 28, 2014 at 12:52:53PM +0100, Andrew Jones wrote:
> This patch series addresses two issues with global clock updates.
> The first fixes a bug found on hosts that have a tsc marked as
> unstable. As global clock updates get triggered on every vcpu load
> in these cases, guests with a lar
On Wed, Feb 26, 2014 at 07:15:11PM +0100, Andrew Jones wrote:
> When we update a vcpu's local clock it may pick up an NTP correction.
> We can't wait an indeterminate amount of time for other vcpus to pick
> up that correction, so commit 0061d53daf26f introduced a global clock
> update. However, we
On Wed, Feb 26, 2014 at 07:15:12PM +0100, Andrew Jones wrote:
> commit 0061d53daf26f introduced a mechanism to execute a global clock
> update for a vm. We can apply this periodically in order to propagate
> host NTP corrections. Also, if all vcpus of a vm are pinned, then
> without an additional t
On Mon, Feb 24, 2014 at 04:42:29PM +0100, Andrew Jones wrote:
> When the tsc is marked unstable on the host it causes global clock
> updates to be requested each time a vcpu is loaded, nearly halting
> all progress on guests with a large number of vcpus.
>
> Fix this by only requesting a local clo
On Fri, Feb 21, 2014 at 02:07:08AM -0800, David Rientjes wrote:
> On Thu, 20 Feb 2014, Marcelo Tosatti wrote:
>
> > > 1GB is of such granularity that you'd typically either be (a) oom so that
> > > your userspace couldn't even start, or (b) have enough memory s
On Thu, Feb 20, 2014 at 03:15:46PM -0800, David Rientjes wrote:
> On Thu, 20 Feb 2014, Marcelo Tosatti wrote:
>
> > Mel has clearly has no objection to the command line. You can also
> > allocate 2M pages at runtime, and that is no reason for "hugepages="
On Wed, Feb 19, 2014 at 07:46:41PM -0800, David Rientjes wrote:
> On Wed, 19 Feb 2014, Marcelo Tosatti wrote:
>
> > We agree that, in the future, we'd like to provide the ability to
> > dynamically allocate and free 1GB pages at runtime.
> >
> > Extending the
On Wed, Feb 19, 2014 at 07:46:41PM -0800, David Rientjes wrote:
> On Wed, 19 Feb 2014, Marcelo Tosatti wrote:
>
> > We agree that, in the future, we'd like to provide the ability to
> > dynamically allocate and free 1GB pages at runtime.
> >
> > Extending the
On Tue, Feb 18, 2014 at 02:16:42PM -0800, David Rientjes wrote:
> On Tue, 18 Feb 2014, Marcelo Tosatti wrote:
>
> > > Lacking from your entire patchset is a specific example of what you want
> > > to do. So I think we're all guessing what exactly your usecase is and
On Mon, Feb 17, 2014 at 03:23:16PM -0800, David Rientjes wrote:
> On Mon, 17 Feb 2014, Luiz Capitulino wrote:
>
> > hugepages= and hugepages_node= are similar, but have different semantics.
> >
> > hugepagesz= and hugepages= create a pool of huge pages of the specified
> > size.
> > This means t
On Tue, Feb 11, 2014 at 05:10:35PM +, Mel Gorman wrote:
> On Tue, Feb 11, 2014 at 01:26:29PM -0200, Marcelo Tosatti wrote:
> > > Or take a stab at allocating 1G pages at runtime. It would require
> > > finding properly aligned 1Gs worth of contiguous MAX_ORDER_NR_PAGE
On Tue, Feb 11, 2014 at 09:25:14AM +, Mel Gorman wrote:
> On Mon, Feb 10, 2014 at 06:54:20PM -0800, David Rientjes wrote:
> > On Mon, 10 Feb 2014, Luiz Capitulino wrote:
> >
> > > HugeTLB command-line option hugepages= allows the user to specify how many
> > > huge pages should be allocated at
+
> 2 files changed, 43 insertions(+), 21 deletions(-)
>
> --
> 1.8.3.1
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/
t_pfn < level_pfn + level_size(level) - 1)) {
> dma_clear_pte(pte);
> domain_flush_cache(domain, pte, sizeof(*pte));
> free_pgtable_page(level_pte);
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/
ch.last_tsc_write = data;
> kvm->arch.last_tsc_khz = vcpu->arch.virtual_tsc_khz;
>
> - /* Reset of TSC must disable overshoot protection below */
> - vcpu->arch.hv_clock.tsc_timestamp = 0;
> vcpu->arch.last_guest_tsc = data;
>
> /* Keep track of which
On Thu, Jan 09, 2014 at 03:08:25PM -0500, Hu Yaohui wrote:
> Hi Marcelo,
> Thanks for your replying!
> I hope you have a good day! I am sorry that it's not that obvious to
> me after I checked that function.
> If the remote vcpu is not in the same pcpu as the sender which calls
> kvm_vpcu_kick.
> B
On Wed, Jan 08, 2014 at 06:35:00PM -0500, Hu Yaohui wrote:
> Thanks a lot Marcelo!
>
> On Wed, Jan 8, 2014 at 6:25 PM, Marcelo Tosatti wrote:
> > On Wed, Jan 08, 2014 at 06:14:15PM -0500, Hu Yaohui wrote:
> >> Hi guys,
> >> I think you should be pretty fa
On Wed, Jan 08, 2014 at 06:14:15PM -0500, Hu Yaohui wrote:
> Hi guys,
> I think you should be pretty familiar with lapic. I would really
> appreciate it if someone could shed some lights on my problem
> regarding Guest TLB flush IPI.
> Supposed we get two vcpus 0 and 1.
> When vcpu#0 wants to inval
On Thu, Jan 02, 2014 at 05:14:11PM +0800, Chen Fan wrote:
> fix the 'vcpi' typos when apic_debug is enabled.
>
> Signed-off-by: Chen Fan
> ---
> arch/x86/kvm/lapic.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Applied, thanks.
--
To unsubscribe from this list: send the line "
Linus,
Please pull from
git://git.kernel.org/pub/scm/virt/kvm/kvm.git master
To receive the following KVM bug fixes
Jan Kiszka (2):
KVM: x86: Fix APIC map calculation after re-enabling
KVM: nVMX: Unconditionally uninit the MMU on nested vmexit
arch/x86/kvm/lapic.c |8 ---
On Sat, Dec 21, 2013 at 10:14:09AM -0800, Randy Dunlap wrote:
> On 12/21/13 08:21, Masanari Iida wrote:
> > Correct spelling typo in Documentations/virtual/kvm
> >
> > Signed-off-by: Masanari Iida
>
> Acked-by: Randy Dunlap
>
> Thanks.
Applied, thanks.
--
To unsubscribe from this list: send
On Thu, Dec 05, 2013 at 11:30:27PM +0800, Xiao Guangrong wrote:
> In some cases, the lockless walker will do endless-walking on desc and
> without rewalk, consider this case:
>
> there are two descs: desc1 and desc2 who is pointed by desc1->next：
> desc1->next = desc2.
>
> CPU 0
On Thu, Dec 05, 2013 at 11:30:27PM +0800, Xiao Guangrong wrote:
> > Is it not the case that simply moving to the slow path once a maximum of
> > rewalks has been reached enough? (looks a like a good solution).
>
> In some cases, the lockless walker will do endless-walking on desc and
> without rew
GOn Tue, Dec 03, 2013 at 03:10:48PM +0800, Xiao Guangrong wrote:
> On 11/28/2013 04:53 PM, Xiao Guangrong wrote:
> > On 11/27/2013 03:31 AM, Marcelo Tosatti wrote:
> >> On Tue, Nov 26, 2013 at 11:21:37AM +0800, Xiao Guangrong wrote:
> >>> On 11/26/2013 02:12 AM, Ma
On Tue, Nov 26, 2013 at 11:21:37AM +0800, Xiao Guangrong wrote:
> On 11/26/2013 02:12 AM, Marcelo Tosatti wrote:
> > On Mon, Nov 25, 2013 at 02:29:03PM +0800, Xiao Guangrong wrote:
> >>>> Also, there is no guarantee of termination (as long as sptes are
> >>>>
On Tue, Nov 26, 2013 at 11:10:19AM +0800, Xiao Guangrong wrote:
> On 11/25/2013 10:23 PM, Marcelo Tosatti wrote:
> > On Mon, Nov 25, 2013 at 02:48:37PM +0200, Avi Kivity wrote:
> >> On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
> >> wrote:
> >>>
>
On Mon, Nov 25, 2013 at 02:29:03PM +0800, Xiao Guangrong wrote:
> >> Also, there is no guarantee of termination (as long as sptes are
> >> deleted with the correct timing). BTW, can't see any guarantee of
> >> termination for rculist nulls either (a writer can race with a lockless
> >> reader indef
GOn Mon, Nov 25, 2013 at 04:29:28PM +0200, Gleb Natapov wrote:
> On Mon, Nov 25, 2013 at 12:23:51PM -0200, Marcelo Tosatti wrote:
> > On Mon, Nov 25, 2013 at 02:48:37PM +0200, Avi Kivity wrote:
> > > On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
> > > wrote:
> >
On Mon, Nov 25, 2013 at 02:48:37PM +0200, Avi Kivity wrote:
> On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
> wrote:
> >
> > On Nov 23, 2013, at 3:14 AM, Marcelo Tosatti wrote:
>
>
>
> I'm not really following, but note that parent_pte predates EPT (and
&
On Mon, Nov 25, 2013 at 02:11:31PM +0800, Xiao Guangrong wrote:
>
> On Nov 23, 2013, at 3:14 AM, Marcelo Tosatti wrote:
>
> > On Wed, Oct 23, 2013 at 09:29:25PM +0800, Xiao Guangrong wrote:
> >> It likes nulls list and we use the pte-list as the nulls which can help
On Wed, Oct 23, 2013 at 09:29:25PM +0800, Xiao Guangrong wrote:
> It likes nulls list and we use the pte-list as the nulls which can help us to
> detect whether the "desc" is moved to anther rmap then we can re-walk the rmap
> if that happened
>
> kvm->slots_lock is held when we do lockless walkin
On Wed, Nov 20, 2013 at 10:20:09PM +0800, Xiao Guangrong wrote:
> > But what guarantee does userspace require, from GET_DIRTY_LOG, while vcpus
> > are
> > executing?
>
> Aha. Single calling GET_DIRTY_LOG is useless since new dirty page can be
> generated
> when GET_DIRTY_LOG is being returned.
On Tue, Nov 19, 2013 at 10:29:20PM -0200, Marcelo Tosatti wrote:
> A call to GET_DIRTY_LOG guarantees to return correct information about
> dirty pages before invocation of the previous GET_DIRTY_LOG call.
> Can you explain why it is OK to relax this rule?
That is, this might be OK, b
On Wed, Aug 07, 2013 at 12:06:49PM +0800, Xiao Guangrong wrote:
> On 08/07/2013 09:48 AM, Marcelo Tosatti wrote:
> > On Tue, Jul 30, 2013 at 09:02:02PM +0800, Xiao Guangrong wrote:
> >> Make sure we can see the writable spte before the dirt bitmap is visible
> >
move the entry: when a spte is deleted, we move the entry in the first
>desc to that position
>
> Both of these also can reduce cache miss
>
> Signed-off-by: Xiao Guangrong
Reviewed-by: Marcelo Tosatti
--
To unsubscribe from this list: send the line "unsubscribe linux
On Fri, Nov 15, 2013 at 03:09:13PM +0800, Xiao Guangrong wrote:
> On 11/15/2013 02:39 AM, Marcelo Tosatti wrote:
> > On Thu, Nov 14, 2013 at 01:15:24PM +0800, Xiao Guangrong wrote:
> >>
> >> Hi Marcelo,
> >>
> >> On 11/14/2013 08:36 AM, Marcelo Tosa
On Thu, Nov 14, 2013 at 01:15:24PM +0800, Xiao Guangrong wrote:
>
> Hi Marcelo,
>
> On 11/14/2013 08:36 AM, Marcelo Tosatti wrote:
>
> >
> > Any code location which reads the writable bit in the spte and assumes if
> > its not
> > set, that the tran
ons(+), 18 deletions(-)
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 Wed, Oct 23, 2013 at 09:29:22PM +0800, Xiao Guangrong wrote:
> Now we can flush all the TLBs out of the mmu lock without TLB corruption when
> write-proect the sptes, it is because:
> - we have marked large sptes readonly instead of dropping them that means we
> just change the spte from writa
LE_LEVEL level) can be fast fixed
>
> Signed-off-by: Xiao Guangrong
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/
!!! At this point, the shadow page can still
> be
> writable due to the corrupt tlb entry
> Flush all TLB
>
> Signed-off-by: Xiao Guangrong
Reviewed-by: Marcelo Tosatti
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&
/locking.txt to get more detail.
>*/
> - ret = fast_pf_fix_direct_spte(vcpu, iterator.sptep, spte);
> + ret = fast_pf_fix_direct_spte(vcpu, sp, iterator.sptep, spte);
> exit:
> trace_fast_page_fault(vcpu, gva, error_code, iterator.sptep,
>
p */
> + while (__gfn_to_hva_memslot(slot, gfn) & (page_size - 1))
> + page_size >>= 1;
> +
> /*
>* Pin all pages we are about to map in memory. This is
> * important because we unmap and un
On Fri, Nov 01, 2013 at 10:08:55AM -0600, Greg Edwards wrote:
> When determining the page size we could use to map with the IOMMU, the
> page size should be aligned with the hva, not the gfn. The gfn may not
> reflect the real alignment within the hugetlbfs file.
>
> Most of the time, this works
On Thu, Oct 17, 2013 at 04:50:47PM +0200, Paolo Bonzini wrote:
> The loop was always using 0 as the index. This means that
> any rubbish after the first element of the array went undetected.
> It seems reasonable to assume that no KVM userspace did that.
It is not a typo, look at __kvm_set_xcr wh
On Wed, Oct 16, 2013 at 02:25:00PM -0400, Don Zickus wrote:
> On Fri, Oct 11, 2013 at 09:39:24PM -0300, Marcelo Tosatti wrote:
> > v2:
> > - do not create hung_task.h, move defines to sched.h (Don Zickus)
> > - switch patch order (Paolo)
>
> As long as it solves kvm&
On Wed, Oct 16, 2013 at 12:12:11PM +0300, Gleb Natapov wrote:
> On Tue, Oct 15, 2013 at 07:21:19PM -0300, Marcelo Tosatti wrote:
> > On Tue, Oct 15, 2013 at 06:57:05AM +0300, Gleb Natapov wrote:
> > > >
> > > > Why is it safe to allow access, by the lockless pa
On Tue, Oct 15, 2013 at 06:57:05AM +0300, Gleb Natapov wrote:
> >
> > Why is it safe to allow access, by the lockless page write protect
> > side, to spt pointer for shadow page A that can change to a shadow page
> > pointer of shadow page B?
> >
> > Write protect spte of any page at will? Or ve
On Sat, Oct 12, 2013 at 08:53:56AM +0300, Gleb Natapov wrote:
> On Fri, Oct 11, 2013 at 05:30:17PM -0300, Marcelo Tosatti wrote:
> > On Fri, Oct 11, 2013 at 08:38:31AM +0300, Gleb Natapov wrote:
> > > > n_max_mmu_pages is not a suitable limit to throttle freeing of pages via
In certain occasions it is possible for a hung task detector
positive to be false: continuation from a paused VM, for example.
Add a method to reset detection, similar as is done
with other kernel watchdogs.
Signed-off-by: Marcelo Tosatti
Index: kvm/kernel/hung_task.c
v2:
- do not create hung_task.h, move defines to sched.h (Don Zickus)
- switch patch order (Paolo)
--
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
Ple
Implement reset of kernel watchdogs at pvclock read time. This avoids
adding special code to every watchdog.
This is possible for watchdogs which measure time based on sched_clock() or
ktime_get() variants.
Suggested by Don Zickus.
Signed-off-by: Marcelo Tosatti
Index: kvm/arch/x86/kernel
On Fri, Oct 11, 2013 at 08:38:31AM +0300, Gleb Natapov wrote:
> > n_max_mmu_pages is not a suitable limit to throttle freeing of pages via
> > RCU (its too large). If the free memory watermarks are smaller than
> > n_max_mmu_pages for all guests, OOM is possible.
> >
> Ah, yes. I am not saying n_
On Thu, Oct 10, 2013 at 10:16:46PM +0300, Gleb Natapov wrote:
> On Thu, Oct 10, 2013 at 01:42:22PM -0300, Marcelo Tosatti wrote:
> > On Thu, Oct 10, 2013 at 03:08:45PM +0300, Gleb Natapov wrote:
> > > On Wed, Oct 09, 2013 at 10:47:10PM -0300, Marcelo Tosatti wrote:
> >
On Thu, Oct 10, 2013 at 03:08:45PM +0300, Gleb Natapov wrote:
> On Wed, Oct 09, 2013 at 10:47:10PM -0300, Marcelo Tosatti wrote:
> > > >> Gleb has a idea that uses RCU_DESTORY to protect the shadow page table
> > > >> and encodes the page-level into th
On Wed, Oct 09, 2013 at 06:45:47PM +0800, Xiao Guangrong wrote:
> On 10/09/2013 09:56 AM, Marcelo Tosatti wrote:
> > On Tue, Oct 08, 2013 at 12:02:32PM +0800, Xiao Guangrong wrote:
> >>
> >> Hi Marcelo,
> >>
> >> On Oct 8, 2013, at 9:23 AM, Marcelo T
On Wed, Oct 09, 2013 at 09:55:19AM -0400, Don Zickus wrote:
> On Tue, Oct 08, 2013 at 07:08:11PM -0300, Marcelo Tosatti wrote:
> > On Tue, Oct 08, 2013 at 09:37:05AM -0400, Don Zickus wrote:
> > > On Mon, Oct 07, 2013 at 10:05:17PM -0300, Marcelo Tosatti wrote:
> > >
On Tue, Oct 08, 2013 at 11:58:10AM +0200, Paolo Bonzini wrote:
> Il 08/10/2013 03:05, Marcelo Tosatti ha scritto:
> > +void pvclock_touch_watchdogs(void)
> > +{
> > + touch_softlockup_watchdog_sync();
> > + clocksource_touch_watchdog();
On Tue, Oct 08, 2013 at 12:02:32PM +0800, Xiao Guangrong wrote:
>
> Hi Marcelo,
>
> On Oct 8, 2013, at 9:23 AM, Marcelo Tosatti wrote:
>
> >>
> >> + if (kvm->arch.rcu_free_shadow_page) {
> >> + kvm_mmu_isolate_pages(invalid_list);
>
On Tue, Oct 08, 2013 at 09:37:05AM -0400, Don Zickus wrote:
> On Mon, Oct 07, 2013 at 10:05:17PM -0300, Marcelo Tosatti wrote:
> > Implement reset of kernel watchdogs at pvclock read time. This avoids
> > adding special code to every watchdog.
> >
> > This is possible
On Thu, Sep 05, 2013 at 06:29:15PM +0800, Xiao Guangrong wrote:
> It is easy if the handler is in the vcpu context, in that case we can use
> walk_shadow_page_lockless_begin() and walk_shadow_page_lockless_end() that
> disable interrupt to stop shadow page being freed. But we are on the ioctl
> con
Please ignore patch 3/3 - there is none.
--
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/
See individual patches for details.
--
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/
In certain occasions it is possible for a hung task detector
positive to be false: continuation from a paused VM, for example.
Add a method to reset detection, similar as is done
with other kernel watchdogs.
Signed-off-by: Marcelo Tosatti
Index: kvm/kernel/hung_task.c
Implement reset of kernel watchdogs at pvclock read time. This avoids
adding special code to every watchdog.
This is possible for watchdogs which measure time based on sched_clock() or
ktime_get() variants.
Suggested by Don Zickus.
Signed-off-by: Marcelo Tosatti
Index: kvm/arch/x86/kernel
--
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 Thu, Sep 05, 2013 at 06:29:08PM +0800, Xiao Guangrong wrote:
> Now we can flush all the TLBs out of the mmu lock without TLB corruption when
> write-proect the sptes, it is because:
> - we have marked large sptes readonly instead of dropping them that means we
> just change the spte from writa
On Thu, Sep 05, 2013 at 06:29:06PM +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 Thu, Sep 05, 2013 at 06:29:05PM +0800, Xiao Guangrong wrote:
> Using sp->role.level instead of @level since @level is not got from the
> page table hierarchy
>
> There is no issue in current code since the fast page fault currently only
> fixes the fault caused by dirty-log that is always on th
On Wed, Aug 07, 2013 at 12:06:49PM +0800, Xiao Guangrong wrote:
> On 08/07/2013 09:48 AM, Marcelo Tosatti wrote:
> > On Tue, Jul 30, 2013 at 09:02:02PM +0800, Xiao Guangrong wrote:
> >> Make sure we can see the writable spte before the dirt bitmap is visible
> >
On Tue, Jul 30, 2013 at 09:02:02PM +0800, Xiao Guangrong wrote:
> Make sure we can see the writable spte before the dirt bitmap is visible
>
> We do this is for kvm_vm_ioctl_get_dirty_log() write-protects the spte based
> on the dirty bitmap, we should ensure the writable spte can be found in rmap
; - dma_clear_pte(pte);
> > - }
> > - pte++;
> > - tmp += level_size(level);
> > - } while (!first_pte_in_page(pte) &&
> > -
On Fri, Aug 02, 2013 at 11:42:19PM +0800, Xiao Guangrong wrote:
>
> On Aug 2, 2013, at 10:55 PM, Marcelo Tosatti wrote:
>
> > On Tue, Jul 30, 2013 at 09:02:01PM +0800, Xiao Guangrong wrote:
> >> Currently, kvm zaps the large spte if write-protected is needed, the late
On Tue, Jul 30, 2013 at 09:02:01PM +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 Thu, Jul 11, 2013 at 11:10:25AM +0300, Gleb Natapov wrote:
> On Wed, Jul 10, 2013 at 10:21:57PM -0300, Marcelo Tosatti wrote:
> >
> > Linux as a guest on KVM hypervisor, the only user of the pvclock
> > vsyscall interface, does not require notification on task m
is increased whenever underlying CPU
changes.
Which is sufficient to guarantee nanoseconds counter
is calculated properly.
Signed-off-by: Marcelo Tosatti
diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
index 109a9dd..be8269b 100644
--- a/arch/x86/include/asm
On Wed, Jul 03, 2013 at 12:44:01PM -0400, Don Zickus wrote:
> On Fri, Jun 28, 2013 at 05:37:39PM -0300, Marcelo Tosatti wrote:
> > On Fri, Jun 28, 2013 at 10:12:15AM -0400, Don Zickus wrote:
> > > On Thu, Jun 27, 2013 at 11:57:23PM -0300, Marcelo Tosatti wrote:
> > > >
On Wed, Jul 03, 2013 at 12:44:01PM -0400, Don Zickus wrote:
> > And why overcommitment is not a valid reason to generate a softlockup in
> > the first place ?
>
> For the guest I don't believe it is. It isn't the guest's fault it
> couldn't run processes. A warning should be scheduled on the hos
On Fri, Jun 28, 2013 at 10:12:15AM -0400, Don Zickus wrote:
> On Thu, Jun 27, 2013 at 11:57:23PM -0300, Marcelo Tosatti wrote:
> >
> > One possibility for a softlockup report in a Linux VM, is that the host
> > system is overcommitted to the point where the watchdog task
the default),
and report this increment in the softlockup message.
Overcommitment is then indicated by a large stolen time increment,
accounting for more than, or for a significant percentage of the
softlockup threshold.
Signed-off-by: Marcelo Tosatti
diff --git a/kernel/watchdog.c b/kernel
On Mon, Jun 24, 2013 at 06:52:44PM -0400, Prarit Bhargava wrote:
>
>
> On 06/24/2013 03:01 PM, Chegu Vinod wrote:
> >
> > Hello,
> >
> > Lots (~700+) of the following messages are showing up in the dmesg of a
> > 3.10-rc1
> > based kernel (Host OS is running on a large socket count box with HT
contention in QEMU.
Add conditional resched points in between writes allowing other tasks to
execute.
Signed-off-by: Marcelo Tosatti
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index 5855d17..0dd6d96 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console
On Mon, Jun 17, 2013 at 07:59:15PM +0800, Xiao Guangrong wrote:
> Sorry for the delay reply since i was on vacation.
>
> On 06/15/2013 10:22 AM, Takuya Yoshikawa wrote:
> > On Thu, 13 Jun 2013 21:08:21 -0300
> > Marcelo Tosatti wrote:
> >
> >> On Fri, Ju
On Sat, Jun 15, 2013 at 10:01:45PM +0400, Eugene Batalov wrote:
> Due to unintialized kvmclock read KVM guest is hanging on SMP boot stage.
> If unintialized memory contains fatal garbage then hang reproduction is 100%.
> Unintialized memory is allocated by memblock_alloc. So the garbage values
> d
On Fri, Jun 07, 2013 at 04:51:22PM +0800, Xiao Guangrong wrote:
> Changelog:
> V3:
> All of these changes are from Gleb's review:
> 1) rename RET_MMIO_PF_EMU to RET_MMIO_PF_EMULATE.
> 2) smartly adjust kvm generation number in kvm_current_mmio_generatio()
> to avoid kvm_memslots->generat
o 1 > events/kvm/kvm_write_tsc_offset/enable
>
> 2. boot a guest
>
> Signed-off-by: Yoshihiro YUNOMAE
> Cc: Joerg Roedel
> Cc: Marcelo Tosatti
> Cc: Gleb Natapov
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> ---
> arch/x86/
On Mon, Jun 10, 2013 at 07:38:34PM +0300, Gleb Natapov wrote:
> > Guest traces contain vcpu number and not pid (because guest is unaware
> > of host PID).
> >
> No, guest trace is just a regular ftrace done inside a guest. It contains
> guest's PIDs which is useless for host.
# tracer: nop
#
# e
501 - 600 of 1340 matches
Mail list logo
