qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: minyard@acm.org
Cc: qemu-devel@nongnu.org, Peter Maydell <peter.maydell@linaro.org>,
	Corey Minyard <cminyard@mvista.com>
Subject: Re: [Qemu-devel] [PATCH v2 1/2] ipmi: Use proper struct reference for KCS vmstate
Date: Mon, 5 Mar 2018 14:09:26 +0000	[thread overview]
Message-ID: <20180305140926.GK3131@work-vm> (raw)
In-Reply-To: <1520004397-28521-2-git-send-email-minyard@acm.org>

* minyard@acm.org (minyard@acm.org) wrote:
> From: Corey Minyard <cminyard@mvista.com>
> 
> The vmstate for isa_ipmi_kcs was referencing into the kcs structure,
> instead create a kcs structure separate and use that.
> 
> There were also some issues in the state transfer.  The inlen field
> was not being transferred, so if a transaction was in process during
> the transfer it would be messed up.  And the use_irq field was
> transferred, but that should come from the configuration.

> And the
> name on the man VMStateDescription was incorrect, it needed to be
> differentiated from the BT one.

I think that's a bigger problem; lets see below.

> To fix this, a new VMStateDescription is added that is hopefully
> correct, and the old one is kept (modified to remove use_irq) in
> a way that it can be received from the remote but will not be sent.
> So an upgrade should work for KCS.
> 
> Signed-off-by: Corey Minyard <cminyard@mvista.com>
> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
> ---
>  hw/ipmi/isa_ipmi_kcs.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 75 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/ipmi/isa_ipmi_kcs.c b/hw/ipmi/isa_ipmi_kcs.c
> index 689587b..2a2784d 100644
> --- a/hw/ipmi/isa_ipmi_kcs.c
> +++ b/hw/ipmi/isa_ipmi_kcs.c
> @@ -422,14 +422,86 @@ static void ipmi_isa_realize(DeviceState *dev, Error **errp)
>      isa_register_ioport(isadev, &iik->kcs.io, iik->kcs.io_base);
>  }
>  
> -const VMStateDescription vmstate_ISAIPMIKCSDevice = {
> +static int ipmi_kcs_vmstate_post_load(void *opaque, int version)
> +{
> +    IPMIKCS *ik = opaque;
> +
> +    /* Make sure all the values are sane. */
> +    if (ik->outpos >= MAX_IPMI_MSG_SIZE || ik->outlen >= MAX_IPMI_MSG_SIZE ||
> +        ik->outpos >= ik->outlen) {
> +        ik->outpos = 0;
> +        ik->outlen = 0;
> +    }
> +
> +    if (ik->inlen >= MAX_IPMI_MSG_SIZE) {
> +        ik->inlen = 0;
> +    }
> +
> +    return 0;
> +}
> +
> +static const VMStateDescription vmstate_IPMIKCS = {
> +    .name = TYPE_IPMI_INTERFACE_PREFIX "kcs",
> +    .version_id = 1,
> +    .minimum_version_id = 1,
> +    .post_load = ipmi_kcs_vmstate_post_load,
> +    .fields      = (VMStateField[]) {
> +        VMSTATE_BOOL(obf_irq_set, IPMIKCS),
> +        VMSTATE_BOOL(atn_irq_set, IPMIKCS),
> +        VMSTATE_BOOL(irqs_enabled, IPMIKCS),
> +        VMSTATE_UINT32(outpos, IPMIKCS),
> +        VMSTATE_UINT32(outlen, IPMIKCS),
> +        VMSTATE_UINT8_ARRAY(outmsg, IPMIKCS, MAX_IPMI_MSG_SIZE),
> +        VMSTATE_UINT32(inlen, IPMIKCS),
> +        VMSTATE_UINT8_ARRAY(inmsg, IPMIKCS, MAX_IPMI_MSG_SIZE),
> +        VMSTATE_BOOL(write_end, IPMIKCS),
> +        VMSTATE_UINT8(status_reg, IPMIKCS),
> +        VMSTATE_UINT8(data_out_reg, IPMIKCS),
> +        VMSTATE_INT16(data_in_reg, IPMIKCS),
> +        VMSTATE_INT16(cmd_reg, IPMIKCS),
> +        VMSTATE_UINT8(waiting_rsp, IPMIKCS),
> +        VMSTATE_END_OF_LIST()
> +    }
> +};
> +
> +static const VMStateDescription vmstate_ISAIPMIKCSDevice = {
> +    .name = TYPE_IPMI_INTERFACE_PREFIX "isa-kcs",
> +    .version_id = 2,
> +    .minimum_version_id = 2,
> +    .fields      = (VMStateField[]) {
> +        VMSTATE_STRUCT(kcs, ISAIPMIKCSDevice, 1, vmstate_IPMIKCS, IPMIKCS),
> +        VMSTATE_END_OF_LIST()
> +    }
> +};

I've got the following, which is only build tested but:

+static const VMStateDescription vmstate_IPMIKCS = {
+    .name = TYPE_IPMI_INTERFACE_PREFIX "kcs",
+    .version_id = 2,
+    .minimum_version_id = 1,
+    .post_load = ipmi_kcs_vmstate_post_load,
+    .fields      = (VMStateField[]) {
+        VMSTATE_BOOL(obf_irq_set, IPMIKCS),
+        VMSTATE_BOOL(atn_irq_set, IPMIKCS),
+        VMSTATE_UNUSED(1), /* Was use_irq */
+        VMSTATE_BOOL(irqs_enabled, IPMIKCS),
+        VMSTATE_UINT32(outpos, IPMIKCS),
+        VMSTATE_UINT32_V(outlen, IPMIKCS,2),
+        VMSTATE_UINT8_ARRAY(outmsg, IPMIKCS, MAX_IPMI_MSG_SIZE),
+        VMSTATE_UINT32_V(inlen, IPMIKCS,2),
+        VMSTATE_UINT8_ARRAY(inmsg, IPMIKCS, MAX_IPMI_MSG_SIZE),
+        VMSTATE_BOOL(write_end, IPMIKCS),
+        VMSTATE_UINT8(status_reg, IPMIKCS),
+        VMSTATE_UINT8(data_out_reg, IPMIKCS),
+        VMSTATE_INT16(data_in_reg, IPMIKCS),
+        VMSTATE_INT16(cmd_reg, IPMIKCS),
+        VMSTATE_UINT8(waiting_rsp, IPMIKCS),
+        VMSTATE_END_OF_LIST()
+    }
+};
+
+static const VMStateDescription vmstate_ISAIPMIKCSDevice = {
+    .name = TYPE_IPMI_INTERFACE_PREFIX "isa-kcs",
+    .version_id = 2,
+    .minimum_version_id = 2,
+    .fields      = (VMStateField[]) {
+        VMSTATE_STRUCT(kcs, ISAIPMIKCSDevice, 2, vmstate_IPMIKCS, IPMIKCS),
+        VMSTATE_END_OF_LIST()
+    }
+};

Note how the outlen and inlen fields use the _V modifier and are only
bound to v2, and I leave the UNUSED in for use_irq, that means we can
then mae the vmstate_v1_ISAIPMIKCSDevice just have:

const VMStateDescription vmstate_v1_ISAIPMIKCSDevice = {
    .name = TYPE_IPMI_INTERFACE,
    .version_id = 1,
    .minimum_version_id = 1,
    .post_load = ipmi_kcs_v1_vmstate_post_load,
    .needed = ipmi_kcs_v1_vmstate_needed,
    .fields      = (VMStateField[]) {
        VMSTATE_STRUCT(kcs, ISAIPMIKCSDevice, 1, vmstate_IPMIKCS, IPMIKCS),
        VMSTATE_END_OF_LIST()
    }
};

Note the '1'. in the VMSTATE_STRUCT.
As I say, that's untested, but if it works it saves a lot of
duplication.

> +
> +/*
> + * Old version of the vmstate transfer that has a number of issues.
> + * We changed the vm state description name, so we need a separate
> + * structure and need to register it separately.
> + */
> +static int ipmi_kcs_v1_vmstate_post_load(void *opaque, int version)
> +{
> +    ISAIPMIKCSDevice *iik = opaque;
> +
> +    return ipmi_kcs_vmstate_post_load(&iik->kcs, version);
> +}
> +
> +static bool ipmi_kcs_v1_vmstate_needed(void *opaque)
> +{
> +    /* Never transmit this, it is just for receiving old versions. */
> +    return false;
> +}
> +
> +const VMStateDescription vmstate_v1_ISAIPMIKCSDevice = {
>      .name = TYPE_IPMI_INTERFACE,
>      .version_id = 1,
>      .minimum_version_id = 1,
> +    .post_load = ipmi_kcs_v1_vmstate_post_load,
> +    .needed = ipmi_kcs_v1_vmstate_needed,
>      .fields      = (VMStateField[]) {
>          VMSTATE_BOOL(kcs.obf_irq_set, ISAIPMIKCSDevice),
>          VMSTATE_BOOL(kcs.atn_irq_set, ISAIPMIKCSDevice),
> -        VMSTATE_BOOL(kcs.use_irq, ISAIPMIKCSDevice),
> +        VMSTATE_UNUSED(1), /* Was use_irq */
>          VMSTATE_BOOL(kcs.irqs_enabled, ISAIPMIKCSDevice),
>          VMSTATE_UINT32(kcs.outpos, ISAIPMIKCSDevice),
>          VMSTATE_UINT8_ARRAY(kcs.outmsg, ISAIPMIKCSDevice, MAX_IPMI_MSG_SIZE),
> @@ -451,6 +523,7 @@ static void isa_ipmi_kcs_init(Object *obj)
>      ipmi_bmc_find_and_link(obj, (Object **) &iik->kcs.bmc);
>  
>      vmstate_register(NULL, 0, &vmstate_ISAIPMIKCSDevice, iik);
> +    vmstate_register(NULL, 0, &vmstate_v1_ISAIPMIKCSDevice, iik);

OK, a bit scary - I don't think anyone else does that trick of
registering it under two names with a '_needed' always saying false.

So I think we have the istuation where the old version had two things
with the same name, and if you instantiated both device types you
probably lost one of them?
In the new world both the 'bt' one is incompatible and renamed,
but this one has the hack to load the old kcs version;  so I guess
that's OK.

Could you just add a comment above that second vmstate_register
  ' old version had different (clashing) name, register both'

However it's worth asking if it's really worth it, if you just ekpt this
one called TYPE_IPMI_INTERFACE then you wouldn't need that hack, and the
only downside I can see is that loading an image that had a ipmi-bt
would fail badly, as opposed to failing clearly.

Dave

>  }
>  
>  static void *isa_ipmi_kcs_get_backend_data(IPMIInterface *ii)
> -- 
> 2.7.4
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2018-03-05 14:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-02 15:26 [Qemu-devel] [PATCH v2 0/2] ipmi: Fix vmstate transfer minyard
2018-03-02 15:26 ` [Qemu-devel] [PATCH v2 1/2] ipmi: Use proper struct reference for KCS vmstate minyard
2018-03-05 14:09   ` Dr. David Alan Gilbert [this message]
2018-03-05 22:52     ` Corey Minyard
2018-03-06 16:46       ` Corey Minyard
2018-04-24 15:32       ` Dr. David Alan Gilbert
2018-04-24 21:08         ` Corey Minyard
2018-03-02 15:26 ` [Qemu-devel] [PATCH v2 2/2] ipmi: Use proper struct reference for BT vmstate minyard
2018-03-05 12:00   ` Dr. David Alan Gilbert
2018-03-02 20:02 ` [Qemu-devel] [PATCH v2 0/2] ipmi: Fix vmstate transfer Dr. David Alan Gilbert
2018-03-02 20:09   ` Corey Minyard
2018-03-05 13:29 ` Peter Maydell
  -- strict thread matches above, loose matches on Subject: below --
2018-02-14 18:23 minyard
2018-02-14 18:23 ` [Qemu-devel] [PATCH v2 1/2] ipmi: Use proper struct reference for KCS vmstate minyard

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=20180305140926.GK3131@work-vm \
    --to=dgilbert@redhat.com \
    --cc=cminyard@mvista.com \
    --cc=minyard@acm.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).