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=-9.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,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 27923C433F5 for ; Tue, 14 Sep 2021 02:20:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0ECBC60F24 for ; Tue, 14 Sep 2021 02:20:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237732AbhINCWA (ORCPT ); Mon, 13 Sep 2021 22:22:00 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:34038 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238318AbhINCVw (ORCPT ); Mon, 13 Sep 2021 22:21:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1631586035; h=from:from: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=rcYJHx/4UcJXZGKmDo86svliqJbYFIRBfH+q9c03jV8=; b=TnHw1ihxeqPgn2RmlTE5nT5D0L/+yP+zqcvUy/6pzOtxw1vW/RD6sB3S6A6tTdqf8Xz+9G 5nOCM6wdWt6ME27C1sq+g79Phn+rHXfQwUtbxrOx1nEj74TFgxUslQP2122sl9llQzlC1F K7NanROu/3R4pJz3di0f7ivSStJhmH8= Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-410-5xHKaJR1OD2fUzjbk_EB1A-1; Mon, 13 Sep 2021 22:20:34 -0400 X-MC-Unique: 5xHKaJR1OD2fUzjbk_EB1A-1 Received: by mail-pg1-f198.google.com with SMTP id h10-20020a65404a000000b00253122e62a0so8524236pgp.0 for ; Mon, 13 Sep 2021 19:20:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=rcYJHx/4UcJXZGKmDo86svliqJbYFIRBfH+q9c03jV8=; b=NKT6VLv5SGGmccAxcEZaXtDGgX+6UkOyTEM2rF25X5PwLHOPxiC8JfuoG12ujITNjz fn5QSGOzu89Eh7AxjOHn9XVXd0dggmh6SQFjnzItyUQ9K7V8jr/3kt+/H0Ph5LiIlKf4 e+gaR3cAOhXIvfeg6f6jiL73yPKsedH2NK0MGTxxJ4qLnoFcmGVfgZ3dmnJwM0GEy7b1 GnbtL8fdCav/TaFdNABG598zkew594x8w8iBLt1/L4BGv6L6qxwi5d/5lXU+VyNQK1XZ 05gSbyykHu2UPRcb/Nh184HQwSdmhivt1g2aMrrURz9GLWXL1wgB/Lg3/B8QK9pw773Y auzA== X-Gm-Message-State: AOAM5308ghRoItrUbwbfDSzkxq8+BXMdSDDuErssLooSp4FpKmme04C1 NOtr7d25HLJyHNK9PJUZt5mE2YNYOZP3CrKozXHaTsuLS4xHuKdyqdiKMc8wBtPGBl8rmxk1t2g IfnhoLTx5251whfzxWl53do2e X-Received: by 2002:a17:902:bcc6:b0:138:d3ca:c356 with SMTP id o6-20020a170902bcc600b00138d3cac356mr12957356pls.6.1631586033278; Mon, 13 Sep 2021 19:20:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwTi2t9kwRmgzAkZOi4siQl5/JqG3e4HK5NmMFCXfex3BVoLj5jj59CSw0hkzWSUkEcyY9uOw== X-Received: by 2002:a17:902:bcc6:b0:138:d3ca:c356 with SMTP id o6-20020a170902bcc600b00138d3cac356mr12957317pls.6.1631586033012; Mon, 13 Sep 2021 19:20:33 -0700 (PDT) Received: from wangxiaodeMacBook-Air.local ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id g3sm7944621pjm.22.2021.09.13.19.20.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Sep 2021 19:20:32 -0700 (PDT) Subject: Re: [PATCH 6/9] virtio_pci: harden MSI-X interrupts To: Thomas Gleixner , "Michael S. Tsirkin" Cc: virtualization , linux-kernel , "Hetzelt, Felicitas" , "kaplan, david" , Konrad Rzeszutek Wilk , pbonzini , Andi Kleen , Dan Williams , "Kuppuswamy, Sathyanarayanan" , Ingo Molnar , Borislav Petkov , Peter Zijlstra , Andy Lutomirski , Bjorn Helgaas , Richard Henderson , Thomas Bogendoerfer , James E J Bottomley , Helge Deller , "David S . Miller" , Arnd Bergmann , Jonathan Corbet , Peter H Anvin , Dave Hansen , Tony Luck , Kirill Shutemov , Sean Christopherson , Kuppuswamy Sathyanarayanan , X86 ML References: <20210913055353.35219-1-jasowang@redhat.com> <20210913055353.35219-7-jasowang@redhat.com> <20210913015711-mutt-send-email-mst@kernel.org> <20210913022257-mutt-send-email-mst@kernel.org> <20210913023626-mutt-send-email-mst@kernel.org> <20210913024153-mutt-send-email-mst@kernel.org> <87bl4wfeq1.ffs@tglx> <20210913164934-mutt-send-email-mst@kernel.org> <87sfy8ds53.ffs@tglx> From: Jason Wang Message-ID: <98ddcf92-b0c8-77c3-d1ca-9855896a2600@redhat.com> Date: Tue, 14 Sep 2021 10:20:19 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <87sfy8ds53.ffs@tglx> Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ÔÚ 2021/9/14 ÉÏÎç6:31, Thomas Gleixner дµÀ: > On Mon, Sep 13 2021 at 16:54, Michael S. Tsirkin wrote: > >> On Mon, Sep 13, 2021 at 09:38:30PM +0200, Thomas Gleixner wrote: >>> On Mon, Sep 13 2021 at 15:07, Jason Wang wrote: >>>> On Mon, Sep 13, 2021 at 2:50 PM Michael S. Tsirkin wrote: >>>>>> But doen't "irq is disabled" basically mean "we told the hypervisor >>>>>> to disable the irq"? What extractly prevents hypervisor from >>>>>> sending the irq even if guest thinks it disabled it? >>>>> More generally, can't we for example blow away the >>>>> indir_desc array that we use to keep the ctx pointers? >>>>> Won't that be enough? >>>> I'm not sure how it is related to the indirect descriptor but an >>>> example is that all the current driver will assume: >>>> >>>> 1) the interrupt won't be raised before virtio_device_ready() >>>> 2) the interrupt won't be raised after reset() >>> If that assumption exists, then you better keep the interrupt line >>> disabled until virtio_device_ready() has completed >> started not completed. device is allowed to send >> config interrupts right after DRIVER_OK status is set by >> virtio_device_ready. > Whatever: > > * Define the exact point from which on the driver is able to handle the > interrupt and put the enable after that point > > * Define the exact point from which on the driver is unable to handle > the interrupt and put the disable before that point Yes, this is exactly what this patch (and INTX patch) want to achieve. The driver should only able to handle the interrupt after virtio_device_ready() but before reset(). Thanks > > The above is blury. > >>> and disable it again >>> before reset() is invoked. That's a question of general robustness and >>> not really a question of trusted hypervisors and encrypted guests. >> We can do this for some MSIX interrupts, sure. Not for shared interrupts though. > See my reply to the next patch. The problem is the same: > > * Define the exact point from which on the driver is able to handle the > interrupt and allow the handler to proceed after that point > > * Define the exact point from which on the driver is unable to handle > the interrupt and ensure that the handler denies to proceed before > that point > > Same story just a different mechanism. > > Thanks, > > tglx >