From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 77242C433DF for ; Tue, 9 Jun 2020 17:46:20 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3EFD82081A for ; Tue, 9 Jun 2020 17:46:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Rg8qy68Q" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3EFD82081A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiiJz-0001yu-Eb; Tue, 09 Jun 2020 17:45:59 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiiJy-0001yp-23 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 17:45:58 +0000 X-Inumbo-ID: 12cf4636-aa79-11ea-8496-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 12cf4636-aa79-11ea-8496-bc764e2007e4; Tue, 09 Jun 2020 17:45:57 +0000 (UTC) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BFA39207ED; Tue, 9 Jun 2020 17:45:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591724756; bh=wlYabBiJGc7VSyncs6OWlQqlLE2Ut4rsDNdk6MY5J9I=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Rg8qy68Q9gMeVk5CtcZkF45VwE3MzspL/JUpzmRz3skLNCh6eGTwMSQTVdmOg8MrW Jy1B90gcDxJOdkh94D9fHreCd4KfvEFTY8AbjQFQzOz4h7475vC7kz53ORShzVpraG aIZNqVNIqJAHYxMDteRJUyt+BVwU88IF59uzCQHA= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jiiJv-001WTZ-At; Tue, 09 Jun 2020 18:45:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 09 Jun 2020 18:45:55 +0100 From: Marc Zyngier To: Julien Grall Subject: Re: Keystone Issue In-Reply-To: <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> User-Agent: Roundcube Webmail/1.4.4 Message-ID: <6033f9cecbf10f50f4a713ce52105426@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: julien@xen.org, Bertrand.Marquis@arm.com, codewiz2280@gmail.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org, nd@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , CodeWiz2280 , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Julien, On 2020-06-09 18:32, Julien Grall wrote: > (+ Marc) > > On 09/06/2020 18:03, Bertrand Marquis wrote: >> Hi >> >>> On 9 Jun 2020, at 16:47, Julien Grall wrote: >>> >>> >>> >>> On 09/06/2020 16:28, Bertrand Marquis wrote: >>>> Hi, >>>>> On 9 Jun 2020, at 15:33, CodeWiz2280 wrote: >>>>> >>>>> There does appear to be a secondary (CIC) controller that can >>>>> forward >>>>> events to the GIC-400 and EDMA controllers for the keystone 2 >>>>> family. >>>>> Admittedly, i'm not sure how it is being used with regards to the >>>>> peripherals. I only see mention of the GIC-400 parent for the >>>>> devices >>>>> in the device tree. Maybe Bertrand has a better idea on whether >>>>> any >>>>> peripherals go through the CIC first? I see that gic_interrupt () >>>>> fires once in Xen, which calls doIRQ to push out the virtual >>>>> interrupt >>>>> to the dom0 kernel. The dom0 kernel then handles the interrupt and >>>>> returns, but gic_interrupt() never fires again in Xen. >>>> I do not remember of any CIC but the behaviour definitely look like >>>> an interrupt acknowledge problem. >>>> Could you try the following: >>>> --- a/xen/arch/arm/gic-v2.c >>>> +++ b/xen/arch/arm/gic-v2.c >>>> @@ -667,6 +667,9 @@ static void gicv2_guest_irq_end(struct irq_desc >>>> *desc) >>>> /* Lower the priority of the IRQ */ >>>> gicv2_eoi_irq(desc); >>>> /* Deactivation happens in maintenance interrupt / via GICV */ >>>> + >>>> + /* Test for Keystone2 */ >>>> + gicv2_dir_irq(desc); >>>> } >>>> I think the problem I had was related to the vgic not deactivating >>>> properly the interrupt. >>> >>> Are you suggesting the guest EOI is not properly forwarded to the >>> hardware when LR.HW is set? If so, this could possibly be workaround >>> in Xen by raising a maintenance interrupt every time a guest EOI an >>> interrupt. >> >> Agree the maintenance interrupt would definitely be the right solution > I would like to make sure we aren't missing anything in Xen first. > From what you said, you have encountered this issue in the past with a > different hypervisor. So it doesn't look like to be Xen related. > > Was there any official statement from TI? If not, can we try to get > some input from them first? > > @Marc, I know you dropped 32-bit support in KVM recently :). Although, Yes! Victory is mine! Freedom from the shackles of 32bit, at last! :D > I was wondering if you heard about any potential issue with guest EOI > not forwarded to the host. This is on TI Keystone (Cortex A-15). Not that I know of. A-15 definitely works (TC2, Tegra-K1, Calxeda Midway all run just fine with guest EOI), and GIC-400 is a pretty solid piece of kit (it is just sloooooow...). Thinking of it, you would see something like that if the GIC was seeing the writes coming from the guest as secure instead of NS (cue the early firmware on XGene that exposed the wrong side of GIC-400). Is there some kind of funky bridge between the CPU and the GIC? M. -- Jazz is not dead. It just smells funny...