xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	david.vrabel@citrix.com, xen-devel <xen-devel@lists.xen.org>
Subject: Re: Multiple issues with event channel on Xen on ARM
Date: Wed, 5 Feb 2014 10:45:16 +0000	[thread overview]
Message-ID: <52F2163C.1000202@citrix.com> (raw)
In-Reply-To: <52F1753C.3010508@linaro.org>

On 04/02/14 23:18, Julien Grall wrote:
> Hello David,
> 
> I'm currently trying to use Linux 3.14-rc1 as Linux guest on Xen on ARM (Xen 4.4-rc3).
> 
> I have multiple issues with your event channel patch series on Linux and Xen side.
> I tried to use Linux 3.14-rc1 as dom0 but it was worst (unable to create guests).

I think there must be two issues here as both 2-level and FIFO events
are broken.

> I'm using a simple guest config:
> kernel="/root/zImage"
> memory=32
> name="test"
> vcpus=1
> autoballon="off"
> extra="console=hvc0"
> 
> If everything is ok, I should see that Linux is unable to find the root filesystem.
> But here, Linux is stucked.
> 
>>From Linux side, after bisecting, I found that the offending commit is:
>     xen/events: remove unnecessary init_evtchn_cpu_bindings()
>     
>     Because the guest-side binding of an event to a VCPU (i.e., setting
>     the local per-cpu masks) is always explicitly done after an event
>     channel is bound to a port, there is no need to initialize all
>     possible events as bound to VCPU 0 at start of day or after a resume.
>     
>     Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>     Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>     Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> 
> With this patch, the function __xen_evtchn_do_upcall won't be able
> to find an events (pendings_bits == 0 every time).
> It seems the second part of init_evtchn_cpu_bindings is necessary on ARM.

I think this is because binding an interdomain or allocating an unbound
event channel does call bind_evtchn_to_cpu(evtchn, 0) which is required
to set the local VCPU masks.

I think this happened to work on x86 because during the generic irq
setup, the irq affinity is always set which then binds the event channel
to the right VCPU.  I guess ARM's irq setup misses this step.

This shouldn't affect the FIFO-based events though since
evtchn_fifo_bind_to_cpu() is a no-op.

David

  parent reply	other threads:[~2014-02-05 10:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-04 23:18 Multiple issues with event channel on Xen on ARM Julien Grall
2014-02-05 10:09 ` David Vrabel
2014-02-05 10:33   ` Julien Grall
2014-02-05 10:45 ` David Vrabel [this message]
2014-02-05 13:34   ` David Vrabel
2014-02-05 13:44     ` Julien Grall
2014-02-05 13:52       ` David Vrabel
2014-02-05 13:58         ` 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=52F2163C.1000202@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=julien.grall@linaro.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --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 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).