linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility check
Date: Tue, 16 Apr 2013 18:40:52 +0200	[thread overview]
Message-ID: <6327a7cba36fe46cb3787617a8f10420@localhost> (raw)
In-Reply-To: <CAEDV+gKbmbdg-xX2Zf5febaeJv5TzLdLZZ5ZrEX9xGc0zsdZQw@mail.gmail.com>

On Tue, 16 Apr 2013 09:24:03 -0700, Christoffer Dall
<cdall@cs.columbia.edu> wrote:
> On Mon, Apr 15, 2013 at 5:26 PM, Geoff Levand <geoff@infradead.org>
wrote:
>> On Sun, 2013-04-14 at 21:57 -0700, Christoffer Dall wrote:
>>> On Fri, Apr 12, 2013 at 6:24 AM, Marc Zyngier <marc.zyngier@arm.com>
>>> wrote:
>>> Nak. The fact that one of the CPUs seem to hang is a sure sign that
>>> > something is severely broken, and you definitely want to fix that
>>> > issue,
>>> > instead of blindly ignoring it.
>>> >
>>> > Additionally, it seems you're just papering over the issue. You
should
>>> > be able to exclude the A7 processors, but not completely deny KVM
from
>>> > running on the hardware.
>>> >
>>> Marc, I disagree with this nak. If the current kernel breaks boot on a
>>> Big.Little system, we need to take care of that first, and the
>>> proposed patch is a quick way to do so, and it does not stand in the
>>> way of introducing proper Big.Little support in any way, which I'm
>>> sure is going to open up a lot of other interesting questions.
>>>
>>> I'm going to take this one.
>>
>> Since this problem will cause the 3.9 kernel to hang then a workaround
>> like this should go in.  There isn't enough time to do a proper fix for
>> 3.9, and even if it could be done I think it would be too intrusive to
>> get merged this late.
>>
> That's why I was inclined to take the patch, but as Marc pointed out
> the error message is incorrect, so that should be fixed at the very
> least. Also I don't think we need the counting logic, just bail out if
> we have any CPUs that are not supported.
> 
> Marc, since you're the strongest opponent of this patch, are you still
> opposed to making sure we don't try to run KVM on Big.Little until
> support is properly introduced?

Nothing I've seen so far proves that BL isn't working. Yes, we know the
guest side is going to break. But the host should be solid, and if it
isn't, let's fix it. What we've seen so far is an A15 hanging (Andre's
trace), and Alexander's weird problem with the third A7 hanging. So far,
I'd be inclined to say that BL is working well enough for that bug to be
reproduced on both sides.

> I also cannot see how we can fix the affinity issue easily from within
> the kernel, do you have a concrete approach in mind you can share?

My idea was to check the affinity of the vcpu thread, compare it to the
"KVM affinity", and force it to the intersection of these two sets
(rescheduling if not on an A15). If the intersection is null, just give up.

Not pretty, but ensures nothing gets scheduled on an A7.

        M.
-- 
Fast, cheap, reliable. Pick two.

  reply	other threads:[~2013-04-16 16:40 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-12 13:04 [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility check Andre Przywara
2013-04-12 13:24 ` Marc Zyngier
2013-04-12 13:40   ` Peter Maydell
2013-04-12 13:49     ` Marc Zyngier
2013-04-17 10:19       ` Russell King - ARM Linux
2013-04-17 10:35         ` Marc Zyngier
2013-04-17 11:07           ` Christoffer Dall
2013-04-17 11:30             ` Marc Zyngier
2013-04-17 11:38               ` Peter Maydell
2013-04-17 11:42                 ` Alexander Graf
2013-04-17 11:45                   ` Christoffer Dall
2013-04-17 12:24                 ` Marc Zyngier
2013-04-17 12:25                   ` Peter Maydell
2013-04-17 12:28                     ` Marc Zyngier
2013-04-17 12:38                       ` Peter Maydell
2013-04-17 13:00                         ` Marc Zyngier
2013-04-17 19:28                           ` Christoffer Dall
2013-04-17 11:38               ` Christoffer Dall
2013-04-12 13:58   ` Andre Przywara
2013-04-12 14:14     ` Marc Zyngier
2013-04-15  4:57   ` Christoffer Dall
2013-04-15  7:50     ` Marc Zyngier
2013-04-15  8:28       ` Christoffer Dall
2013-04-15  8:43         ` Marc Zyngier
2013-04-15  8:54           ` Christoffer Dall
2013-04-15  9:14             ` Peter Maydell
2013-04-15  9:39               ` Andre Przywara
2013-04-15  9:45                 ` Peter Maydell
     [not found]                 ` <CAJRNFKJoBzgt4UhxsH65_LyhcGXPnzB_pg3q-zeYT2OVv59q4A@mail.gmail.com>
2013-04-15 13:13                   ` Andre Przywara
2013-04-15 13:48                     ` Will Deacon
2013-04-15 14:26                       ` Andre Przywara
2013-04-15 14:39                         ` Peter Maydell
2013-04-15 14:53                         ` Alexander Spyridakis
2013-04-16 16:26                       ` Christoffer Dall
2013-04-16 16:33                         ` Marc Zyngier
2013-04-17  8:08                           ` Andre Przywara
2013-04-17  8:16                             ` Marc Zyngier
     [not found]                               ` <CAEDV+g+3nkdvbLdj0m-ZdDKt0JY2vgzhP2AQA2nf=R3h4yTQmQ@mail.gmail.com>
2013-04-19 12:58                                 ` Andre Przywara
2013-04-19 16:13                                   ` Christoffer Dall
2013-04-22 10:36                                     ` Andre Przywara
2013-04-22 11:02                                       ` Marc Zyngier
2013-04-22 11:14                                         ` Marc Zyngier
2013-04-22 14:35                                           ` Andre Przywara
2013-04-16 15:59                   ` Christoffer Dall
2013-04-16 16:03                     ` Christoffer Dall
2013-04-16 18:37                     ` Alexander Spyridakis
2013-04-16 18:43                       ` Alexander Spyridakis
2013-04-16 23:13                       ` Christoffer Dall
2013-04-16  0:26     ` Geoff Levand
2013-04-16 16:24       ` Christoffer Dall
2013-04-16 16:40         ` Marc Zyngier [this message]
2013-04-17  8:01         ` Andre Przywara
  -- strict thread matches above, loose matches on Subject: below --
2013-04-17 10:52 Andre Przywara

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=6327a7cba36fe46cb3787617a8f10420@localhost \
    --to=marc.zyngier@arm.com \
    --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).