All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: "Eric Auger" <eric.auger@redhat.com>,
	"Stefan Berger" <stefanb@linux.ibm.com>,
	qemu-devel@nongnu.org, "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Subject: Re: [PULL 1/2] tpm: CRB: Use ram_device for "tpm-crb-cmd" region
Date: Fri, 4 Feb 2022 13:08:46 +0100	[thread overview]
Message-ID: <20220204130846.31f5b396@redhat.com> (raw)
In-Reply-To: <164392772418.1683127.9746374099330960813.stgit@omen>

On Thu, 03 Feb 2022 15:35:35 -0700
Alex Williamson <alex.williamson@redhat.com> wrote:

> From: Eric Auger <eric.auger@redhat.com>
> 
> Representing the CRB cmd/response buffer as a standard
> RAM region causes some trouble when the device is used
> with VFIO. Indeed VFIO attempts to DMA_MAP this region
> as usual RAM but this latter does not have a valid page
> size alignment causing such an error report:
> "vfio_listener_region_add received unaligned region".
> To allow VFIO to detect that failing dma mapping
> this region is not an issue, let's use a ram_device
> memory region type instead.
> 
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> Tested-by: Stefan Berger <stefanb@linux.ibm.com>
> Acked-by: Stefan Berger <stefanb@linux.ibm.com>
> [PMD: Keep tpm_crb.c in meson's softmmu_ss]
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> Link: https://lore.kernel.org/r/20220120001242.230082-2-f4bug@amsat.org
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> ---
>  hw/tpm/tpm_crb.c |   22 ++++++++++++++++++++--
>  1 file changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/tpm/tpm_crb.c b/hw/tpm/tpm_crb.c
> index 58ebd1469c35..be0884ea6031 100644
> --- a/hw/tpm/tpm_crb.c
> +++ b/hw/tpm/tpm_crb.c
> @@ -25,6 +25,7 @@
>  #include "sysemu/tpm_backend.h"
>  #include "sysemu/tpm_util.h"
>  #include "sysemu/reset.h"
> +#include "exec/cpu-common.h"
>  #include "tpm_prop.h"
>  #include "tpm_ppi.h"
>  #include "trace.h"
> @@ -43,6 +44,7 @@ struct CRBState {
>  
>      bool ppi_enabled;
>      TPMPPI ppi;
> +    uint8_t *crb_cmd_buf;
>  };
>  typedef struct CRBState CRBState;
>  
> @@ -291,10 +293,14 @@ static void tpm_crb_realize(DeviceState *dev, Error **errp)
>          return;
>      }
>  
> +    s->crb_cmd_buf = qemu_memalign(qemu_real_host_page_size,
> +                                HOST_PAGE_ALIGN(CRB_CTRL_CMD_SIZE));
> +
>      memory_region_init_io(&s->mmio, OBJECT(s), &tpm_crb_memory_ops, s,
>          "tpm-crb-mmio", sizeof(s->regs));
> -    memory_region_init_ram(&s->cmdmem, OBJECT(s),
> -        "tpm-crb-cmd", CRB_CTRL_CMD_SIZE, errp);
> +    memory_region_init_ram_device_ptr(&s->cmdmem, OBJECT(s), "tpm-crb-cmd",
> +                                      CRB_CTRL_CMD_SIZE, s->crb_cmd_buf);

> +    vmstate_register_ram(&s->cmdmem, DEVICE(s));

Does it need a compat knob for the case of migrating to older QEMU/machine type,
not to end-up with target aborting migration when it sees unknown section.


>      memory_region_add_subregion(get_system_memory(),
>          TPM_CRB_ADDR_BASE, &s->mmio);
> @@ -309,12 +315,24 @@ static void tpm_crb_realize(DeviceState *dev, Error **errp)
>      qemu_register_reset(tpm_crb_reset, dev);
>  }
>  
> +static void tpm_crb_unrealize(DeviceState *dev)
> +{
> +    CRBState *s = CRB(dev);
> +

likewise, should vmstate be unregistered here, before freeing
actually happens?

> +    qemu_vfree(s->crb_cmd_buf);
> +
> +    if (s->ppi_enabled) {
> +        qemu_vfree(s->ppi.buf);
> +    }
> +}
> +
>  static void tpm_crb_class_init(ObjectClass *klass, void *data)
>  {
>      DeviceClass *dc = DEVICE_CLASS(klass);
>      TPMIfClass *tc = TPM_IF_CLASS(klass);
>  
>      dc->realize = tpm_crb_realize;
> +    dc->unrealize = tpm_crb_unrealize;
>      device_class_set_props(dc, tpm_crb_properties);
>      dc->vmsd  = &vmstate_tpm_crb;
>      dc->user_creatable = true;
> 
> 
> 



  reply	other threads:[~2022-02-04 12:20 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-03 22:35 [PULL 0/2] VFIO fixes 2022-02-03 Alex Williamson
2022-02-03 22:35 ` [PULL 1/2] tpm: CRB: Use ram_device for "tpm-crb-cmd" region Alex Williamson
2022-02-04 12:08   ` Igor Mammedov [this message]
2022-02-07  9:23     ` Eric Auger
2022-02-07 13:42     ` Eric Auger
2022-02-23 13:02       ` Dr. David Alan Gilbert
2022-02-03 22:36 ` [PULL 2/2] hw/vfio/common: Silence ram device offset alignment error traces Alex Williamson
2022-02-05 10:49 ` [PULL 0/2] VFIO fixes 2022-02-03 Peter Maydell
2022-02-05 11:19   ` Philippe Mathieu-Daudé via
2022-02-07  9:10     ` Eric Auger
2022-02-07 15:50   ` Alex Williamson
2022-02-07 16:08     ` Philippe Mathieu-Daudé via
2022-02-07 16:54       ` Alex Williamson
2022-02-07 17:47         ` Alex Williamson
2022-02-07 16:20     ` Thomas Huth
2022-06-02 21:31       ` Alex Williamson
2022-06-02 22:15         ` Alex Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220204130846.31f5b396@redhat.com \
    --to=imammedo@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanb@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.