Received: by 10.223.185.111 with SMTP id b44csp295651wrg; Fri, 9 Mar 2018 05:12:11 -0800 (PST) X-Google-Smtp-Source: AG47ELsuIB0vwwUr3B67Oa3dzNDETF5lfHVCxM71C0oRGSc8o47qPZDxBsMh7m8vsmFJKFhGp/mO X-Received: by 10.98.159.85 with SMTP id g82mr29880172pfe.15.1520601131620; Fri, 09 Mar 2018 05:12:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520601131; cv=none; d=google.com; s=arc-20160816; b=KtkqpimGEZmEbnTvuRRVabKdvSIopUVWbT/wRoCZ+HF39SEDGZ8dXPEExAE5Jy36Xc hcOx9/u6aZ9sBkvlbdLoS75aOc1xDnmn/zvgh9J1/dpXQlkAjbpN+eY+oPPr3VQF4dBC WvrmBILEbCVLWSuJiHO0xIksVh9fOaGHlA6ePtCO60kqQPbX3IzzfvKV6QFcx38UgPoG rj+z8J2cRKCmeA5pcuzixzOkMOsLbx/2T3diXv2BiyuSApARGAVZatoWfKw4Ee8dbaB5 E2q/K09qhJJVYV9lL/0dNrkA5NFiRmscx0xmTNylgIsY8t1mOXt8nIWCihNKozVIa4Nl JI6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:arc-authentication-results; bh=G3XWVUNra5h/f0ydEUARbDwwOoWTSNPcNx+VMhZEHSI=; b=Bqu18nzgZhp/xCmEtY0TgsnnWs+fsl2Sf+Ql0nKO31DLV+bQ8F4cWQxnmCZrXkb6es HTjyQfgJ+o87UPTDSlxD6jnjdY9HZD5XM0wE5nnMeItFXowqPBwomE0BWChxvgunkAMB v3a1S0uWYAG0yTYt5ALX2evj9ljg/tEqhDaqMG5ITowBqj7KOhr/vOraO9cZjVogUehJ vT3BvwaSocp1FWH0Mu6aVEkNAeAFEo2BZge4/7GLplnyRUVj0CYVFEoXuh5vCO45mBDP mIURCjAPr79D/nrDLBE2irLsJbFJAN2uYKDl6w2oMnwcb1nMyWu39eq2YasZpRbcC3A2 DuPw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m16-v6si846299pls.471.2018.03.09.05.11.56; Fri, 09 Mar 2018 05:12:11 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932084AbeCINLC (ORCPT + 99 others); Fri, 9 Mar 2018 08:11:02 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:50756 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751096AbeCINLA (ORCPT ); Fri, 9 Mar 2018 08:11:00 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2269C8182D1E; Fri, 9 Mar 2018 13:11:00 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-135.ams2.redhat.com [10.36.116.135]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4D31D2166BAE; Fri, 9 Mar 2018 13:10:54 +0000 (UTC) Subject: Re: [RFC PATCH] KVM: arm/arm64: vgic: change condition for level interrupt resampling To: Marc Zyngier , "Yang, Shunyong" , "cdall@kernel.org" References: <1520492490-7943-1-git-send-email-shunyong.yang@hxt-semitech.com> <9ad47673-068e-f732-d2ca-9c76a8fbdfbc@arm.com> <0a15633d-8944-cb9b-3e6b-b08ee5ec42b9@arm.com> <20180308161900.GC1917@lvm> <86r2oubho3.wl-marc.zyngier@arm.com> <1520565257.2583.57.camel@hxt-semitech.com> <959b6484-c683-65b2-a1e5-3e3784865682@arm.com> Cc: "ard.biesheuvel@linaro.org" , "david.daney@cavium.com" , "will.deacon@arm.com" , "linux-kernel@vger.kernel.org" , "Zheng, Joey" , "kvmarm@lists.cs.columbia.edu" , "linux-arm-kernel@lists.infradead.org" From: Auger Eric Message-ID: Date: Fri, 9 Mar 2018 14:10:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <959b6484-c683-65b2-a1e5-3e3784865682@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Fri, 09 Mar 2018 13:11:00 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Fri, 09 Mar 2018 13:11:00 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'eric.auger@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marc, On 09/03/18 10:40, Marc Zyngier wrote: > On 09/03/18 03:14, Yang, Shunyong wrote: > > [trimming things a bit] > >>>>>>>> static bool lr_signals_eoi_mi(u32 lr_val) >>>>>>>> { >>>>>>>> - return !(lr_val & GICH_LR_STATE) && (lr_val & >>>>>>>> GICH_LR_EOI) && >>>>>>>> - !(lr_val & GICH_LR_HW); >>>>>>>> + return !((lr_val & GICH_LR_STATE) ^ GICH_LR_STATE) >>>>>>>> && >>>>>>> That feels very wrong. You're now signalling the resampling >>>>>>> in both >>>>>>> invalid and pending+active, and the latter state doesn't mean >>>>>>> you've >>>>>>> EOIed anything. You're now over-signalling, and signalling >>>>>>> the >>>>>>> wrong event. >> >> I am using XOR GICH_LR_STATE(0b'11), so only 0b'11(P&A) will be >> signaled. Other state will be false. > > And that's really wrong. P+A is a state where the interrupt is still > being processed. The only case where we can reliably detect that an > interrupt has been EOId is when state==0. > >> And I am curious why the EOI bit in LR indicate the end of interrupt >> regardless of the state? Please bear with me as I am a newbie in this >> part. > > The EOI bit indicates that we've requested a maintenance interrupt from > the HW. It only triggers when state==0. If you have (like you describe > further down) a sequence of > > P -> A -> (exit) -> P+A -> P -> A -> (exit) P+A ... > > we can never reliably detect that an interrupt has been EOId (because > the HW never delivers a maintenance interrupt), other than by tracking > the states before and after exit, and hoping that you've done an exit > because you're touching the source of the interrupt. > >>>>>> Also, any guideline on how to reproduce this would be much >>>>>> appreciated. >>>>>> I never used this mdev/mtty thing, so please bear with me. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> M. >> >> The mdev/mtty documentation is at Documentation/vfio-mediated- >> device.txt. It docmented how to enable mtty device. >> And support for "vfio-pci,sysfsdev" should be availabe in your qemu >> version (I compiled the latest version). >> Following is my commond to run qemu with mdev support, >> "qemu-system-aarch64 -m 1024 -cpu host -M virt,gic_version=3 -nographic >> \ >> -kernel /home/yangsy/up-kvm/arch/arm64/boot/Image.gz \ >> -initrd /home/yangsy/kvm/ramdisk/initrd.img \ >> -netdev user,id=eth0 -device virtio-net-device,netdev=eth0 -enable-kvm >> \ >> -append "root=/dev/ram rdinit=/sbin/init" \ >> -device vfio-pci,sysfsdev=/sys/bus/mdev/devices/83b8f4f2-509f-382f- >> 3c1e-e6bfe0fa1001 >> " >> For just test this vgic case, type "cat /dev/ttyS0" in guest. But if >> test read/write multiple bytes, please apply following patch also >> https://patchwork.kernel.org/patch/10267039/ > > Thanks. I'll have a look. > >> >>>>>> >>>>>> From 66a7c4cfc1029b0169dd771e196e2876ba3f17b1 Mon Sep 17 >>>>>> 00:00:00 2001 >>>>>> From: Marc Zyngier >>>>>> Date: Thu, 8 Mar 2018 11:14:06 +0000 >>>>>> Subject: [PATCH] KVM: arm/arm64: Do not rely on LR state to >>>>>> guess EOI MI >>>>>> status >>>>>> >>>>>> We so far rely on the LR state to decide whether the guest has >>>>>> EOI'd a level interrupt or not. While this looks like a good >>>>>> idea on the surface, it leads to a couple of annoying corner >>>>>> cases: >>>>>> >>>>>> Example 1: (P = Pending, A = Active, MI = Maintenance >>>>>> Interrupt) >>>>>> P -> guest IAR -> A -> exit/entry -> P+A -> guest EOI -> P -> >>>>>> MI >>>>> Do we really get an EOI maintenance interrupt here? Reading the >>>>> MISR >>>>> and EISR descriptions make me thing this is not the case... >>> Hum yes in EISR it is said that ICH_LR.State = 0b00! >>>> >>>> >>>> Yeah, it looks like I always want EISR to do what I want, and not >>>> to >>>> do what it does. Man, this thing is such a piece of crap. >>>> >>>> OK, scratch that. We need to do it without the help of the HW. >> >> If convenient, maybe we can get something from HW gus. :-) >> >> Hi, Marc, >> >> Do you need me to test the patch you posted for EISR? As it seems there >> are some things need more discussion. > > Yeah, that approach doesn't work. I'll try and come up with another > approach (basically banning P+A for interrupts that require a back > notification). > > [...] > >> I have added some logs to compare level interrupt between pl011(hwirq = >> 33) and mtty (hwirq = 36). In mtty case, vgic_queue_irq_unlock() is >> called twice. But only called once in pl011. >> >> following is the log, >> ===Without my patch=== >> ###PL011### >> >> <4>[ 180.598266] kvm_vgic_inject_irq 453 irq:33 enabled:1 config:1 >> latch:0 level:1 >> <4>[ 180.604460] ##vgic_queue_irq_unlock 388 irq->intid:33 enable:1 >> level:1 >> <4>[ 180.604540] ==>90a0020000000021(active) >> <4>[ 180.614878] ==>d0a0020000000021(P&A) >> <4>[ 180.618415] kvm_vgic_inject_irq 453 irq:33 enabled:1 config:1 >> latch:0 level:0 >> <4>[ 180.625508] ==>90a0020000000021(active) >> <4>[ 180.629343] ==>10a0020000000021(inactive) >> >> ###mtty-vfio### >> <4>[ 223.123329] kvm_vgic_inject_irq 453 irq:36 enabled:0 config:1 >> latch:0 level:1 >> <4>[ 223.129736] ##vgic_queue_irq_unlock 388 irq->intid:36 enable:1 >> level:1 >> <4>[ 223.136027] ==>50a0020000000024(pending) >> <4>[ 223.139954] ##vgic_queue_irq_unlock 388 irq->intid:36 enable:1 >> level:1 >> <4>[ 223.146460] ==>90a0020000000024(active) >> <4>[ 223.150273] ==>d0a0020000000024(P&A) >> <4>[ 223.153827] ==>90a0020000000024(active) >> <4>[ 223.157668] ==>d0a0020000000024(P&A) > > So the line is never lowered. That's very odd. > >> ...........cyclic... >> >> I rembered in some tests the state change is cyclic P->A->P&A. But it >> seems I cannot reproduce it. Is output LR state >> in kvm_vgic_inject_irq() reliable? >> >> ===With my patch=== >> ###PL011### >> <4>[ 114.798528] kvm_vgic_inject_irq 453 irq:33 enabled:1 config:1 >> latch:0 level:1 >> <4>[ 114.804743] ##vgic_queue_irq_unlock 388 irq->intid:33 enable:1 >> level:1 >> <4>[ 114.804796] ==>90a0020000000021(active) >> <4>[ 114.815077] ==>d0a0020000000021(P&A) >> <4>[ 114.818628] kvm_vgic_inject_irq 453 irq:33 enabled:1 config:1 >> latch:0 level:0 >> <4>[ 114.825726] ==>90a0020000000021(active) >> <4>[ 114.829560] ==>10a0020000000021(inactive) >> >> ###mtty-vfio### >> >> <4>[ 161.579083] kvm_vgic_inject_irq 453 irq:36 enabled:0 config:1 >> latch:0 level:1 >> <4>[ 161.585419] ##vgic_queue_irq_unlock 388 irq->intid:36 enable:1 >> level:1 >> <4>[ 161.591780] ==>50a0020000000024(pending) >> <4>[ 161.595708] ##vgic_queue_irq_unlock 388 irq->intid:36 enable:1 >> level:1 >> <4>[ 161.602204] ==>90a0020000000024(active) >> <4>[ 161.606023] ==>d0a0020000000024(P&A) >> <4>[ 161.609561] kvm_vgic_inject_irq 453 irq:36 enabled:1 config:1 >> latch:0 level:0 >> <4>[ 161.616693] ==>10a0020000000024(inactive) >> <4>[ 161.620745] kvm_vgic_inject_irq 453 irq:36 enabled:1 config:1 >> latch:0 level:1 >> <4>[ 161.627800] ##vgic_queue_irq_unlock 388 irq->intid:36 enable:1 >> level:1 >> <4>[ 161.627849] ==>90a0020000000024(active) >> <4>[ 161.640076] ==>d0a0020000000024(P&A) >> <4>[ 161.642689] kvm_vgic_inject_irq 453 irq:36 enabled:1 config:1 >> latch:0 level:0 >> <4>[ 161.649822] ==>10a0020000000024(inactive) > > Which is really bizarre. The device only lowers the line when it is > being told that the interrupt has been processed. That really smells of > a bug in the device emulation. It should be lowered when the guest > clears the interrupt status at the device level, and not when notified > that the interrupt has been completed at the interrupt controller level. Not sure I get what you mean. To me the guest driver may have properly acked the interrupt at HW level. But this cannot lower the virtual line level. The virtual line level only is set when an interrupt hits and the VFIO irq handler signals the irqfd. only the resamplefd can lower the virtual line level. There is no communication between the VFIO driver and KVM to lower the virtual line level. Note the resamplefd also is used to unmask the interrupt on VFIO driver side. Thanks Eric > > Thanks, > > M. >