On Thu, 2023-10-05 at 18:11 +0200, Philippe Mathieu-Daudé wrote: > On 5/10/23 15:57, James Bottomley wrote: > > On Thu, 2023-10-05 at 08:49 +0200, Philippe Mathieu-Daudé wrote: > > > On 4/10/23 20:42, James Bottomley wrote: > > > > From: James Bottomley <james.bottom...@hansenpartnership.com> [...] > > > > +.. code-block:: console > > > > + > > > > + qemu-system-x86_64 <qemu-options> \ > > > > + -tpmdev > > > > "{'type':'mssim','id':'tpm0','command':{'type':'inet','host':'r > > > > emot > > > > e','port':'2321'},'control':{'type':'inet','host':'remote','por > > > > t':' > > > > 2322'}}" \ > > > > + -device tpm-crb,tpmdev=tpm0 > > > > > > Did you test running this command line on a big-endian host? > > > > Well no, big endian machines are rather rare nowadays. However, > > since the QIOChannelSocket abstraction is based on SocketAddress, > > which is a qapi wrapper around strings, what makes you think the > > endianness would matter? > > You use ntoh/hton in tpm_mssim_handle_request(), so I wonder about > the 'uint32_t cmd' in tpm_send_ctrl().
tpm_send_ctrl has a htonl for the send control command as well (The TPM server is always network ordered, i.e. big endian). The reason it doesn't have one for the receive is that it only checks against zero which is endian invariant, if that's what you're asking? James