linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 6/6] ARM: kvm: TMP: Commit the hyp page tables to main memory
Date: Fri, 15 Nov 2013 00:42:50 +0000	[thread overview]
Message-ID: <20131115004250.GH20516@lvm> (raw)
In-Reply-To: <52856C95.6000102@ti.com>

On Thu, Nov 14, 2013 at 07:36:37PM -0500, Santosh Shilimkar wrote:
> On Thursday 14 November 2013 07:27 PM, Christoffer Dall wrote:
> > On Thu, Nov 14, 2013 at 07:15:44PM -0500, Santosh Shilimkar wrote:
> >> On Thursday 14 November 2013 07:11 PM, Christoffer Dall wrote:
> >>> On Thu, Nov 14, 2013 at 02:37:46PM -0500, Santosh Shilimkar wrote:
> >>>> This is a temporary hack which I have to use to avoid a weired crash while
> >>>> starting the guest OS on Keystsone. They are random crashesh while the
> >>>> guest os userspace starts. Additional data point is, it seen only with first
> >>>> guest OS lanch. Subsequest guest OS starts normal.
> >>>>     
> >>>
> >>> what crashes?  The guest?  Where, how?
> >>>
> >> When guest userspace starts. The crashes are random but always after the
> >> guest init process have started.
> >>  
> > 
> > So you get a guest kernel crash when guest userspace starts?
> > 
> > Are the crashes completely random or is it always some pointer
> > dereference that goes wrong, is it init crashing and causing the kernel
> > to crash (from killed init), or is it always the same kernel thread, or
> > anything coherent at all?
> >
> Completely random. I have seen almost all of the above possible crashes
> like pointer derefence, init process skipping some steps, console going
> for toss, the log in prompt just won't let me log in etc
> 
>  
> > It could be anything, really.  You could try a really brute force
> > debugging option of adding a complete cache flush at the end of
> > user_mem_abort in arch/arm/kvm/mmu.c to see if this is cache related at
> > all...
> >
> I will try that. I strongly suspect this has to do with bad page tables.
> remember I see this issue with when using memory which starts beyond 4GB.
> 
> 

But once it crashes, if you kill the VM process and start a new one,
then the new one runs flawlessly?  Did you stress test the second VM
(hackbench or something) so we're sure the second one is indeed stable?

What happens if you start a guest, kill it immediately, and then start
another guest?

-Christoffer

  reply	other threads:[~2013-11-15  0:42 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-14 19:37 [PATCH 0/6] ARM/AMR64: Few patches on kvm and mm code Santosh Shilimkar
2013-11-14 19:37 ` [PATCH 1/6] arm64: mm: Add __virt_to_idmap() to keep kvm build happy Santosh Shilimkar
2013-11-15 13:34   ` Catalin Marinas
2013-11-15 14:55     ` Santosh Shilimkar
2013-11-15 14:58       ` Catalin Marinas
2013-11-15 15:31         ` Santosh Shilimkar
2013-11-15 15:05   ` Marc Zyngier
2013-11-15 15:25     ` Santosh Shilimkar
2013-11-15 15:29       ` Marc Zyngier
2013-11-15 15:31         ` Catalin Marinas
2013-11-15 15:33           ` Santosh Shilimkar
2013-11-14 19:37 ` [PATCH 2/6] ARM: kvm: Use virt_to_idmap instead of virt_to_phys for idmap mappings Santosh Shilimkar
2013-11-15  0:12   ` Christoffer Dall
2013-11-14 19:37 ` [PATCH 3/6] ARM: mm: Drop the lowmem watermark check from virt_addr_valid() Santosh Shilimkar
2013-11-15  0:22   ` Christoffer Dall
2013-11-15  0:31     ` Santosh Shilimkar
2013-11-15  0:40       ` Christoffer Dall
2013-11-15 11:48         ` Marc Zyngier
2013-11-15 11:43     ` Marc Zyngier
2013-11-15 14:55       ` Santosh Shilimkar
2013-11-15 15:08         ` Marc Zyngier
2013-11-15 15:46           ` Christoffer Dall
2013-11-15 14:20   ` Russell King - ARM Linux
2013-11-15 15:40     ` Santosh Shilimkar
2013-11-14 19:37 ` [PATCH 4/6] arm64: " Santosh Shilimkar
2013-11-15 13:39   ` Catalin Marinas
2013-11-15 14:25     ` Marc Zyngier
2013-11-15 14:57       ` Santosh Shilimkar
2013-11-14 19:37 ` [PATCH 5/6] ARM: kvm: Use phys_addr_t instead of unsigned long in mm code Santosh Shilimkar
2013-11-15  0:09   ` Christoffer Dall
2013-11-15  0:10     ` Santosh Shilimkar
2013-11-15 11:58   ` Marc Zyngier
2013-11-14 19:37 ` [PATCH 6/6] ARM: kvm: TMP: Commit the hyp page tables to main memory Santosh Shilimkar
2013-11-14 22:36   ` Santosh Shilimkar
2013-11-15  0:11   ` Christoffer Dall
2013-11-15  0:15     ` Santosh Shilimkar
2013-11-15  0:27       ` Christoffer Dall
2013-11-15  0:36         ` Santosh Shilimkar
2013-11-15  0:42           ` Christoffer Dall [this message]
2013-11-15  1:19             ` Santosh Shilimkar
2013-11-15  1:35               ` Christoffer Dall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131115004250.GH20516@lvm \
    --to=christoffer.dall@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).