All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Stefano Garzarella <sgarzare@redhat.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
	coconut-svsm@lists.linux.dev, svsm-devel@coconut-svsm.dev
Subject: Re: [svsm-devel] Potential project on implementing AMD SEV emulation in QEMU
Date: Tue, 22 Apr 2025 08:52:49 +0100	[thread overview]
Message-ID: <aAdKwgeBO3ILBwcJ@redhat.com> (raw)
In-Reply-To: <CAGxU2F4X_yQS9zR7u6cPmXzt8-BkPwWf0NQt2f=GVQBp1BOztw@mail.gmail.com>

On Thu, Apr 17, 2025 at 05:26:15PM +0200, Stefano Garzarella wrote:
> Hi Tom,
> yesterday in the Coconut-SVSM community call we talked about a
> potential project with the University of Pisa to emulate AMD
> SEV/SEV-ES/SEV-SNP support in QEMU.
> 
> Joerg rightly suggested having a step-by-step approach, supporting SEV
> initially, as supporting SEV-SNP directly might be too much for a
> master's thesis (about 6 months of work).

Agreed, from the QEMU maintainer side we'd very likely want to see an
incremental set of patches rather than a "big bang" attempting todo
everything in one go. Staging patch submissions for SEV, then ES
then SNP would make conceptual sense, to enable something useful to
be delivered at each step.

> We wondered if you knew of any attempts already made in this regard,
> but especially if you think it's a feasible thing.

I think 6 months is possibly on the optimistic side.

Non-trivial feature proposals have a habit of taking longer than people
expect upfront. They might get lucky, but I equally it wouldn't surprise
me to see patches go through 6-9 months of reviews, on top of the initial
time needed to write a first impl before submission, with multiple
repostings needed before being merged. IOW it could be 6 months,  it
could be 12 months.

I don't mean that to discourage an attempt. Just that non-trivial open
source contributions with fixed timelines are not a reliable combination.
IOW, plan for what happens if it takes longer than expected, exceeding
the 6 month thesis timeframe.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


  parent reply	other threads:[~2025-04-22  7:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-17 15:26 Potential project on implementing AMD SEV emulation in QEMU Stefano Garzarella
2025-04-17 16:08 ` Dionna Amalie Glaze
2025-04-18  8:12   ` Stefano Garzarella
2025-04-17 20:14 ` Tom Lendacky
2025-04-18  8:31   ` Stefano Garzarella
2025-04-22  7:56     ` [svsm-devel] " Daniel P. Berrangé
2025-04-22 10:32       ` Stefano Garzarella
2025-04-22 10:35         ` Daniel P. Berrangé
2025-04-22  7:52 ` Daniel P. Berrangé [this message]
2025-04-22 10:45   ` Stefano Garzarella

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=aAdKwgeBO3ILBwcJ@redhat.com \
    --to=berrange@redhat.com \
    --cc=coconut-svsm@lists.linux.dev \
    --cc=sgarzare@redhat.com \
    --cc=svsm-devel@coconut-svsm.dev \
    --cc=thomas.lendacky@amd.com \
    /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.