Re: qemu for bmc

[Patrick Venture <venture@google.com>]

On Mon, Nov 23, 2020 at 2:58 AM Cédric Le Goater <clg@kaod.org> wrote:
>
> On 11/20/20 5:44 PM, Patrick Venture wrote:
> > On Thu, Nov 19, 2020 at 8:56 AM Patrick Venture <venture@google.com> wrote:
> >>
> >> On Wed, Nov 18, 2020 at 11:41 PM Cédric Le Goater <clg@kaod.org> wrote:
> >>>
> >>> Hello,
> >>>
> >>> On 11/18/20 10:11 PM, Patrick Venture wrote:
> >>>> Patrick;
> >>>>
> >>>> I was looking at a patch series of yours that landed,
> >>>> https://github.com/qemu/qemu/blob/master/hw/arm/aspeed.c#L517 <-- in
> >>>> this line you're referencing a device that appears to be missing from
> >>>> qemu - namely, the pca i2c mux.
> >>>>
> >>>> My question is to the community at large, and you also, is anyone
> >>>> currently implementing this i2c-mux or a similar one?
> >>>
> >>> I haven't seen any patches for this device on the QEMU mailing
> >>> list.
> >>>
> >>> John Wang from Bytedance has started developing some new I2C
> >>> device models for their G220A board. We hope to get that merged
> >>> in 6.0.
> >>>
> >>> If you are interested, we maintain a brief TODO list here
> >>>
> >>>   https://github.com/openbmc/qemu/wiki
> >>
> >> Thanks, I'll take a look.
> >>
> >>>
> >>> Feel free to update.
> >>>
> >>>
> >>> In terms of priority, I think that the support to boot from eMMC
> >>> on the AST2600 is an important one. Reviewing the FSI patches
> >>> also but that's an IBM thing, so it might not interest the
> >>> community that much.
> >>>
> >>> There are quite a few I2C models missing.
> >>
> >> Yes.
> >>
> >>>
> >>> All Aspeed models could be more precise.
> >>>
> >>>
> >>> Google and Nuvoton have merged their models for the npcm750-evb
> >>> and quanta-gsj boards. It would be good to have some interaction
> >>> with them, on bus/device modeling but also on full system emulation.
> >>
> >> Yeah, I believe you've seen my team's patches adding nuvoton support
> >> to Qemu.  It's a WIP, but we're making a lot of headway and hope to
> >> have more Nuvoton 730/750 qemu devices sent to qemu over the coming
> >> days, weeks, etc.
> >>
> >> One of the big gaps that I'm seeing is that we weren't yet looking at
> >> the rest of the board as closely, to see what other devices are
> >> missing, such as the i2c-muxes, etc.  This will be a really good
> >> community convergence point as there are only so many i2c-muxes,
> >> voltage regulators, temperature sensors, that are in common use.
> >>
> >> I'll go through some of our plans as stated and add them to the todo
> >> list.  My team currently isn't focused on aspeed support at present,
> >> but we're keeping an eye on it and are definitely excited to see
> >> others contributing in that space!
> >
> > Cedric,
> >
> > I noticed you wrote the smbus_ipmi device in qemu.
>
> I wrote an experimental iBT device model using a chardev device backend
> to communicate with the external world (the host)

Yeah, I saw this discussion with Havard who effectively owns our Qemu
workflow and has been contributing our initial patches in this regard.
I'm aware there are some ideas on how this should work, and we should
have a couple useful devices going upstream shortly that wire up kcs
to a host-extern device.

My question was specifically regarding the smbus_ipmi device you
implemented for the host:
  - https://github.com/qemu/qemu/blame/master/hw/ipmi/smbus_ipmi.c

Presumably this device can also talk to a kcs-bmc-extern, as it just
requests a bmc property device linkage.

>
> > It looks like this
> > is meant to operate on the host-side using the SSIF driver.
>
> The goal was to connect a Aspeed BMC QEMU machine to a PowerNV QEMU machine
> using an external IPMI BMC. The PowerNV machine uses by default an internal
> BMC simulator but it can be switched to an external one and connect to a
> remote BMC using the OpenIPMI's lanserv serial interface.
>
> It operated on top of the iBT device only.

More or less unrelated to the smbus ipmi device question, since you
replied about the aspeed simulation goal:

Interestingly the KCS host-side works with a remote kcs bmc.  In
addition to the iBT device.

We have working and will be sending up for review shortly:

[Qemu process A: simulation of host]->ipmi_kcs->ipmi_bmc_extern <->
ipmi_host_extern**->nuvoton_ipmi_kcs**->[Qemu process B: simulation of
Nuvoton BMC]

**new devices.

We actually have non-Qemu simulations able to talk to Qemu and vice
versa by just handling the Vm codec translations.

This is data-only and doesn't send the control back and forth for
things like GPIO asserts, etc, yet, but we wanted to get the data
pathway up first.

Patrick

>
> C.
>
>
> > I'm looking at the Kudo BMC board which uses SSIF on the BMC side, and
> > don't see an SSIF driver yet in openbmc/ilnux, but I wanted to
> > validate that the host-side of the equation is what you've provided in
> > Qemu?  Perhaps a silly question, but I've been caught off guard by
> > some bad assumptions recently. :)
> >
> > Thanks,
> > Patrick
> >
> >>
> >>>
> >>> Cheers,
> >>>
> >>> C.
> >>
> >> - Patrick
>