qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Call failed: MCTP Endpoint did not respond: Qemu CXL switch with mct


From: Jonathan Cameron
Subject: Re: Call failed: MCTP Endpoint did not respond: Qemu CXL switch with mctp-1.0
Date: Fri, 17 Mar 2023 18:12:05 +0000

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]