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=-5.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 9550AC433DF for ; Thu, 15 Oct 2020 06:09:03 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 D0EDC22249 for ; Thu, 15 Oct 2020 06:09:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="2RoTFnj/"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mg.codeaurora.org header.i=@mg.codeaurora.org header.b="eVtpAcx2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D0EDC22249 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Date:Message-ID:Subject:From:To: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=gCY/e6XDuW91tb/baBlcUZt3fAyEfLPw9wr6YDfLVvI=; b=2RoTFnj/9msDfYZhCrqQItsQDZ 6p77S6UxjjX7ww+zjF0MKgiIgnUcs8FOWzecxfjqonV1S/dUGLlp00a/Ux0XxiukP35XgLKMxJlBn Tk3fZBxyMFfqeFgtnTMSzwE7pTLDRSAlHJRsOJoOjAo/06yyhY5QnDW4sdKYkhlPKN+XK832lIiqr wKSfYsEJrK8sTpylq+d33cF3ZNI6tvYGVlQbPTkBpt/IuCKv1eLIxpiA+iPgoNkn9xHlIQekA2fkh Lg7IyFIK5SxuZcT4GQwyVOG7jjMXNyOAc8R6VtQEjEMdKe2S876vbcdeBUFIGgAA0wc/8CdSPhgPi oSdod10g==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSwQ7-0001AR-CX; Thu, 15 Oct 2020 06:07:23 +0000 Received: from m42-4.mailgun.net ([69.72.42.4]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSwQ1-000196-1V for linux-arm-kernel@lists.infradead.org; Thu, 15 Oct 2020 06:07:20 +0000 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1602742038; h=Content-Transfer-Encoding: Content-Type: MIME-Version: Date: Message-ID: Subject: From: Cc: To: Sender; bh=3YpwQ8vNPH2kYO0S+h4JavGJgn0OjQHCMmUoLuwkYtk=; b=eVtpAcx2JAjDdGXRxaluaea0JycwAR/WgR2Gy6zoTvqV7I702bEZilmbHnaeAhXzX5fzUPXs 4MkIL6p8cTG5DJdHZo50f/qgffMLnX97Du2gfnvdwNRlFf/sI9xMM1RQ+MN1v53aMOQ0zwCo BxNPLYcZc3pXWzjpYaNe3cKWL9s= X-Mailgun-Sending-Ip: 69.72.42.4 X-Mailgun-Sid: WyJiYzAxZiIsICJsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmciLCAiYmU5ZTRhIl0= Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n03.prod.us-east-1.postgun.com with SMTP id 5f87e710d63768e57b430f91 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Thu, 15 Oct 2020 06:07:12 GMT Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 239BDC433FF; Thu, 15 Oct 2020 06:07:12 +0000 (UTC) Received: from [192.168.0.102] (unknown [49.206.34.248]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: neeraju) by smtp.codeaurora.org (Postfix) with ESMTPSA id 7D5D5C433C9; Thu, 15 Oct 2020 06:07:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 7D5D5C433C9 Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=fail smtp.mailfrom=neeraju@codeaurora.org To: james.morse@arm.com From: Neeraj Upadhyay Subject: Queries on ARM SDEI Linux kernel code Message-ID: Date: Thu, 15 Oct 2020 11:37:07 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201015_020719_152177_0F2B1C65 X-CRM114-Status: GOOD ( 16.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: lkml , linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi James, Have few queries on ARM SDEI Linux code. Queries are listed below; can you please help provide your insights on these? 1. Looks like interrupt bind interface (SDEI_1_0_FN_SDEI_INTERRUPT_BIND) is not available for clients to use; can you please share information on why it is not provided? While trying to dig information on this, I saw that [1] says: Now the hotplug callbacks save nothing, and restore the OS-view of registered/enabled. This makes bound-interrupts harder to work with. Based on this comment, the changes from v4 [2], which I could understand is, cpu down path does not save the current event enable status, and we rely on the enable status `event->reenable', which is set, when register/unregister, enable/disable calls are made; this enable status is used during cpu up path, to decide whether to reenable the interrupt. Does this make, bound-interrupts harder to work with? how? Can you please explain? Or above save/restore is not the reason and you meant something else? Also, does shared bound interrupts also have the same problem, as save/restore behavior was only for private events? 2. SDEI_EVENT_SIGNAL api is not provided? What is the reason for it? Its handling has the same problems, which are there for bound interrupts? Also, if it is provided, clients need to register event 0 ? Vendor events or other event nums are not supported, as per spec. 3. Can kernel panic() be triggered from sdei event handler? Is it a safe operation? The spec says, synchronous exceptions should not be triggered; I think panic won't do it; but anything which triggers a WARN or other sync exception in that path can cause undefined behavior. Can you share your thoughts on this? "The handler code should not enable asynchronous exceptions by clearing any of the PSTATE.DAIF bits, and should not cause synchronous exceptions to the client Exception level." [1] https://lwn.net/Articles/740817/ [2] https://www.spinics.net/lists/kvm-arm/msg27784.html -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel