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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 3EB2BC433FE for ; Sat, 29 Oct 2022 05:35:30 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ooeU0-0002Yx-CL; Sat, 29 Oct 2022 01:34:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ooUgK-0004bg-OH; Fri, 28 Oct 2022 15:06:30 -0400 Received: from mail-pl1-x636.google.com ([2607:f8b0:4864:20::636]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ooUgH-0000qN-6P; Fri, 28 Oct 2022 15:06:16 -0400 Received: by mail-pl1-x636.google.com with SMTP id f23so5626295plr.6; Fri, 28 Oct 2022 12:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=OpySAI0m06R16LGE63jw0ivYx7e/ioZkfJWvMJn/6p4=; b=BJ33SXBipARpCCtD2oOUkdM2RwZNIXY+XMUdvUhKqF6VuaQ8miWtNBI/CdPbA7sUta oXy7ggplDYDuuUTyNOjOsHDFD9zVN0aKqUY/cewErZBNQcdZTk5TovbXo8pBbzYDTEZf 9rp+ds87gQHxqbHI3/E3ECAWJ3dklCaqNHM7iJEPXGn1DvXXh/lRT/ghGVM9uRMn9iys XPN7XmGEab12vjsbRHdEHg/m0eXr0IeiaUA29O7qFu7kXN2aZXTengiSAgGOFc+izg78 UkS93zzjWQDa8e9yZusr2WX2jmsR47czjYPH6Y0puT9tbf8JfLhY3G/p9YsjDrdoIDSR oyfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OpySAI0m06R16LGE63jw0ivYx7e/ioZkfJWvMJn/6p4=; b=AHInQhRZPTRFov+9mJT1jxq8ixtncL1G5VFqCFhE8ivm1wvgUxRWJq+5Jm6e7ppsmk lr5ZHXD/ZVvmBOKpeFsKhC+GTxAHczbzlDh8O3+h8c3QKhyPfvWBXLIbBN7VzjmnGjE/ wA+OOoR2gFXW3P+PGctKlYqQK+/iDjOhgx6SvvSRoRn/CM94/aJIxhhHcJ9OUscq3Jop L0+Kp5yEstwM/jshXOMOg7OkPyZMPK+YtJ2wJAMTScTXWIbXRJyQMote18tMrHNVBtt5 EoND+u6Tfbf5nnNUcWD8jCiJb3paXUWqCt+cebVNGJx16Q9LcHa7oj5JL41gv1hb/jd/ Ju6w== X-Gm-Message-State: ACrzQf2UtMzl7X8xySrtcH3DWARKG5RZGz0VQjfmZV1ZI315T//DkT5o vd/s6VbSlnXt64Netrb8wRQ6B/ZaUht76fgX7L8= X-Google-Smtp-Source: AMsMyM4xKpCtA6doHrBId4kdH/4woxsla2xyPf+PNZF/ENC+dfhwTJMgv3LlYmF2OAn5rSk4ZRzuc0DmTtr8rx9IYqg= X-Received: by 2002:a17:902:eccc:b0:186:5f09:f9 with SMTP id a12-20020a170902eccc00b001865f0900f9mr490806plh.6.1666983970122; Fri, 28 Oct 2022 12:06:10 -0700 (PDT) MIME-Version: 1.0 References: <20221015050750.4185-1-vikram.garhwal@amd.com> <20221015050750.4185-11-vikram.garhwal@amd.com> <87wn8l3d3r.fsf@linaro.org> <7da20a2e-81e0-b3ad-c2d6-6012fa7edee2@xen.org> In-Reply-To: <7da20a2e-81e0-b3ad-c2d6-6012fa7edee2@xen.org> From: Oleksandr Tyshchenko Date: Fri, 28 Oct 2022 22:05:58 +0300 Message-ID: Subject: Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine To: Julien Grall , Vikram Garhwal , stefano.stabellini@amd.com Cc: qemu-devel@nongnu.org, Peter Maydell , Stefano Stabellini , Anthony Perard , Paul Durrant , "open list:ARM TCG CPUs" , xen-devel@lists.xenproject.org, =?UTF-8?B?QWxleCBCZW5uw6ll?= Content-Type: multipart/alternative; boundary="00000000000062afd005ec1cf34a" Received-SPF: pass client-ip=2607:f8b0:4864:20::636; envelope-from=olekstysh@gmail.com; helo=mail-pl1-x636.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sat, 29 Oct 2022 00:27:01 -0400 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Qemu-devel" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org --00000000000062afd005ec1cf34a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 28, 2022 at 8:58 PM Julien Grall wrote: > Hi, > Hello all. [sorry for the possible format issues] > > On 27/10/2022 09:02, Alex Benn=C3=A9e wrote: > > > > Vikram Garhwal writes: > > > > > >> Optional: When CONFIG_TPM is enabled, it also creates a tpm-tis-device= , > adds a > >> TPM emulator and connects to swtpm running on host machine via chardev > socket > >> and support TPM functionalities for a guest domain. > >> > >> Extra command line for aarch64 xenpv QEMU to connect to swtpm: > >> -chardev socket,id=3Dchrtpm,path=3D/tmp/myvtpm2/swtpm-sock \ > >> -tpmdev emulator,id=3Dtpm0,chardev=3Dchrtpm \ > >> > >> swtpm implements a TPM software emulator(TPM 1.2 & TPM 2) built on > libtpms and > >> provides access to TPM functionality over socket, chardev and CUSE > interface. > >> Github repo: https://github.com/stefanberger/swtpm > >> Example for starting swtpm on host machine: > >> mkdir /tmp/vtpm2 > >> swtpm socket --tpmstate dir=3D/tmp/vtpm2 \ > >> --ctrl type=3Dunixio,path=3D/tmp/vtpm2/swtpm-sock & > > > > > >> +static void xen_enable_tpm(void) > >> +{ > >> +/* qemu_find_tpm_be is only available when CONFIG_TPM is enabled. */ > >> +#ifdef CONFIG_TPM > >> + Error *errp =3D NULL; > >> + DeviceState *dev; > >> + SysBusDevice *busdev; > >> + > >> + TPMBackend *be =3D qemu_find_tpm_be("tpm0"); > >> + if (be =3D=3D NULL) { > >> + DPRINTF("Couldn't fine the backend for tpm0\n"); > >> + return; > >> + } > >> + dev =3D qdev_new(TYPE_TPM_TIS_SYSBUS); > >> + object_property_set_link(OBJECT(dev), "tpmdev", OBJECT(be), &errp= ); > >> + object_property_set_str(OBJECT(dev), "tpmdev", be->id, &errp); > >> + busdev =3D SYS_BUS_DEVICE(dev); > >> + sysbus_realize_and_unref(busdev, &error_fatal); > >> + sysbus_mmio_map(busdev, 0, GUEST_TPM_BASE); > > > > I'm not sure what has gone wrong here but I'm getting: > > > > ../../hw/arm/xen_arm.c: In function =E2=80=98xen_enable_tpm=E2=80=99= : > > ../../hw/arm/xen_arm.c:120:32: error: =E2=80=98GUEST_TPM_BASE=E2=80= =99 undeclared > (first use in this function); did you mean =E2=80=98GUEST_RAM_BASE=E2=80= =99? > > 120 | sysbus_mmio_map(busdev, 0, GUEST_TPM_BASE); > > | ^~~~~~~~~~~~~~ > > | GUEST_RAM_BASE > > ../../hw/arm/xen_arm.c:120:32: note: each undeclared identifier is > reported only once for each function it appears in > > > > In my cross build: > > > > # Configured with: '../../configure' '--disable-docs' > '--target-list=3Daarch64-softmmu' '--disable-kvm' '--enable-xen' > '--disable-opengl' '--disable-libudev' '--enable-tpm' > '--disable-xen-pci-passthrough' '--cross-prefix=3Daarch64-linux-gnu-' > '--skip-meson' > > > > which makes me wonder if this is a configure failure or a confusion > > about being able to have host swtpm implementations during emulation bu= t > > needing target tpm for Xen? > > I was also wondering where is that value come from. Note that the > memory/IRQ layout exposed to the guest is not stable. > > Are we expecting the user to rebuild QEMU for every Xen versions (or > possibly every guest if we ever allow dynamic layout in Xen)? > This doesn't sound ideal. I am wondering what would be the correct way here assuming that we would likely need to have more such information in place for supporting more use-cases... For instance, the PCI host bridge emulation in Qemu. Xen toolstack (another software layer) generates device-tree for the guest, so creates PCI Host bridge node by using reserved regions from Guest OS interface (arch-arm.h): - GUEST_VPCI_MEM_ADDR (GUEST_VPCI_MEM_SIZE) - GUEST_VPCI_ECAM_BASE (GUEST_VPCI_ECAM_SIZE) - GUEST_VPCI_PREFETCH_MEM_ADDR (GUEST_VPCI_PREFETCH_MEM_SIZE) https://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3Dtools/libs/light/l= ibxl_arm.c;h=3D2a5e93c28403738779863aded31d2df3ba72f8c0;hb=3DHEAD#l833 Here in Qemu when creating a PCI Host bridge we would need to use exactly the same reserved regions which toolstack writes in the corresponding device-tree node. So how to tell Qemu about them? 1. Introduce new cmd line arguments? 2. Using Xenstore? 3. Anything else? I am afraid this would be related to every device that we want to emulate in Qemu and for which the toolstack needs to generate device-tree node by using something defined with GUEST_*, unless I really missed something. > > Cheers, > > -- > Julien Grall > > --=20 Regards, Oleksandr Tyshchenko --00000000000062afd005ec1cf34a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Oct 28, 2022 at 8:58 PM Julie= n Grall <julien@xen.= org> wrote:
Hi,

Hello all.

<= div>[sorry for the possible format issues]

=C2=A0<= /div>

On 27/10/2022 09:02, Alex Benn=C3=A9e wrote:
>
> Vikram Garhwal <vikram.garhwal@amd.com> writes:
>
> <snip>
>> Optional: When CONFIG_TPM is enabled, it also creates a tpm-tis-de= vice, adds a
>> TPM emulator and connects to swtpm running on host machine via cha= rdev socket
>> and support TPM functionalities for a guest domain.
>>
>> Extra command line for aarch64 xenpv QEMU to connect to swtpm:
>>=C2=A0 =C2=A0 =C2=A0 -chardev socket,id=3Dchrtpm,path=3D/tmp/myvtpm= 2/swtpm-sock \
>>=C2=A0 =C2=A0 =C2=A0 -tpmdev emulator,id=3Dtpm0,chardev=3Dchrtpm \<= br> >>
>> swtpm implements a TPM software emulator(TPM 1.2 & TPM 2) buil= t on libtpms and
>> provides access to TPM functionality over socket, chardev and CUSE= interface.
>> Github repo: https://github.com/stefanberger/swtpm=
>> Example for starting swtpm on host machine:
>>=C2=A0 =C2=A0 =C2=A0 mkdir /tmp/vtpm2
>>=C2=A0 =C2=A0 =C2=A0 swtpm socket --tpmstate dir=3D/tmp/vtpm2 \
>>=C2=A0 =C2=A0 =C2=A0 --ctrl type=3Dunixio,path=3D/tmp/vtpm2/swtpm-s= ock &
>
> <snip>
>> +static void xen_enable_tpm(void)
>> +{
>> +/* qemu_find_tpm_be is only available when CONFIG_TPM is enabled.= */
>> +#ifdef CONFIG_TPM
>> +=C2=A0 =C2=A0 Error *errp =3D NULL;
>> +=C2=A0 =C2=A0 DeviceState *dev;
>> +=C2=A0 =C2=A0 SysBusDevice *busdev;
>> +
>> +=C2=A0 =C2=A0 TPMBackend *be =3D qemu_find_tpm_be("tpm0"= ;);
>> +=C2=A0 =C2=A0 if (be =3D=3D NULL) {
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 DPRINTF("Couldn't fine the b= ackend for tpm0\n");
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 return;
>> +=C2=A0 =C2=A0 }
>> +=C2=A0 =C2=A0 dev =3D qdev_new(TYPE_TPM_TIS_SYSBUS);
>> +=C2=A0 =C2=A0 object_property_set_link(OBJECT(dev), "tpmdev&= quot;, OBJECT(be), &errp);
>> +=C2=A0 =C2=A0 object_property_set_str(OBJECT(dev), "tpmdev&q= uot;, be->id, &errp);
>> +=C2=A0 =C2=A0 busdev =3D SYS_BUS_DEVICE(dev);
>> +=C2=A0 =C2=A0 sysbus_realize_and_unref(busdev, &error_fatal);=
>> +=C2=A0 =C2=A0 sysbus_mmio_map(busdev, 0, GUEST_TPM_BASE);
>
> I'm not sure what has gone wrong here but I'm getting:
>
>=C2=A0 =C2=A0 ../../hw/arm/xen_arm.c: In function =E2=80=98xen_enable_t= pm=E2=80=99:
>=C2=A0 =C2=A0 ../../hw/arm/xen_arm.c:120:32: error: =E2=80=98GUEST_TPM_= BASE=E2=80=99 undeclared (first use in this function); did you mean =E2=80= =98GUEST_RAM_BASE=E2=80=99?
>=C2=A0 =C2=A0 =C2=A0 120 |=C2=A0 =C2=A0 =C2=A0sysbus_mmio_map(busdev, 0= , GUEST_TPM_BASE);
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ^~~~~~~~~~~~~~
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 GUEST_RAM_BASE
>=C2=A0 =C2=A0 ../../hw/arm/xen_arm.c:120:32: note: each undeclared iden= tifier is reported only once for each function it appears in
>
> In my cross build:
>
>=C2=A0 =C2=A0 # Configured with: '../../configure' '--disab= le-docs' '--target-list=3Daarch64-softmmu' '--disable-kvm&#= 39; '--enable-xen' '--disable-opengl' '--disable-libude= v' '--enable-tpm' '--disable-xen-pci-passthrough' '= --cross-prefix=3Daarch64-linux-gnu-' '--skip-meson'
>
> which makes me wonder if this is a configure failure or a confusion > about being able to have host swtpm implementations during emulation b= ut
> needing target tpm for Xen?

I was also wondering where is that value come from. Note that the
memory/IRQ layout exposed to the guest is not stable.

Are we expecting the user to rebuild QEMU for every Xen versions (or
possibly every guest if we ever allow dynamic layout in Xen)?


This doesn't sound ideal.=C2=A0

I am wondering what would be the correct way here a= ssuming that we would likely need to have more such information in place fo= r supporting more use-cases...
For instance, the PCI host bridge = emulation in Qemu. Xen toolstack (another software layer) generates device-= tree for the guest, so creates PCI Host bridge node by using reserved regio= ns from=C2=A0Guest OS interface (arch-arm.h):
- GUEST_VPCI_MEM_AD= DR (GUEST_VPCI_MEM_SIZE)
- GUEST_VPCI_ECAM_BASE (GUEST_VPCI_E= CAM_SIZE)
- GUEST_VPCI_PREFETCH_MEM_ADDR (GUEST_VPCI_PREFETCH= _MEM_SIZE)

=
Here in Qemu when creating a PCI Host bridge we would need to use exac= tly the same reserved regions=C2=A0which toolstack writes in the correspond= ing device-tree node. So how to tell Qemu about them?=C2=A0
1. In= troduce new cmd line arguments?
2. Using Xenstore?
3. A= nything else?

I am afraid this would be related to= every device that we want to emulate in Qemu and for which the toolstack n= eeds to=C2=A0generate device-tree node=C2=A0by using something defined with= GUEST_*, unless I really missed something.

=C2=A0=

Cheers,

--
Julien Grall



--
Regards,=

Oleksandr Tyshchenko<= /span>
--00000000000062afd005ec1cf34a--