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=-2.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY,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 28A20C433C1 for ; Thu, 25 Mar 2021 02:38:59 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 F3B6D61A13 for ; Thu, 25 Mar 2021 02:38:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F3B6D61A13 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=c-sky.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:46068 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lPFtg-0008BM-Pw for qemu-devel@archiver.kernel.org; Wed, 24 Mar 2021 22:38:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36632) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lPFt3-0007mA-KP for qemu-devel@nongnu.org; Wed, 24 Mar 2021 22:38:17 -0400 Received: from mail142-23.mail.alibaba.com ([198.11.142.23]:39334) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lPFt0-0003jH-MA for qemu-devel@nongnu.org; Wed, 24 Mar 2021 22:38:17 -0400 X-Alimail-AntiSpam: AC=CONTINUE; BC=0.1057777|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.0268789-0.00141912-0.971702; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047201; MF=zhiwei_liu@c-sky.com; NM=1; PH=DS; RN=1; RT=1; SR=0; TI=SMTPD_---.JpraRpj_1616639865; Received: from 10.0.2.15(mailfrom:zhiwei_liu@c-sky.com fp:SMTPD_---.JpraRpj_1616639865) by smtp.aliyun-inc.com(10.147.41.121); Thu, 25 Mar 2021 10:37:45 +0800 To: qemu-devel@nongnu.org From: LIU Zhiwei Subject: Questions about qtest on interrupt controller Message-ID: Date: Thu, 25 Mar 2021 10:37:31 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------512567F3AF4969EAC4EFF1A2" Content-Language: en-US Received-SPF: none client-ip=198.11.142.23; envelope-from=zhiwei_liu@c-sky.com; helo=mail142-23.mail.alibaba.com X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" This is a multi-part message in MIME format. --------------512567F3AF4969EAC4EFF1A2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi folks, When I am writing  qtest  cases for an interrupt controller,  I encounter some problems. *1) Can't intercept both the irq in and irq out for the same device.* It's a necessary feature for an interrupt controller qtest. However, as you can see  from qtest.c,  when a device has intercepted irq out or irq in, it can't intercept another. " if (irq_intercept_dev) {             qtest_send_prefix(chr);             if (irq_intercept_dev != dev) {                 qtest_send(chr, "FAIL IRQ intercept already enabled\n");             } else {                 qtest_send(chr, "OK\n");             }             return; } " In my opinion,  this code in qtest is protecting from intercepting irqs repeatedly. But irq in and out are different directions, they should be intercepted simultaneously. Is it right? *2) Can't get  the right IRQ num.* If  I  intercept an IRQ out,  I can get the num of IRQ if the IRQ raises, .  But the really IRQ I want to get is the IRQ that the interrupt controller selected out. However I can't get this IRQ from qtest_irq_handler. Are there already some methods to surmount these problems?  Any advice is well appreciated. Thanks very much. Zhiwei --------------512567F3AF4969EAC4EFF1A2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi folks,

When I am writing  qtest  cases for an interrupt controller,  I encounter some problems.

1) Can't intercept both the irq in and irq out for the same device.

It's a necessary feature for an interrupt controller qtest. However, as you can see  from qtest.c,  when a device has intercepted irq out or irq in, it can't intercept another.

"
	if (irq_intercept_dev) {
            qtest_send_prefix(chr);
            if (irq_intercept_dev != dev) {
                qtest_send(chr, "FAIL IRQ intercept already enabled\n");
            } else {
                qtest_send(chr, "OK\n");
            }
            return;
	}
"

In my opinion,  this code in qtest is protecting from intercepting irqs repeatedly. But irq in and out are different directions, they should be intercepted simultaneously. Is it right?

2) Can't get  the right IRQ num.

If  I  intercept an IRQ out,  I can get the num of IRQ if the  IRQ raises, .  But the really IRQ I want to get is the IRQ that the interrupt controller selected out. However I can't get this IRQ from qtest_irq_handler.

Are there already some methods to surmount these problems?  Any advice is well appreciated. Thanks very much.

Zhiwei


--------------512567F3AF4969EAC4EFF1A2--