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.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, 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 B89B3C5519F for ; Wed, 18 Nov 2020 19:16:37 +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 E98282222C for ; Wed, 18 Nov 2020 19:16:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="EaDCkg9L" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E98282222C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:32920 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kfSwT-0004iA-Rr for qemu-devel@archiver.kernel.org; Wed, 18 Nov 2020 14:16:33 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41188) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kfStU-0003MO-T1 for qemu-devel@nongnu.org; Wed, 18 Nov 2020 14:13:31 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:43501) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1kfStS-0001Gb-KP for qemu-devel@nongnu.org; Wed, 18 Nov 2020 14:13:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605726805; 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=87J+vcO6qyvYbQnUkt6tNwuf2drLnAFSkWK6FLmXjvU=; b=EaDCkg9LOonrWihCro658OsaLRi7+OeEcEr9RGLGEA4w8wg/oeipglVOdnK6ZclHvV7IAt J5n8FtTL5TSmQ5RYVHjBkL89OaUgXkHeSSKzQCoXVuDdO2z0nEQNVBj1I6OYPjN9tsZ1HE 7r9qEF1IjPcGAvZCqMufqxK3yoCDc+E= Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-536-N9Btm_RlOdyW0U5EwWtwMw-1; Wed, 18 Nov 2020 14:13:23 -0500 X-MC-Unique: N9Btm_RlOdyW0U5EwWtwMw-1 Received: by mail-ej1-f72.google.com with SMTP id lz20so1246959ejb.13 for ; Wed, 18 Nov 2020 11:13:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=87J+vcO6qyvYbQnUkt6tNwuf2drLnAFSkWK6FLmXjvU=; b=qR9Ecxu6qCTioCm27/6NPmNUBkB85Cf9c196zfrrHf+IS1/l8YlL4bYgrxECaYAan6 1Xvjt+JMxQGn+5xDSsVVXMR74rwtdn/B9ALSsa4WEw6/fkt0CjQ4yyNbYrdlyadgbPev JLF+PKdygXpUEB2G1r7+VSr/Cb95gt2XeWSsTYkg40ICWbB9nbpz642IsLWLlGynfMng 5sMyiY7C6y7+jOAel/uur4Shy6d7TjCuDUn+R1lESRf2f+/1Qwl18pKLCmMFf1IFwUBE IA7aQ/PwipuvB4VtmHVz6s/W1uKw+5CJYl89Tj1oVKA23dyk2uc80jbBmOrE5HaVaWp0 3gqQ== X-Gm-Message-State: AOAM5327tmC6DqAtMYqT0C/XtTNuB00S7oEqIr7IAY6FGxC7coE9eDy9 PxIX399BHit4VgiEqaiymJvrAI3aoH21cGN74c4BnbV0E10k08yx16rNq5NjrjRJgbLr3knngO5 k7B6NJiOvEwIotXk= X-Received: by 2002:a17:906:1a0c:: with SMTP id i12mr24798983ejf.176.1605726802252; Wed, 18 Nov 2020 11:13:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJwOGaEda2S/B2yes+g1TqFZVXr9glnaUxaAiyYWWpc2OxtV2kY8RNfrFp3s4rmlJVxaixL8YQ== X-Received: by 2002:a17:906:1a0c:: with SMTP id i12mr24798939ejf.176.1605726802033; Wed, 18 Nov 2020 11:13:22 -0800 (PST) Received: from ?IPv6:2001:b07:6468:f312:c8dd:75d4:99ab:290a? ([2001:b07:6468:f312:c8dd:75d4:99ab:290a]) by smtp.gmail.com with ESMTPSA id f24sm13954949edx.90.2020.11.18.11.13.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Nov 2020 11:13:21 -0800 (PST) To: Eduardo Habkost References: <20201118102936.25569-9-cfontana@suse.de> <20201118124845.GC1509407@habkost.net> <6093de34-807d-3840-5402-4769385dd894@suse.de> <8f829e99-c346-00bc-efdd-3e6d69cfba35@redhat.com> <20201118143643.GF1509407@habkost.net> <20201118152552.GG1509407@habkost.net> <20201118161119.GJ1509407@habkost.net> <20201118173055.GM1509407@habkost.net> From: Paolo Bonzini Subject: Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU Message-ID: Date: Wed, 18 Nov 2020 20:13:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <20201118173055.GM1509407@habkost.net> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=pbonzini@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=63.128.21.124; envelope-from=pbonzini@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/17 19:41:43 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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: , Cc: Laurent Vivier , Bruce Rogers , Thomas Huth , Stefano Stabellini , Paul Durrant , Olaf Hering , Jason Wang , Marcelo Tosatti , qemu-devel@nongnu.org, Peter Xu , Dario Faggioli , Roman Bolshakov , Cameron Esfahani , Colin Xu , Wenchao Wang , Anthony Perard , haxm-team@intel.com, Sunil Muthuswamy , Richard Henderson , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , Claudio Fontana Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 18/11/20 18:30, Eduardo Habkost wrote: >> Adding a layer of indirect calls is not very different from monkey patching >> though. > > I'm a little bothered by monkey patching, but I'm more > bothered by having to: > > (1) register (module_init()) a function (kvm_cpu_accel_register()) that > (2) register (accel_register_call()) a function (kvm_cpu_accel_init()) that > (3) register (x86_cpu_accel_init()) a data structure (X86CPUAccel kvm_cpu_accel) that > (4) will be saved in multiple QOM classes, so that > (5) we will call the right X86CPUClass.accel method at the right moment > (common_class_init(), instance_init(), realizefn()), > where: > step 4 must be done before any CPU object is created > (otherwise X86CPUAccel.instance_init & X86CPUAccel.realizefn > will be silently ignored), and > step 3 must be done after all QOM types were registered. > >> You also have to consider that accel currently does not exist in usermode >> emulators, so that's an issue too. I would rather get a simple change in >> quickly, instead of designing the perfect class hierarchy. > > It doesn't have to be perfect. I agree that simple is better. > > To me, registering a QOM type and looking it up when necessary is > simpler than the above. Even if it's a weird class having no > object instances. It probably could be an interface type. Registering a QOM type still has quite some boilerplate. Also registering a QOM type has a public side effect (shows up in qom-list-types). In general I don't look at QOM unless I want its property mechanism, but maybe that's just me. >> Perhaps another idea would be to allow adding interfaces to classes >> *separately from the registration of the types*. Then we can use it to add >> SOFTMMU_ACCEL and I386_ACCEL interfaces to a bare bones accel class, and >> add the accel object to usermode emulators. > > I'm not sure I follow. What do you mean by bare bones accel > class, and when exactly would you add the new interfaces to the > classes? A bare bones accel class would not have init_machine and setup_post methods; those would be in a TYPE_SOFTMMU_ACCEL interface. It would still have properties (such as tb-size for TCG) and would be able to register compat properties. Where would I add it, I don't know. It could be a simple public wrapper around type_initialize_interface() if we add a new MODULE_INIT_* phase after QOM. Or without adding a new phase, it could be a class_type->array of (interface_type, init_fn) hash table. type_initialize would look up the class_type by name, add the interfaces would to the class with type_initialize_interface, and then call the init_fn to fill in the vtable. Paolo