On 02/12/2022 03:24, Garhwal, Vikram wrote:
Hi Julien,
Hi Vikram,
I am having trouble to differentiate your answers from my remark. For
instance...
From: Julien Grall <jul...@xen.org>
Date: Sunday, October 16, 2022 at 10:48 AM
To: Garhwal, Vikram <vikram.garh...@amd.com>, qemu-devel@nongnu.org
<qemu-devel@nongnu.org>
Cc: Stabellini, Stefano <stefano.stabell...@amd.com>, Peter Maydell <peter.mayd...@linaro.org>, Stefano
Stabellini <sstabell...@kernel.org>, Anthony Perard <anthony.per...@citrix.com>, Paul Durrant
<p...@xen.org>, open list:ARM TCG CPUs <qemu-...@nongnu.org>, open list:X86 Xen CPUs
<xen-de...@lists.xenproject.org>
Subject: Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine
Hi,
There seem to be some missing patches on xen-devel (including the cover
letter). Is that expected?
Not sure what went wrong there. I can see all of these on QEMU-devel. Perhaps
xen-devel is not in maintainer’s list for all the xen files?
On 15/10/2022 06:07, Vikram Garhwal wrote:
Add a new machine xenpv which creates a IOREQ server to register/connect with
Xen Hypervisor.
I don't like the name 'xenpv' because it doesn't convey the fact that
some of the HW may be emulated rather than para-virtualized. In fact one
may only want to use for emulating devices.
Potential name would be 'xen-arm' or re-using 'virt' but with
'accel=xen' to select a Xen layout.
Xen IOREQ connection expect the TARGET_PAGE_SIZE to 4096, and the xenpv machine
on ARM will have no CPU definitions. We need to define TARGET_PAGE_SIZE
appropriately ourselves.
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 &
I see patches for QEMU but not Xen. How can this be tested with existing
Xen? Will libxl ever create QEMU?
Will send the patch for libxl Xen separately.
... the first two lines are my remarks and the 3rd is your answer. Can
you configure your e-mail client to do proper quoting?
[...]
+ 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 can't find where GUEST_TPM_BASE is defined. But then the guest memory
layout is not expected to be stable. With your current approach, it
means QEMU would need to be rebuilt for every Xen version. Is it what we
want?
I cannot think of better way to do this. Either we add the the def here or
rebuild it if GUEST_TPM_BASE changes for each xen version.
The alternative would be to specify the address on the QEMU command
line. The advantage is you could build a system where each guests have
different layout.
Cheers,
--
Julien Grall