From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792576046; b=J8kkJJROf76SOVomVRNEE9QTMVT9KwprV/McziaczyAnzB3YQRuomwvp0F5xzC4utw7H Q9KLIrDX7sTPwBkNY8CzfxZITnCVQlRx65vAItHNz3QP6OcU5vUdY4q4yZgK34xu0LnLr Gw8JVh42mtQLP2D96g95IodEP4Nuj43RqWL+LtUykNR6Zjzpz0U46HH8DRRfUACDDOq44 JQXesOj2AjfSXnYxrbq/u0JCJ0g0jSbfpsfN1/ORbUUf/0uG2fpCxzaQoHtkVLa6+YjIj RRUTRw92ZMMlpBXizkiKW6vdQLkrXhsowyqLZUyNatELLBExklKSOTNKZzgy7r7otLw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792576046; h=Received:DKIM-Signature:Date:From:To:Cc:Subject:Message-ID: References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To; bh=dnUnDjOFjw0ANux3in/sgLvd/qDmG3wkK317g+Mf5Fo=; b=tOhGbwe80pN21uZTElcpjWffK5MjPaX/2o3p9G65+MICrnsEGtvfJ1+7CCJPFVwFjJ0K 4YVQifZqINY8zGWUjUR0NGKZCcXzQ3JB3OVhZoKCddbp/kT5I9fFnAK0CBIzDwedMvP7K jK6m70bHpJQpwmnqB3nfAhifd0j9nr0lTg4lwE8E96ogzUQQvjZbnxjNqzhLDvvPzZaKJ bJObUc729QZoVhqwczA4W/7x7DIk7ZAYwR56AxXJU7vNmv+olP8uTDBUu58kpcsIEZYCT WuttIvcYjAwWHQv4kffjR4VcW+8pgg8bs+UfMOV7w/SlJlcO5gVHPHnC3VIbuiW9rpQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=iMK5xies; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A5739606A31A for ; Wed, 21 Oct 2026 09:47:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=iMK5xies Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9AA11F000CA; Wed, 21 Oct 2026 09:47:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792576045; bh=dnUnDjOFjw0ANux3in/sgLvd/qDmG3wkK317g+Mf5Fo=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=iMK5xiesQuJPx3FWVla20YDT/MBk57uKKqrH0LyZ/iO3VebalD42OvSM7F7xWVWwF E1qVsX8cgh1QFHWE6joX6qO6011c1UrNGJ8Gowfmr4WpqtDqfNV1ZGqBOjBmJISO0u r2aYoEbXsuf1Nt82LfAL36yga5Jt45FvM+9t1N1f2pLyb1ecSDUHdkl/Ba88Agrl3I ypaVhxRh3gwa8KSNennWxxCsCrMounid0cs5LdizNRWpuq9n2T8F/QBh+VGFmpyFYb p97/kH7iIihpGyHcpiwavSdhudXUDRsuEFbm86fTf+kbZMP+gAQq9RcgFneysjwGzt MnrnuYN/WlzIQ== Date: Wed, 21 Oct 2026 11:47:19 +0200 From: Lorenzo Pieralisi To: Gavin Shan Cc: Mathieu Poirier , berrange@redhat.com, kchamart@redhat.com, pierrick.bouvier@oss.qualcomm.com, peter.maydell@linaro.org, mst@redhat.com, cohuck@redhat.com, pbonzini@redhat.com, eblake@redhat.com, armbru@redhat.com, lorenzo.pieralisi@linaro.org, enju.kohei@fujitsu.com, qemu-devel@nongnu.org, qemu-arm@nongnu.org, kvm@vger.kernel.org Subject: Re: [RFC v4 11/24] target/arm/kvm-rme: Populate Realm with runtime images Message-ID: References: <20260903193611.1058589-1-mathieu.poirier@linaro.org> <20260903193611.1058589-12-mathieu.poirier@linaro.org> <3257a387-490f-44bb-bd44-dbe06036fd52@redhat.com> X-Mailing-List: kvm@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3257a387-490f-44bb-bd44-dbe06036fd52@redhat.com> On Fri, Oct 02, 2026 at 01:45:40PM +1000, Gavin Shan wrote: > On 9/4/26 5:35 AM, Mathieu Poirier wrote: > > From: Jean-Philippe Brucker > > > > Once the Realm descriptor has been created, tell KVM to transfer runtime > > images (kernel, DT, and rootfs) from guest memory to Realm memory. > > > > Signed-off-by: Jean-Philippe Brucker > > Signed-off-by: Lorenzo Pieralisi > > Signed-off-by: Mathieu Poirier > > --- > > target/arm/kvm-rme.c | 76 ++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 76 insertions(+) > > > > diff --git a/target/arm/kvm-rme.c b/target/arm/kvm-rme.c > > index 9985f5daba89..c082a5d8f3d1 100644 > > --- a/target/arm/kvm-rme.c > > +++ b/target/arm/kvm-rme.c > > @@ -15,6 +15,7 @@ > > #include "migration/blocker.h" > > #include "qapi/error.h" > > #include "qemu/error-report.h" > > +#include "qemu/memalign.h" > > #include "qom/object_interfaces.h" > > #include "system/confidential-guest-support.h" > > #include "system/kvm.h" > > @@ -43,12 +44,87 @@ OBJECT_DEFINE_SIMPLE_TYPE_WITH_INTERFACES(RmeGuest, rme_guest, RME_GUEST, > > static RmeGuest *rme_guest; > > +static int rme_populate_range(const RmeRamRegion *region, bool measure, > > + Error **errp) > > +{ > > + int ret; > > + void *buffer; > > + hwaddr size = region->size; > > + hwaddr base = region->base; > > + hwaddr start = QEMU_ALIGN_DOWN(base, RME_PAGE_SIZE); > > + hwaddr end = QEMU_ALIGN_UP(base + size, RME_PAGE_SIZE); > > + struct kvm_arm_rmi_populate populate_args; > > + size_t aligned_size = ROUND_UP(region->size, qemu_real_host_page_size()); > > s/qemu_real_host_page_size()/RME_PAGE_SIZE It will always have to be qemu_real_host_page_size(), KVM configures it that way. > > + > > + if (!region->data) { > > + return -ENODEV; > > + } > > + > > + ret = kvm_set_memory_attributes_private(start, end - start); > > + if (ret) { > > + error_report("RME: failed to configure initial" > > + "private guest memory"); > > + return ret; > > + } > > + > > + /* Allocate page-aligned memory */ > > + buffer = qemu_memalign(qemu_real_host_page_size(), aligned_size); > > + > > + if (!buffer) { > > + return -ENOMEM; > > + } > > + > > + memset(buffer, 0, aligned_size); > > + memcpy(buffer, region->data, region->size); > > + > > + populate_args = (struct kvm_arm_rmi_populate) { > > + .base = start, > > + .size = end - start, > > + .source_uaddr = (uintptr_t)buffer, > > + .flags = measure ? KVM_ARM_RMI_POPULATE_FLAGS_MEASURE : 0, > > + }; > > + > > + while (populate_args.size > 0) { > > + ret = kvm_vm_ioctl(kvm_state, KVM_ARM_RMI_POPULATE, &populate_args, 0); > > + if (ret) { > > + error_setg_errno(errp, -ret, > > + "failed to populate realm [0x%"HWADDR_PRIx", 0x%"HWADDR_PRIx")", > > + start, end); > > + break; > > + } > > + } > > + > > + qemu_vfree(buffer); > > + > > + return ret; > > +} > > + > > I doubt that the unaligned regions (RmeRamRegion) are allowed. For example, > the region [4KB 64KB+4KB] is turned to the aligned range [0 128KB] when RME_PAGE_SIZE > is 64KB. The question is how do we know the added regions due to the alignment > ([0 4KB] and [64KB+4KB 128KB]) are safe for kvm_vm_ioctl(KVM_ARM_RMI_POPULATE). Getting back to this because it is important. Can you define "safe" here ? I think it is VMM's role to load with the required alignment and make sure it does not double populate (that is anyway prevented by KVM), what was your concern here to make sure we are in agreement ? Thanks, Lorenzo > I guess we probably just reject unaligned regions if they're not expected. > > Even if the unaligned regions are allowed, they seem not well handled. > > - @aligned_size is still 64KB instead of the 128KB ? > - In "memcpy(buffer, region->data, region->size);", the blob data would be copied to > [4KB, 4KB+64KB]. However, we're copying the data to [0 64KB] now. > > > +static void rme_populate_ram_region(gpointer data, gpointer err) > > +{ > > + Error **errp = err; > > + const RmeRamRegion *region = data; > > + > > + if (*errp) { > > + return; > > + } > > + > > + rme_populate_range(region, /* measure */ true, errp); > > +} > > + > > static void rme_vm_state_change(void *opaque, bool running, RunState state) > > { > > + Error *errp = NULL; > > + > > if (!running) { > > return; > > } > > + g_slist_foreach(rme_guest->ram_regions, rme_populate_ram_region, &errp); > > + g_slist_free_full(g_steal_pointer(&rme_guest->ram_regions), g_free); > > + if (errp) { > > + return; > > + } > > + > > kvm_mark_guest_state_protected(); > > } > > Thanks, > Gavin >