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=-0.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 3CC41C4338F for ; Wed, 18 Aug 2021 20:09:27 +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 CAB9260F39 for ; Wed, 18 Aug 2021 20:09:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CAB9260F39 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:41580 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mGRsL-0007z3-Rh for qemu-devel@archiver.kernel.org; Wed, 18 Aug 2021 16:09:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34590) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mGRXW-0002lJ-5a for qemu-devel@nongnu.org; Wed, 18 Aug 2021 15:47:54 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:22816) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mGRXU-0001ms-JJ for qemu-devel@nongnu.org; Wed, 18 Aug 2021 15:47:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1629316071; 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=IN+A2YV8lnyT2Ng0aWhK6RxOteRmp7fFa45zy1dSMwY=; b=TgtrxvigxQyLnukBgmW4uY6D7j24zU0bQukbtVhi7fn/rxFtJu1MPpxHj3VXMmNrPUsvOC m5Ct7ocZG/pUWu4fNpqPX/ygnm/bmtOuiwgw9qXZ7kw2EgqFiicGv/uHMafKO1wEU/Oztf GxT9R1IroxFG68REWnq/ssiEMYhEEOw= Received: from mail-pj1-f70.google.com (mail-pj1-f70.google.com [209.85.216.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-322-b8rCcp06NUG8G11fVyUqkw-1; Wed, 18 Aug 2021 15:47:47 -0400 X-MC-Unique: b8rCcp06NUG8G11fVyUqkw-1 Received: by mail-pj1-f70.google.com with SMTP id k17-20020a17090aaa11b02901788cbc8832so4068640pjq.0 for ; Wed, 18 Aug 2021 12:47:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IN+A2YV8lnyT2Ng0aWhK6RxOteRmp7fFa45zy1dSMwY=; b=DaMyTJEdsy9ieixDCs9l6qns3L4taALcHLk7kRYTaBFm5Y8KtnidEIAk8aiwj08N1R w+d8Pn6C7IjCP5sEkoM7eDmtQ9mlnIfetS1ssRfHdKTyBE6H62AA+KuyyyIDPFw+djgF vz9Kzc88pAg9nKA/hv1ATcjW8MQrI/Um4mAqVxL+kN7DtVI+iC8m8hQKJE7T0yR9DQDR 3sh35I306K9I5wCUNiAQyepD6jp2sG7VRfnWBMUjLMciYh6nlL+c3gEhThCPkLPcbo/d 3vUg/7bv+P9OyGYTk59kKQdwYQETEu3+0SMCmd1yViEd1d2GCAfAYzQxCOizqpUBIlYb 2X/A== X-Gm-Message-State: AOAM532SMd5QzXvgphH9ym4NyvTSrLjvmBnsXPQEt7ZR8+pcH45P5l8d J4go+WEDMaPPE7EEdwnteQuXZZrjD097TkRCxRf+vJUOK0kSB5cWK+8Mx4zkbaq5Rpk/OkV13QF A0vf2+/fAKD+ZLFAfelwpFElK+I1Wv9I= X-Received: by 2002:a63:5fcc:: with SMTP id t195mr10312454pgb.146.1629316066716; Wed, 18 Aug 2021 12:47:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzl+CDRGCzeP3QPc2WXRxCANh3B9ZbRQw18tAno0sI1fPvBOwgnViETvtptFNPXKNvRIoYrOlbk1cVAMGbK/wY= X-Received: by 2002:a63:5fcc:: with SMTP id t195mr10312439pgb.146.1629316066491; Wed, 18 Aug 2021 12:47:46 -0700 (PDT) MIME-Version: 1.0 References: <20210816144413.GA29881@ashkalra_ubuntu_server> <20210816151349.GA29903@ashkalra_ubuntu_server> <20210818103147.GB31834@ashkalra_ubuntu_server> In-Reply-To: <20210818103147.GB31834@ashkalra_ubuntu_server> From: Paolo Bonzini Date: Wed, 18 Aug 2021 21:47:32 +0200 Message-ID: Subject: Re: [RFC PATCH 00/13] Add support for Mirror VM. To: Ashish Kalra 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: multipart/alternative; boundary="0000000000005ed3c705c9dab5c0" Received-SPF: pass client-ip=170.10.133.124; envelope-from=pbonzini@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -34 X-Spam_score: -3.5 X-Spam_bar: --- X-Spam_report: (-3.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.7, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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: Thomas Lendacky , Brijesh Singh , "Habkost, Eduardo" , kvm , "S. Tsirkin, Michael" , Tobin Feldman-Fitzthum , "James E . J . Bottomley" , Richard Henderson , qemu-devel , David Gilbert , Hubertus Franke , Dov Murik Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --0000000000005ed3c705c9dab5c0 Content-Type: text/plain; charset="UTF-8" Il mer 18 ago 2021, 12:31 Ashish Kalra ha scritto: > Hello Paolo, > > On Mon, Aug 16, 2021 at 05:38:55PM +0200, Paolo Bonzini wrote: > > On 16/08/21 17:13, Ashish Kalra wrote: > > > > > I think that once the mirror VM starts booting and running the UEFI > > > > > code, it might be only during the PEI or DXE phase where it will > > > > > start actually running the MH code, so mirror VM probably still > need > > > > > to handles KVM_EXIT_IO when SEC phase does I/O, I can see PIC > > > > > accesses and Debug Agent initialization stuff in SEC startup code. > > > > That may be a design of the migration helper code that you were > working > > > > with, but it's not necessary. > > > > > > > Actually my comments are about a more generic MH code. > > > > I don't think that would be a good idea; designing QEMU's migration > helper > > interface to be as constrained as possible is a good thing. The > migration > > helper is extremely security sensitive code, so it should not expose > itself > > to the attack surface of the whole of QEMU. > > > > > One question i have here, is that where exactly will the MH code exist > in QEMU ? > > I assume it will be only x86 platform specific code, we probably will > never support it on other platforms ? > > So it will probably exist in hw/i386, something similar to "microvm" > support and using the same TYPE_X86_MACHINE ? > > Also if we are not going to use the existing KVM support code and > adding some duplicate KVM interface code, do we need to interface with > this added KVM code via the QEMU accelerator framework, or simply invoke > this KVM code statically ? > I would expect to be mostly separate. Once we get a second architecture we may move part of it into TYPE_ACCEL_KVM, but that can come later and probably it would still not reuse much code from the full-blown KVM code that supports interrupts, MMIO and all that. Paolo > Thanks, > Ashish > > --0000000000005ed3c705c9dab5c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Il mer 18 ago 2021, 12:31 Ashish Kalra <ashish.kalra@amd.com> ha scritto:
Hello Paolo,

On Mon, Aug 16, 2021 at 05:38:55PM +0200, Paolo Bonzini wrote:
> On 16/08/21 17:13, Ashish Kalra wrote:
> > > > I think that once the mirror VM starts booting and runn= ing the UEFI
> > > > code, it might be only during the PEI or DXE phase wher= e it will
> > > > start actually running the MH code, so mirror VM probab= ly still need
> > > > to handles KVM_EXIT_IO when SEC phase does I/O, I can s= ee PIC
> > > > accesses and Debug Agent initialization stuff in SEC st= artup code.
> > > That may be a design of the migration helper code that you w= ere working
> > > with, but it's not necessary.
> > >
> > Actually my comments are about a more generic MH code.
>
> I don't think that would be a good idea; designing QEMU's migr= ation helper
> interface to be as constrained as possible is a good thing.=C2=A0 The = migration
> helper is extremely security sensitive code, so it should not expose i= tself
> to the attack surface of the whole of QEMU.
>
>
One question i have here, is that where exactly will the MH code exist
in QEMU ?

I assume it will be only x86 platform specific code, we probably will
never support it on other platforms ?

So it will probably exist in hw/i386, something similar to "microvm&qu= ot;
support and using the same TYPE_X86_MACHINE ?

Also if we are not going to use the existing KVM support code and
adding some duplicate KVM interface code, do we need to interface with
this added KVM code via the QEMU accelerator framework, or simply invoke this KVM code statically ?
I would expect to be mostly separate. Once we get= a second architecture we may move part of it into TYPE_ACCEL_KVM, but that= can come later and probably it would still not reuse much code from the fu= ll-blown KVM code that supports interrupts, MMIO and all that.

Paolo


Thanks,
Ashish

--0000000000005ed3c705c9dab5c0--