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=-7.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 4F937C433E0 for ; Fri, 3 Jul 2020 00:29:39 +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 1758720781 for ; Fri, 3 Jul 2020 00:29:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="XK/SRw7y"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="HAS87BeR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1758720781 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com 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:Reply-To:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=1pE9+kVODL9bp1Ezvwb2aH8YuerEwPckfM2RE3p+z6Y=; b=XK/SRw7ykHJuxD DA0C+5aCKYpZutRGKIp1NU5Uoru1cz6kuagIhwm+SIxK67sgo657HWCisDmHYXar1y/4b7IjB17QX pLYFDeZxJaiZrEBzi0MwhL0co0G7YKWjFrpys7pKRbwnLXe6HegJjLzYGcxLKasLb4ob97vuNiRDj ab8GyAaaSzlxMq0a1VZBntKvpG1FpfIG464ZGErdsnAC4mVTwtDYrWs5t6OZv4LArGvpEw4rkm3yQ HKhuP3DkM4VhGiZq6oDCvuQEy1FYEpggQb9JLd3wtweZp8DTFS15l/FMMcu8NwuxQscfBN1KLKz06 9AmfMqj3HWuLjoV3Vkvw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jr9Yj-0000Gh-Gg; Fri, 03 Jul 2020 00:28:05 +0000 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120] helo=us-smtp-1.mimecast.com) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jr9Yg-0000CX-Jb for linux-arm-kernel@lists.infradead.org; Fri, 03 Jul 2020 00:28:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593736081; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5KZ7enUnjN7C5Ug217T7ZgxyOrNB92zSCuAMyuPJ5HM=; b=HAS87BeRnZoxkd6fAsATxcgkNNZD9L536N815xmEGObPUpefqQskCW23mt6zqQzja0Dp3r 6wb81DuKgWjeuJW3Z5n9j3YMIjqqqDZ90FrPxL/vnvYkqxUGpEEWNnY0PocbnwbghGLPkW g2yS6k/yx5cW8ZbvlJPEAszyiTrHOeM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-13-oOSvfDtWOuSM4vQibOUpDw-1; Thu, 02 Jul 2020 20:26:26 -0400 X-MC-Unique: oOSvfDtWOuSM4vQibOUpDw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 54C9E800C60; Fri, 3 Jul 2020 00:26:25 +0000 (UTC) Received: from localhost.localdomain (vpn2-54-19.bne.redhat.com [10.64.54.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 380755DAB0; Fri, 3 Jul 2020 00:26:22 +0000 (UTC) Subject: Re: [Question] How to testing SDEI client driver To: James Morse , linux-arm-kernel@lists.infradead.org References: <8cdef8ea-e550-ccff-2041-526d6f6fcda0@redhat.com> From: Gavin Shan Message-ID: <3cc7e69c-9315-5138-85f7-7b36e17b67a1@redhat.com> Date: Fri, 3 Jul 2020 10:26:19 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=gshan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200702_202802_735506_0C8B9E69 X-CRM114-Status: GOOD ( 35.47 ) 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: , Reply-To: Gavin Shan Cc: mark.rutland@arm.com, pbonzini@redhat.com, maz@kernel.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, On 7/1/20 9:57 PM, James Morse wrote: > On 30/06/2020 06:17, Gavin Shan wrote: >> I'm currently looking into SDEI client driver and reworking on it so that >> it can provide capability/services to arm64/kvm to get it virtualized. > > What do you mean by virtualised? The expectation is the VMM would implement the 'firmware' > side of this. 'events' are most likely to come from the VMM, and having to handshake with > the kernel to work out if the event you want to inject is registered and enabled is > over-complicated. Supporting it in the VMM means you can notify a different vCPU if that > is appropriate, or take a different action if the event isn't registered. > > This was all blocked on finding a future-proof way for tools like Qemu to consume > reference code from ATF. > Sorry that I didn't mention the story a bit last time. We plan to use SDEI to deliver the notification (signal) from host to guest, needed by the asynchronous page fault feature. The RFCv2 patchset was post a while ago [1]. For the SDEI events needed by the async page fault, it's originated from KVM (host). In order to achieve the goal, KVM needs some code so that SDEI event can be injected and delivered. Also, the SDEI related hypercalls needs to be handled either. Since we're here, I plan to expand the scope so that the firmware owned SDEI events (private/shared) can be passed through to multiple VMs. Lets say they're passthrou event. For these passthrou events, they can be shared by multiple VMs either. I would call this kind of feature as SDEI virtualization, but there might be better name for it :) [1] https://lore.kernel.org/kvmarm/924ee966-7412-f9ff-c2b0-598e4abbb05c@redhat.com/ > >> The >> primary reason is we want to use SDEI to deliver the asynchronous page fault >> notification from host to guest. > > As an NMI?! Yuck! > The SDEI handler reads memory, you'd need to stop it being re-entrant. It exits through > the IRQ vector, (which is necessary for forward-progress given a synchronous RAS event, > and for KVM to trigger guest-exit before the 'real' work that is offloaded to an irq > handler can run), its going to be 'fun' to have any guarantee of forward-progress if this > is involved with stage2. > Yeah, It's something similar to NMI. The notification (signal) has to be delivered in synchronous mode. Yes, The SDEI specification already mentioned this: the client handler should have all required resources in place before the handler is going to run. However, I don't see it's a problem so far. Lets wait and see if it's a real issue until I post the RFC patchset :) > >> The code of rework on SDEI client driver, including some cleanup, > > Cleanup is always welcome. > Thanks, James. > >> is almost >> done. Currently, I have issues on how to test/verify the client driver. > > ... > >> Any suggestions regarding this are appreciated. > >> It seems that TRF (Trusted Firmware) is the only firmware with SDEI service >> implemented and supported. > > This project calls itself TF-A. ATF is the other widely used name. (I've never seen TRF > before) > Yeah, I must have provided wrong name. Here is the git repo I was looking into: https://github.com/ARM-software/arm-trusted-firmware > >> If so, does it mean I need to install TRF on my bare metal machine? >> I'm wandering how it can be installed and not sure if >> there is any document about this. > > Firmware should come with the platform. You'd need to know intricate details about power > management and initialising parts of the SoC to port it. > > ATF has a port for the fast-model/foundation model. I test this with ATF in the fast-model. > I have no idea of fast-model and foundation model, and I got nothing from below commands in ATF git repo: [gwshan@localhost atf]$ git grep -i fast | grep -i model [gwshan@localhost atf]$ git grep -i fundation | grep -i model > >> Besides, GHES seems the only user of SDEI in the linux kernel. If so, is >> there a way to inject the relevant errors and how? > > It is, and unfortunately last time I checked, upstream ATF doesn't have the firmware-first > stuff for this. Its too SoC specific. > > I test this by binding the fast-model's SP804 one-shot interrupt controller as an event, > then plumbing that into GHES. Its more of case-study in why the bindable-irq stuff is > nasty than usable error injection method. > I can push the most recently rebased version of this, but you'd also need to hack-up a > HEST table with GHES entries to actually get it running. > > > But, unless you are working on EL3 firmare, or a VMM, I don't think SDEI is what you want. > What problem are you trying to solve? > Thanks for the information. It seems I also need to emulate SDEI event by myself in order to test it. The best way for me is to inject SDEI event from KVM. By the way, the code you had is part of the firmware used by bare-metal machine or VM? The issue we want to resolve is to deliver async page fault notification as mentioned above. Please let me know if there are more concerns :) Thanks, Gavin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel