All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron via <qemu-arm@nongnu.org>
To: Gustavo Romero <gustavo.romero@linaro.org>
Cc: <qemu-devel@nongnu.org>, <qemu-arm@nongnu.org>,
	<richard.henderson@linaro.org>, <alex.bennee@linaro.org>,
	<peter.maydell@linaro.org>
Subject: Re: [RFC PATCH 5/7] hw/arm/virt: Add machine option 'mec'
Date: Fri, 20 Mar 2026 09:31:45 +0000	[thread overview]
Message-ID: <20260320093145.000020e1@huawei.com> (raw)
In-Reply-To: <c04a5077-e122-4784-91ad-259055c0f63b@linaro.org>

On Thu, 19 Mar 2026 14:27:57 -0300
Gustavo Romero <gustavo.romero@linaro.org> wrote:

> Hi Jonathan,
> 
> On 3/19/26 06:46, Jonathan Cameron wrote:
> > On Wed, 18 Mar 2026 23:23:33 -0300
> > Gustavo Romero <gustavo.romero@linaro.org> wrote:
> >   
> >> Add new machine option 'mec' that enables and sets the memory used by
> >> FEAT_MEC.
> >>
> >> Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org>  
> > 
> > Drive by comments only. I'm curious enough to read the patches
> > but no idea if this is how people would like to see this implemented!  
> 
> Thanks for taking a look at it and for you comments.
> 
> In which sense do you mean exactly? Do mind to elaborate a bit more on 
> it? If it's about the whole implementation, would it be about not
> really encrypting data or something else? Please help me to understand it :)
> 
> I'm not sure if you're talking about just this patch or the whole 
> FEAT_MEC design.

I was failing to express that this is fine for me but out of my area of expertise
wrt to QEMU so would leave the questions of 'is this the best way to do it?'
for others!

> 
> 
> Cheers,
> Gustavo
> 
> > Jonathan
> >   
> >>   static void create_secure_ram(VirtMachineState *vms,
> >>                                 MemoryRegion *secure_sysmem,
> >>                                 MemoryRegion *secure_tag_sysmem)
> >> @@ -2267,6 +2288,8 @@ static void machvirt_init(MachineState *machine)
> >>       MemoryRegion *secure_sysmem = NULL;
> >>       MemoryRegion *tag_sysmem = NULL;
> >>       MemoryRegion *secure_tag_sysmem = NULL;
> >> +    MemoryRegion *pseudo_encrypted_page = NULL;
> >> +    MemoryRegion *tuple_memory = NULL;
> >>       int n, virt_max_cpus;
> >>       bool firmware_loaded;
> >>       bool aarch64 = true;
> >> @@ -2495,6 +2518,28 @@ static void machvirt_init(MachineState *machine)
> >>               }
> >>           }
> >>   
> >> +        if (vms->mec) {
> >> +            if (tcg_enabled()) {
> >> +                if (tuple_memory == NULL) {
> >> +                    /* XXX(gromero): Add object_property_find(cpuobj, "tuple-memory", ...) here. */
> >> +
> >> +                    tuple_memory = g_new(MemoryRegion, 1);
> >> +                    memory_region_init(tuple_memory, OBJECT(machine), "mec", UINT64_MAX / 32);
> >> +
> >> +                    pseudo_encrypted_page = g_new(MemoryRegion, 1);
> >> +                    memory_region_init(pseudo_encrypted_page, OBJECT(machine), "mec-page", 4 * 1024 /* 4 KiB */);
> >> +                }
> >> +
> >> +                object_property_set_link(cpuobj, "mec",  OBJECT(tuple_memory), &error_abort);
> >> +                object_property_set_link(cpuobj, "mec-page",  OBJECT(pseudo_encrypted_page), &error_abort);  
> > Trivial but some bonus spaces.
> >   
> >> +
> >> +                } else {  
> > 
> > Indent seems off.
> >   
> >> +                    /* Check for other accels here. */
> >> +                    error_report("MEC requested, but not supported");
> >> +                    exit(1);
> >> +                }
> >> +        }
> >> +
> >>           qdev_realize(DEVICE(cpuobj), NULL, &error_fatal);
> >>           object_unref(cpuobj);
> >>       }  
> > 
> >   
> 
> 



WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron via qemu development <qemu-devel@nongnu.org>
To: Gustavo Romero <gustavo.romero@linaro.org>
Cc: <qemu-devel@nongnu.org>, <qemu-arm@nongnu.org>,
	<richard.henderson@linaro.org>, <alex.bennee@linaro.org>,
	<peter.maydell@linaro.org>
Subject: Re: [RFC PATCH 5/7] hw/arm/virt: Add machine option 'mec'
Date: Fri, 20 Mar 2026 09:31:45 +0000	[thread overview]
Message-ID: <20260320093145.000020e1@huawei.com> (raw)
In-Reply-To: <c04a5077-e122-4784-91ad-259055c0f63b@linaro.org>

On Thu, 19 Mar 2026 14:27:57 -0300
Gustavo Romero <gustavo.romero@linaro.org> wrote:

