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

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

[Maverickk 78]

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?


Regards
Raghu

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

[Jonathan Cameron via]

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.

Jonathan


> 
> 
> Regards
> Raghu

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

[Jonathan Cameron via]

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  
> 
> 
> 

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

[Maverickk 78]

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
> >
> >
> >
>