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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 58DB9D30000 for ; Fri, 18 Oct 2024 12:30:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=NG7zGDxhiPRDpcFZR5Y55rGJs4/cOwK4rTpIZ8xc9yA=; b=mSpfgoOLz8qpYOOJHlUlUEtcRN iLih0s/6kUC9H8kfaA9NusoWEv5ug99MW0egWqN6ifPr8Imn7mlx1SwlhK9xPtKEk37z62nmnd8vL QU9M639P305Ok4+m1xQFW+qT2QP1GkXnlcjX944luE35Um1rh0ENms9yO2RKA0JE9G9fSof+NklMN jn4qPfe87Wa0llMOK9hSnON7rq2aULjZ9i0YivM3zED030H89ROGFCp1a9pkwU39/4zuDhYOe1sGa MVXGvJSu/+H7rlOC7FHxKXqd7Mt3IyNWs92bX5YQAUlFkEqtWmPC7e2pXyK32oojxrS3xO2PD9xeE RUUwonFw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t1m7I-00000000kjP-44X7; Fri, 18 Oct 2024 12:30:04 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t1m5p-00000000kak-2cad for linux-arm-kernel@lists.infradead.org; Fri, 18 Oct 2024 12:28:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1729254512; 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: in-reply-to:in-reply-to:references:references; bh=NG7zGDxhiPRDpcFZR5Y55rGJs4/cOwK4rTpIZ8xc9yA=; b=d61VbeF4DnqGshdgAaYWVljA1IhfKR7kypGvGnVO09nLwG6xDg934+che6b4gRRiMKBxQ5 wUKsUW0EIAVnApIhSokGONo88pQOYYQtXNGoFWN0D6un3pUOeyz0978WpJsA5HSXnrO0Rz IX+nBz105K3cfratVYRx1AzIYTVZI2g= Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-449-RgX3D5w1MKiSZnhc_agrwQ-1; Fri, 18 Oct 2024 08:28:27 -0400 X-MC-Unique: RgX3D5w1MKiSZnhc_agrwQ-1 Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 68AF819560AE; Fri, 18 Oct 2024 12:28:24 +0000 (UTC) Received: from localhost (dhcp-192-244.str.redhat.com [10.33.192.244]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D1C1A195607C; Fri, 18 Oct 2024 12:28:21 +0000 (UTC) From: Cornelia Huck To: Shameerali Kolothum Thodi , "eric.auger@redhat.com" , Oliver Upton , Marc Zyngier Cc: "kvmarm@lists.linux.dev" , "catalin.marinas@arm.com" , "will@kernel.org" , "mark.rutland@arm.com" , yuzenghui , "Wangzhou (B)" , jiangkunkun , Jonathan Cameron , Anthony Jebson , "linux-arm-kernel@lists.infradead.org" , Linuxarm Subject: RE: [RFC PATCH 0/6] KVM: arm64: Errata management for VM Live migration In-Reply-To: <432569c372284ddba8ed29f09595390e@huawei.com> Organization: "Red Hat GmbH, Sitz: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Handelsregister: Amtsgericht =?utf-8?Q?M=C3=BCnchen=2C?= HRB 153243, =?utf-8?Q?Gesch=C3=A4ftsf=C3=BChrer=3A?= Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross" References: <20241011075053.80540-1-shameerali.kolothum.thodi@huawei.com> <86jzef53iz.wl-maz@kernel.org> <3f4469c49625413f9ab2c224d0d3fbea@huawei.com> <86ikty6f1b.wl-maz@kernel.org> <08261a41b9644f5ab49063824e4060c3@huawei.com> <87bjziraou.fsf@redhat.com> <7df21c56-0b07-4112-839e-ef90c5999fcd@redhat.com> <432569c372284ddba8ed29f09595390e@huawei.com> User-Agent: Notmuch/0.38.3 (https://notmuchmail.org) Date: Fri, 18 Oct 2024 14:28:19 +0200 Message-ID: <875xppr3x8.fsf@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241018_052833_768847_2027838E X-CRM114-Status: GOOD ( 38.91 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Oct 18 2024, Shameerali Kolothum Thodi wrote: >> -----Original Message----- >> From: Eric Auger >> Sent: Thursday, October 17, 2024 6:16 PM >> To: Cornelia Huck ; Shameerali Kolothum Thodi >> ; Oliver Upton >> ; Marc Zyngier >> Cc: kvmarm@lists.linux.dev; catalin.marinas@arm.com; will@kernel.org; >> mark.rutland@arm.com; yuzenghui ; Wangzhou >> (B) ; jiangkunkun >> ; Jonathan Cameron >> ; Anthony Jebson >> ; linux-arm-kernel@lists.infradead.org; >> Linuxarm >> Subject: Re: [RFC PATCH 0/6] KVM: arm64: Errata management for VM Live >> migration >> >> Hi Shameer, >> >> On 10/17/24 17:49, Cornelia Huck wrote: >> > On Fri, Oct 11 2024, Shameerali Kolothum Thodi >> wrote: >> > >> >>> -----Original Message----- >> >>> From: Oliver Upton >> >>> Sent: Friday, October 11, 2024 4:11 PM >> >>> To: Marc Zyngier >> >>> Cc: Shameerali Kolothum Thodi >> >>> ; kvmarm@lists.linux.dev; >> >>> catalin.marinas@arm.com; will@kernel.org; mark.rutland@arm.com; >> >>> cohuck@redhat.com; eric.auger@redhat.com; yuzenghui >> >>> ; Wangzhou (B) >> ; >> >>> jiangkunkun ; Jonathan Cameron >> >>> ; Anthony Jebson >> >>> ; linux-arm-kernel@lists.infradead.org; >> >>> Linuxarm >> >>> Subject: Re: [RFC PATCH 0/6] KVM: arm64: Errata management for VM >> Live >> >>> migration >> >>> >> >>> On Fri, Oct 11, 2024 at 12:43:28PM +0100, Marc Zyngier wrote: >> >>>> On Fri, 11 Oct 2024 11:57:10 +0100, Shameerali Kolothum Thodi >> >>> wrote: >> >>>>>>> Please take a look and let me know your thoughts. >> >>>>>> Having eyeballed this very superficially, I think we can do >> something >> >>>>>> simpler, and maybe more future-proof: >> >>>>> Thanks Marc for taking a look and the quick feedback. >> >>>> No worries, that's the least I could do given that you put the effort >> >>>> implementing my silly ideas! ;-) >> >>>> >> >>>>>> - I don't think KVM should be concerned about the description of >> the >> >>>>>> target CPUs. The hypercall you defined is the right thing to do, >> >>>>>> but the VMM should completely handle it. That's an >> implementation >> >>>>>> detail, but it would make things much simpler. >> >>>>> Ok. So does that mean the hypercall will use some sort of shared >> >>> memory >> >>>>> to retrieve the list of target CPUs from VMM? >> >>>> Two possibilities: >> >>>> >> >>>> - either shared memory, in which case the hypercall would require the >> >>>> guest to give an IPA and size for the VMM to write its stuff into >> >>>> the guest memory, >> >>>> >> >>>> - or more simply return the data as an MIDR/REVIDR pair in registers, >> >>>> the guest requesting an index, and getting an error when out of >> >>>> range, leaving it with the freedom to organise the storage. >> >>>> >> >>>> The second option is a bit slower, but way simpler, and it only >> >>>> happens once per guest boot, so it would probably be my preferred >> >>>> option unless this is proved to be impractical. >> >>> Also worth noting there's existing UAPI [*] for allowing userspace to >> >>> register range(s) of hypercalls that it services directly. It's a bit >> >>> weird that we'd allow userspace to do stuff in KVM's own hypercall >> >>> range, but I don't think it really matters at this point since this is >> >>> all prototyping. >> >>> >> >>> [*]: https://docs.kernel.org/virt/kvm/devices/vm.html#attribute-kvm- >> arm- >> >>> vm-smccc-filter-w-o >> >> Thanks. Yes and there are attempts to add that handling in Qemu[*] in >> the context >> >> of vCPU hotplug support(PSCI related ones though). Will take a look. >> >> >> >> Thanks, >> >> Shameer >> >> [1] https://lore.kernel.org/qemu-devel/20241009033704.250287-1- >> salil.mehta@huawei.com/ >> > Speaking of QEMU: Do you maybe already have some prototype code that >> > tries to do something with the setup here? (I don't think QEMU currently >> > mucks around with MIDR and friends when running with KVM; I wonder >> what >> > it should provide to the guest and if it should care to set something as >> > a base level that gives guests not using the hypercall a chance to work >> > properly.) > > I had a hacked Qemu to test this RFC. Nothing fancy but just to verify the RFC. > It basically adds a named CPU to virt as below, > > 1. Checks the host MIDR and REVIDR and if it is one of the supported platforms, > use the writable register interface to update the ID registers with a common > minimum feature list. > 2. Use the IOCTL in this RFC to update the target CPU list info. > 3. Ignore the invariant register SET errors. Thanks for sharing this information (no need to share the code, I usually do not want to share my hacked-together-for-testing code, either :) > >> > >> As discussed during the KVM forum we are working on a qemu integration >> for writable ID regs. The first goal is to be able to specialize the >> host passthrough model (custom host model). Maybe this will trigger more >> discussions on named models too. This is complementary to the >> MIDR/REVIDR problematic and I hope we will be able to consolidate our >> works at some point. > > Cool!. Happy to know that it is making progress. Once I rework this RFC based on the > suggestions, I will rework the Qemu to have a hacked prototype to test it as well and > probably can share that. The reason I asked was mostly to get a feel about how you wanted to end up using the interface. Did I understand correctly that you derive your custom set of features from whatever comes as common features with the MIDR/REVIDR, and do not treat "frankencpu with features common across all possible targets" and "list of MIDR/REVIDR for all possible targets" separately and tack them together in the end? It would also be interesting to discuss what actual named models could look like (models we could use for baselining etc.) But that's probably something that needs to be discussed on qemu-devel anyway, and I certainly don't want to derail the discussions about the KVM changes. (Agreeing on QEMU interfaces is going to take a lot of work anyway :) > > Please keep me in loop if you have plans to share your Qemu work soon. That will > be very helpful. > > Thanks, > Shameer