> Hi Jonathan,
> 
> On 3/19/26 06:46, Jonathan Cameron wrote:
> > On Wed, 18 Mar 2026 23:23:33 -0300
> > Gustavo Romero <gustavo.romero@linaro.org> wrote:
> >   
> >> Add new machine option 'mec' that enables and sets the memory used by
> >> FEAT_MEC.
> >>
> >> Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org>  
> > 
> > Drive by comments only. I'm curious enough to read the patches
> > but no idea if this is how people would like to see this implemented!  
> 
> Thanks for taking a look at it and for you comments.
> 
> In which sense do you mean exactly? Do mind to elaborate a bit more on 
> it? If it's about the whole implementation, would it be about not
> really encrypting data or something else? Please help me to understand it :)
> 
> I'm not sure if you're talking about just this patch or the whole 
> FEAT_MEC design.

I was failing to express that this is fine for me but out of my area of expertise
wrt to QEMU so would leave the questions of 'is this the best way to do it?'
for others!

> 
> 
> Cheers,
> Gustavo
> 
> > Jonathan
> >   
> >>   static void create_secure_ram(VirtMachineState *vms,
> >>                                 MemoryRegion *secure_sysmem,
> >>                                 MemoryRegion *secure_tag_sysmem)
> >> @@ -2267,6 +2288,8 @@ static void machvirt_init(MachineState *machine)
> >>       MemoryRegion *secure_sysmem = NULL;
> >>       MemoryRegion *tag_sysmem = NULL;
> >>       MemoryRegion *secure_tag_sysmem = NULL;
> >> +    MemoryRegion *pseudo_encrypted_page = NULL;
> >> +    MemoryRegion *tuple_memory = NULL;
> >>       int n, virt_max_cpus;
> >>       bool firmware_loaded;
> >>       bool aarch64 = true;
> >> @@ -2495,6 +2518,28 @@ static void machvirt_init(MachineState *machine)
> >>               }
> >>           }
> >>   
> >> +        if (vms->mec) {
> >> +            if (tcg_enabled()) {
> >> +                if (tuple_memory == NULL) {
> >> +                    /* XXX(gromero): Add object_property_find(cpuobj, "tuple-memory", ...) here. */
> >> +
> >> +                    tuple_memory = g_new(MemoryRegion, 1);
> >> +                    memory_region_init(tuple_memory, OBJECT(machine), "mec", UINT64_MAX / 32);
> >> +
> >> +                    pseudo_encrypted_page = g_new(MemoryRegion, 1);
> >> +                    memory_region_init(pseudo_encrypted_page, OBJECT(machine), "mec-page", 4 * 1024 /* 4 KiB */);
> >> +                }
> >> +
> >> +                object_property_set_link(cpuobj, "mec",  OBJECT(tuple_memory), &error_abort);
> >> +                object_property_set_link(cpuobj, "mec-page",  OBJECT(pseudo_encrypted_page), &error_abort);  
> > Trivial but some bonus spaces.
> >   
> >> +
> >> +                } else {  
> > 
> > Indent seems off.
> >   
> >> +                    /* Check for other accels here. */
> >> +                    error_report("MEC requested, but not supported");
> >> +                    exit(1);
> >> +                }
> >> +        }
> >> +
> >>           qdev_realize(DEVICE(cpuobj), NULL, &error_fatal);
> >>           object_unref(cpuobj);
> >>       }  
> > 
> >   
> 
> 



  reply	other threads:[~2026-03-20  9:32 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-19  2:23 [RFC PATCH 0/7] Add FEAT_MEC (encryption) Gustavo Romero
2026-03-19  2:23 ` [RFC PATCH 1/7] target/arm: Flush TLB on MECID write Gustavo Romero
2026-03-26 23:29   ` Richard Henderson
2026-03-19  2:23 ` [RFC PATCH 2/7] target/cpu: Add two new address spaces for FEAT_MEC Gustavo Romero
2026-03-26 23:30   ` Richard Henderson
2026-03-19  2:23 ` [RFC PATCH 3/7] memattrs: Add new attribute 'encrypted' Gustavo Romero
2026-03-26 23:39   ` Richard Henderson
2026-03-19  2:23 ` [RFC PATCH 4/7] target/arm/cpu: Add FEAT_MEC object properties Gustavo Romero
2026-03-26 23:40   ` Richard Henderson
2026-03-19  2:23 ` [RFC PATCH 5/7] hw/arm/virt: Add machine option 'mec' Gustavo Romero
2026-03-19  9:46   ` Jonathan Cameron via
2026-03-19  9:46     ` Jonathan Cameron via qemu development
2026-03-19 17:27     ` Gustavo Romero
2026-03-20  9:31       ` Jonathan Cameron via [this message]
2026-03-20  9:31         ` Jonathan Cameron via qemu development
2026-03-27  0:10   ` Richard Henderson
2026-03-19  2:23 ` [RFC PATCH 6/7] target/arm/ptw: Add MECID checks Gustavo Romero
2026-03-27  1:28   ` Richard Henderson
2026-03-19  2:23 ` [RFC PATCH 7/7] target/arm/ptw: Print MECID if not zero [TO BE DISCARDED] Gustavo Romero

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260320093145.000020e1@huawei.com \
    --to=qemu-arm@nongnu.org \
    --cc=alex.bennee@linaro.org \
    --cc=gustavo.romero@linaro.org \
    --cc=jonathan.cameron@huawei.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.