Re: Call failed: MCTP Endpoint did not respond: Qemu CXL switch with mctp-1.0

[Maverickk 78 <maverickk1778@gmail.com>]

Hi Jonathan,

Thanks for the quick response, this patch works!


Regards
Raghu

On Fri, 17 Mar 2023 at 23:42, Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> On Fri, 17 Mar 2023 16:37:20 +0000
> Jonathan Cameron via <qemu-devel@nongnu.org> wrote:
>
> > On Fri, 17 Mar 2023 00:11:10 +0530
> > Maverickk 78 <maverickk1778@gmail.com> wrote:
> >
> > > Hi
> > >
> > >  I am trying mctp & mctpd with aspeed +buildroot(master) + linux v6.2
> > > with Qemu 7.2.
> > >
> > >
> > > I have added necessary FMAPI related patches into QEMU to support CLX
> > > switch emulation
> > >
> > > RFC-1-2-misc-i2c_mctp_cxl_fmapi-Initial-device-emulation.diff
> > >
> > > RFC-2-3-hw-i2c-add-mctp-core.diff
> > >
> > > RFC-4-4-hw-misc-add-a-toy-i2c-echo-device.diff
> > >
> > > RFC-2-2-arm-virt-Add-aspeed-i2c-controller-and-MCTP-EP-to-enable-MCTP-testing.diff
> > >
> > > RFC-3-3-hw-nvme-add-nvme-management-interface-model.diff
> > >
> > >
> > > Executed following mctp commands to setup the binding,
> > >
> > > mctp link set mctpi2c15 up
> > >
> > > mctp addr add 50 dev mctpi2c15
> > >
> > > mctp link set mctpi2c15 net 11
> > >
> > > systemctl restart mctpd.service
> > >
> > > busctl call xyz.openbmc_project.MCTP /xyz/openbmc_project/mctp
> > > au.com.CodeConstruct.MCTP AssignEndpoint say mctpi2c15 1 0x4d
> > >
> > >
> > >  The above busctl configuration is reaching fmapi patch and sets up
> > > the endpoint id but then mctpd fails with log after timeout.
> > >
> > > Call failed: MCTP Endpoint did not respond
> > >
> > > Any clue what's going on?
> >
> > Hi Raghu,
> >
> > Yikes. Didn't think anyone would still use that series.
> > Not even sure I still have a tree with it on.
> >
> > I'll try and bring up again and get back to you. Might be a little
> > while though.
>
> It is Friday and this was more interesting than what I was planning to do. :)
>
> I think the breakage comes from the async send i2c series that was a month
> or so after the PoC was posted. Issues was it was only entering the _bh once.
>
> Following hack works for me on current mainline (+ CXL patches that shouldn't
> affect this.)
>
>
>
>
> From c8d819835faaec2b2a4755eb891284fe21c0747d Mon Sep 17 00:00:00 2001
> From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Date: Fri, 17 Mar 2023 18:07:08 +0000
> Subject: [PATCH] misc/i2c_mctp_fmapi: Hack
>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
>  hw/misc/i2c_mctp_cxl_fmapi.c | 9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/hw/misc/i2c_mctp_cxl_fmapi.c b/hw/misc/i2c_mctp_cxl_fmapi.c
> index 219e30bfd5..2e2da80264 100644
> --- a/hw/misc/i2c_mctp_cxl_fmapi.c
> +++ b/hw/misc/i2c_mctp_cxl_fmapi.c
> @@ -330,7 +330,7 @@ static int i2c_mctp_cxl_switch_event(I2CSlave *i2c, enum i2c_event event)
>      case I2C_FINISH:
>          s->len = 0;
>          s->state = MCTP_I2C_PROCESS_REQUEST;
> -        qemu_bh_schedule(s->bh);
> +        i2c_bus_master(s->bus, s->bh);
>          return 0;
>      case I2C_NACK:
>      default:
> @@ -671,12 +671,11 @@ static void mctp_bh(void *opaque)
>
>      switch (s->state) {
>      case MCTP_I2C_PROCESS_REQUEST:
> -        i2c_bus_master(s->bus, s->bh);
>          s->state = MCTP_I2C_START_SEND;
> -        return;
> -
> +//        return;
> +        //fallthrough
>      case MCTP_I2C_START_SEND:
> -        i2c_start_send(s->bus, s->source_slave_addr);
> +        i2c_start_send_async(s->bus, s->source_slave_addr);
>          s->send_buf[s->len] = s->source_slave_addr << 1;
>          s->len++;
>          s->state = MCTP_I2C_ACK;
> --
> 2.37.2
>
>
> >
> > Jonathan
> >
> >
> > >
> > >
> > > Regards
> > > Raghu
> >
> >
> >
>