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=-3.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 25222C433DF for ; Tue, 13 Oct 2020 14:31:53 +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 B920620797 for ; Tue, 13 Oct 2020 14:31:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=citrix.com header.i=@citrix.com header.b="ZnoGxfOF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B920620797 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=citrix.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.6256.16677 (Exim 4.92) (envelope-from ) id 1kSLKw-0002eN-2C; Tue, 13 Oct 2020 14:31:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 6256.16677; Tue, 13 Oct 2020 14:31:34 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kSLKv-0002eG-VM; Tue, 13 Oct 2020 14:31:33 +0000 Received: by outflank-mailman (input) for mailman id 6256; Tue, 13 Oct 2020 14:31:33 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kSLKu-0002eB-Ve for xen-devel@lists.xenproject.org; Tue, 13 Oct 2020 14:31:33 +0000 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b06388ef-72c6-41c1-8d04-d86572adeab9; Tue, 13 Oct 2020 14:31:31 +0000 (UTC) Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kSLKu-0002eB-Ve for xen-devel@lists.xenproject.org; Tue, 13 Oct 2020 14:31:33 +0000 X-Inumbo-ID: b06388ef-72c6-41c1-8d04-d86572adeab9 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b06388ef-72c6-41c1-8d04-d86572adeab9; Tue, 13 Oct 2020 14:31:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1602599491; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=iDo8FB4WmMtlZfau0epF9uABoNlYLbVDVOagXTbSFWw=; b=ZnoGxfOFCB7IPx1An806voamNE2FSoVHbnGwJ4YIvPajfqMxTvAQRXsZ 1k53takEcsHkdszKsX0i+/nphHekNh4AKL4rAvAFpgU1OS3a6jUhPxpYh jYYp5+lfqKP8ew4FEHH51cZl2c87AxXZuq4gzTJBTEb+ZV5Y7DkqG0EKo 0=; Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: rJTEUAUpSIF3w8Y+dF/haT23n5jHUbv36bMw98Rv2kxrfE55nZe7EQmOP7dIwmdEyKNWMLA8n4 Ssvw/Wr4mL0gLeiXzlXjGj2V2ADTLrZSbk7E7wG9EYuWJfbHrPkyrQkaqCrxvGAXgL+JlFvy2W H1pbU7FaazmR/KX/lDwSwmic6Qt3RFPyeEt13gasVSx1X569AXIBJiA88u2BFEznNQN3MvrN3z ZIPVxeuNsM6xoEIRyTO0geMBXwyZA5AfGY1Pffw/KKlNWmlJPApHhWRPMwxbmcUAaf7tJOgcI+ rr8= X-SBRS: 2.5 X-MesageID: 28897343 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.77,371,1596513600"; d="scan'208";a="28897343" Date: Tue, 13 Oct 2020 16:30:28 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich CC: , Andrew Cooper , Wei Liu Subject: Re: [PATCH v2 03/11] x86/vlapic: introduce an EOI callback mechanism Message-ID: <20201013143028.GQ19254@Air-de-Roger> References: <20200930104108.35969-1-roger.pau@citrix.com> <20200930104108.35969-4-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To FTLPEX02CL06.citrite.net (10.13.108.179) On Fri, Oct 02, 2020 at 11:39:50AM +0200, Jan Beulich wrote: > On 30.09.2020 12:41, Roger Pau Monne wrote: > > Add a new vlapic_set_irq_callback helper in order to inject a vector > > and set a callback to be executed when the guest performs the end of > > interrupt acknowledgment. > > On v1 I did ask > > "One thing I don't understand at all for now is how these > callbacks are going to be re-instated after migration for > not-yet-EOIed interrupts." > > Afaics I didn't get an answer on this. Oh sorry, I remember your comment and I've changed further patches to address this. The setter of the callback will be in charge for setting the callback again on resume. That's why vlapic_set_callback is not a static function, and is added to the header. Patch 5/11 [0] contains an example of hw the vIO-APIC resets the callbacks on load. > > > --- > > RFC: should callbacks also be executed in vlapic_do_init (which is > > called by vlapic_reset). We would need to make sure ISR and IRR > > are cleared using some kind of test and clear atomic functionality to > > make this race free. > > I guess this can't be decided at this point of the series, as it > may depend on what exactly the callbacks mean to do. It may even > be that whether a callback wants to do something depends on > whether it gets called "normally" or from vlapic_do_init(). Well, lets try to get some progress on the other questions and we will eventually get here I think. > > --- a/xen/arch/x86/hvm/vlapic.c > > +++ b/xen/arch/x86/hvm/vlapic.c > > @@ -144,7 +144,32 @@ bool vlapic_test_irq(const struct vlapic *vlapic, uint8_t vec) > > return vlapic_test_vector(vec, &vlapic->regs->data[APIC_IRR]); > > } > > > > -void vlapic_set_irq(struct vlapic *vlapic, uint8_t vec, uint8_t trig) > > +void vlapic_set_callback(struct vlapic *vlapic, unsigned int vec, > > + vlapic_eoi_callback_t *callback, void *data) > > +{ > > + unsigned long flags; > > + unsigned int index = vec - 16; > > + > > + if ( !callback || vec < 16 || vec >= X86_NR_VECTORS ) > > + { > > + ASSERT_UNREACHABLE(); > > + return; > > + } > > + > > + spin_lock_irqsave(&vlapic->callback_lock, flags); > > + if ( vlapic->callbacks[index].callback && > > + vlapic->callbacks[index].callback != callback ) > > + printk(XENLOG_G_WARNING > > + "%pv overriding vector %#x callback %ps (%p) with %ps (%p)\n", > > + vlapic_vcpu(vlapic), vec, vlapic->callbacks[index].callback, > > + vlapic->callbacks[index].callback, callback, callback); > > + vlapic->callbacks[index].callback = callback; > > + vlapic->callbacks[index].data = data; > > Should "data" perhaps also be compared in the override check above? Could do, there might indeed be cases where the callback is the same but data has changed and should be interesting to log. Thanks, Roger. [0] https://lore.kernel.org/xen-devel/20200930104108.35969-6-roger.pau@citrix.com/