All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Andre Przywara <andre.przywara@calxeda.com>,
	Julien Grall <julien.grall@linaro.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [ARM] Bash often segfaults in Dom0 with the latest Xen
Date: Wed, 5 Jun 2013 10:52:22 +0100	[thread overview]
Message-ID: <1370425942.24512.172.camel@zakaz.uk.xensource.com> (raw)
In-Reply-To: <CAMJs5B_4A2cgybq_xERKgLF+yibtUqJFz2G8rDAZhko61hNq6g@mail.gmail.com>

On Tue, 2013-06-04 at 18:38 -0700, Christoffer Dall wrote:
>  - Does dom0 run with Stage-2 translation?

Yes.

>  If so, you should be able
> to disable caches in both Hyp mode and for dom0 by manipulating the
> hyp registers to try and exclude caches. If Linux doesn't boot under
> such configuration, something else is completely broken, as it must be
> transparent to your dom0.

For some reason I had it in my head that the monitor used by the
load/store exclusive instructions was somehow tied to the cache
controller (i.e. you can't use them with caching disabled) which makes
it impossible to disable caching if you are using them in your spinlock
routines.

I can't actually find anything to that affect in the ARM ARM now though
-- Am/was I imagining things?

>  - Are you doing any swapping and/or page reclaiming?

At the hypervisor level you mean? No.

dom0 might be swapping itself but I don't think that is what you meant
and I expect Julien doesn't have a swap device configured in any case.

> - All other cache accesses should be coherent across cores and are
> physically indexed/physically tagged so I don't see how this could be
> your issue.

Agreed.

> - Are you managing the VMID properly across physical CPU migration?
> (ensure that dom0 always uses the same vmid regardless of the physical
> cpu)

Currently VMID = DOMID + 1 so yes.

Ian.

  reply	other threads:[~2013-06-05  9:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-04 22:45 [ARM] Bash often segfaults in Dom0 with the latest Xen Julien Grall
2013-06-05  1:38 ` Christoffer Dall
2013-06-05  9:52   ` Ian Campbell [this message]
2013-06-05 11:48   ` Julien Grall
2013-06-05 14:30     ` Christoffer Dall
2013-06-05 15:18       ` Ian Campbell
2013-06-05 16:12       ` Julien Grall
2013-06-05 16:46         ` Stefano Stabellini
2013-06-05 17:36         ` Christoffer Dall
2013-06-05 17:53           ` Julien Grall
2013-06-05 17:57             ` Christoffer Dall
2013-06-05 18:01               ` Stefano Stabellini
2013-06-05 18:17                 ` Christoffer Dall
2013-06-05 18:36                   ` Julien Grall
2013-06-11 11:48   ` Julien Grall
2013-06-11 14:25     ` Christoffer Dall
2013-06-05  9:38 ` Ian Campbell
2013-06-05 10:39   ` Julien Grall

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=1370425942.24512.172.camel@zakaz.uk.xensource.com \
    --to=ian.campbell@citrix.com \
    --cc=Stefano.Stabellini@eu.citrix.com \
    --cc=andre.przywara@calxeda.com \
    --cc=christoffer.dall@linaro.org \
    --cc=julien.grall@linaro.org \
    --cc=xen-devel@lists.xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.