On Fri, Oct 28, 2022 at 8:58 PM Julien Grall <jul...@xen.org> wrote: > Hi, >
Hello all. [sorry for the possible format issues] > > On 27/10/2022 09:02, Alex Bennée wrote: > > > > Vikram Garhwal <vikram.garh...@amd.com> writes: > > > > <snip> > >> 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=chrtpm,path=/tmp/myvtpm2/swtpm-sock \ > >> -tpmdev emulator,id=tpm0,chardev=chrtpm \ > >> > >> 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=/tmp/vtpm2 \ > >> --ctrl type=unixio,path=/tmp/vtpm2/swtpm-sock & > > > > <snip> > >> +static void xen_enable_tpm(void) > >> +{ > >> +/* qemu_find_tpm_be is only available when CONFIG_TPM is enabled. */ > >> +#ifdef CONFIG_TPM > >> + Error *errp = NULL; > >> + DeviceState *dev; > >> + SysBusDevice *busdev; > >> + > >> + TPMBackend *be = qemu_find_tpm_be("tpm0"); > >> + if (be == NULL) { > >> + DPRINTF("Couldn't fine the backend for tpm0\n"); > >> + return; > >> + } > >> + dev = 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 = 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 ‘xen_enable_tpm’: > > ../../hw/arm/xen_arm.c:120:32: error: ‘GUEST_TPM_BASE’ undeclared > (first use in this function); did you mean ‘GUEST_RAM_BASE’? > > 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=aarch64-softmmu' '--disable-kvm' '--enable-xen' > '--disable-opengl' '--disable-libudev' '--enable-tpm' > '--disable-xen-pci-passthrough' '--cross-prefix=aarch64-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 but > > 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=xen.git;a=blob;f=tools/libs/light/libxl_arm.c;h=2a5e93c28403738779863aded31d2df3ba72f8c0;hb=HEAD#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 > > -- Regards, Oleksandr Tyshchenko
