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.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,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 98AEEC433DF for ; Fri, 21 Aug 2020 00:54:08 +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 6719F20702 for ; Fri, 21 Aug 2020 00:54:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="dW53WxAg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6719F20702 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 1k8vJg-0006Jf-1o; Fri, 21 Aug 2020 00:54:00 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1k8vJe-0006JR-Ne for xen-devel@lists.xenproject.org; Fri, 21 Aug 2020 00:53:58 +0000 X-Inumbo-ID: 1d6b0049-dba5-470f-a689-0c5a574c18ae Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1d6b0049-dba5-470f-a689-0c5a574c18ae; Fri, 21 Aug 2020 00:53:58 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (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 214FE20702; Fri, 21 Aug 2020 00:53:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597971237; bh=+MBEQqTqksDVjAqZz4o5NDmvkN+Eddf1emR9wLaRSZQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=dW53WxAgEWr5RTXjIq0ZbYkKrEDHiK+AKn8KjVdBMZjnwmFOeAvkdQCoCNF1lxBZj 8PSqlTK+nEpY5xUI0zIwQLOy+a1BIYp0/cbYZU5OYm11KtZPVU5C/o+mp/4LNDvN9Z l9RNS6Y/FBaiC4Sk2oofeKgORcly4cY+4y5NJdC8= Date: Thu, 20 Aug 2020 17:53:56 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall cc: Stefano Stabellini , Julien Grall , Jan Beulich , Oleksandr Tyshchenko , xen-devel , Oleksandr Tyshchenko , Ian Jackson , Wei Liu , Andrew Cooper , George Dunlap , Volodymyr Babchuk , Julien Grall Subject: Re: [RFC PATCH V1 05/12] hvm/dm: Introduce xendevicemodel_set_irq_level DM op In-Reply-To: Message-ID: References: <1596478888-23030-1-git-send-email-olekstysh@gmail.com> <1596478888-23030-6-git-send-email-olekstysh@gmail.com> <00e261e0-295a-9cd8-ed11-7e3801a4eb58@xen.org> <92e2b136-8468-2877-0e8c-c13ff2a0a1fb@xen.org> <97b477a9-3945-9c5d-671d-ab5cbb2d0468@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, 18 Aug 2020, Julien Grall wrote: > On 11/08/2020 23:48, Stefano Stabellini wrote: > > On Tue, 11 Aug 2020, Julien Grall wrote: > > > > I vaguely > > > > recall a bug 10+ years ago about this with QEMU on x86 and a line that > > > > could be both active-high and active-low. So QEMU would raise the > > > > interrupt but Xen would actually think that QEMU stopped the interrupt. > > > > > > > > To do this right, we would have to introduce an interface between Xen > > > > and QEMU to propagate the trigger type. Xen would have to tell QEMU when > > > > the guest changed the configuration. That would work, but it would be > > > > better if we can figure out a way to do without it to reduce complexity. > > > Per above, I don't think this is necessary. > > > > > > > > > > > Instead, given that QEMU and other emulators don't actually care about > > > > active-high or active-low, if we have a Xen interface that just says > > > > "fire the interrupt" we get away from this kind of troubles. It would > > > > also be more efficient because the total number of hypercalls required > > > > would be lower. > > > > > > I read "fire interrupt" the interrupt as "Please generate an interrupt > > > once". > > > Is it what you definition you expect? > > > > Yes, that is the idea. It would have to take into account the edge/level > > semantic difference: level would have "start it" and a "stop it". > > I am still struggling to see how this can work: > - At the moment, QEMU is only providing us the line state. How can we > deduce the type of the interrupt? Would it mean a major modification of the > QEMU API? Good question. I don't think we would need any major modifications of the QEMU APIs. QEMU already uses two different function calls to trigger an edge interrupt and to trigger a level interrupt. Edge interrupts are triggered with qemu_irq_pulse; level interrupts with qemu_irq_raise/qemu_irq_lower. It is also possible for devices to call qemu_set_irq directly which only has the state of the line represented by the "level" argument. As far as I can tell all interrupts emulated in QEMU (at least the ones we care about) are active-high. We have a couple of choices in the implementation, like hooking into qemu_irq_pulse, and/or checking if the interrupt is level or edge in the xen interrupt injection function. The latter shouldn't require any changes in QEMU common code. FYI looking into the code there is something "strange" in virtio-mmio.c: it only ever calls qemu_set_irq to start a notification. It doesn't look like it ever calls qemu_set_irq to stop a notification at all. It is possible that the state of the line is not accurately emulated for virtio-mmio.c. > - Can you provide a rough sketch how this could be implemented in Xen? It would work similarly to other emulated interrupt injections on the Xen side, calling vgic_inject_irq. We have matching info about level/edge and active-high/active-low in Xen too, so we could do more precise emulation of the interrupt flow, although I am aware of the current limitations of the vgic in that regard. But I have the feeling I didn't address your concern :-)