Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine

[Julien Grall]

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 <julien@xen.org>
> Date: Sunday, October 16, 2022 at 10:48 AM
> To: Garhwal, Vikram <vikram.garhwal@amd.com>, qemu-devel@nongnu.org 
> <qemu-devel@nongnu.org>
> Cc: Stabellini, Stefano <stefano.stabellini@amd.com>, Peter Maydell <peter.maydell@linaro.org>, Stefano 
> Stabellini <sstabellini@kernel.org>, Anthony Perard <anthony.perard@citrix.com>, Paul Durrant 
> <paul@xen.org>, open list:ARM TCG CPUs <qemu-arm@nongnu.org>, open list:X86 Xen CPUs 
> <xen-devel@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