A PCC driver in Qemu

Posted on by
Reply

In order to perform test driven development, you need a way to drive your code that can isolate behavior. Linux Kernel drivers that communicate with hardware devices can be hard to test: you might not have access to the hardware from your test systems, or the hardware may be flakey. I have such a set of issues with the Platform Communication Channel (PCC) drivers I am working with.

My primary work has been with a network driver that only exists on the newest hardware. However, I also need to be able to handle some drivers that would only work against old hardware. There are also PCC based drivers for hardware that my company does not support or have access to. I might want to make a test to ensure that changes to the Linux Kernel PCC driver does not change its behavior against these drivers. There exists no system where all of these drivers would be supported. But I can build one with Qemu.

The Qemu based driver might not completely simulate the hardware exactly as implemented, and that is OK: I want to be able to do things with Qemu I cannot do with current hardware. For example, the MCTP-over-PCC driver should be able to handle a wide array of messages, but the hardware I have access to only supports a very limited subset of message types.

The full code for the device is here.

Here is how I went about building a Qemu based PCC driver.

Continue reading →

Maintaining a change log in a git commit message

Posted on by
Reply

Changes do not always get accepted upon initial submission. My current submission of the MCTP over PCC patch is at revision 37 and will likely have more. Previously, this patch was part of a series, and the change log was displayed in the series header email. However, now that I am down to a single patch, the change log should go in the email message with the patch attached.

It rturns out this is fairly simple to do: Puyt the change log at the =bottom of the commit message, after the Signed-Off-By tag. and after three dashes:

Continue reading →

The Value of Blogging as a programmer

Posted on by
1

Today at the local Python meetup, I repeated my little speech encouraging the other members to blog. They, in turn, suggested I write a blog post explaining what I just told them. It is entirely possible I have written this before in my 2.5 decods of recording my thoughts in web format, but maybe I still have something new to add.

When talking about software, esepcially that brand of software that is written for internal consumption at a company, I find it valuable to frame things in terms of “Me. Us. Them.” I might write something for my personal use. Later I dscover other people on my team can use it,too. Finally, I might find that it is worthwhile to make it availble to the larger organization. I think the same might be true about blogging.

Continue reading →

Limiting What an Agent can do

Posted on by
Reply

I do not work with AI tools. This is not advice from experience of working with AI. It is advice from working with access controls in general.

Any agent has responsibility and authority. Responsibility is what it is required to produce. Authority is the set of resources that you provide to that agent. This does not change if the agent is human or automation, and AI agents fall in to that later category.

Continue reading →

Stacking Protocols

Posted on by
Reply

I find myself writing a program in C that is supposed to handle multiple protocols. At its entry point, the protocol is Platform Communication Channel (extended memory, type 3 and type 4). Embedded in that is an Management Component Transport Protocol (MCTP) message, and embedded in that is one of many different protocols.

I might want to swap out the PCC layer in the future for….something else. MCTP can come over many different protocols, so there is a good be that the tool will be more useful if it can assume that the protocol outside of the MCTP layer is something other than MCTP.

One problem I have is that the MCTP header does not have a length field. We do not not know how long the payload is; all it has is version, source, destination, and flags. Thus, if we want to pass a buffer of type MCTP header along, and we want the length, we need to pass it in a separate field. This goes both for incoming (how many bytes to read) and outgoing (how many bytes to write).

Continue reading →

Install a custom Kernel inside a VM

Posted on by
Reply

When debugging Qemu, it might be helpoful to instrument Linux Kernel to see when interrupts get received, or see data on the other side of a transfer. If you have to modify the Kernel on a regular basis, it can be faster to build it in place than to build a customer RPM/DEB and install inside the VM. Here is how I have been going about updating the kernel.

Continue reading →

Viewing the Flattened Device Tree from Qemu

Posted on by
Reply

The Qemu implementation uses a Flattened Device Tree (FTD) to manage the virtual implementation of the physical devices in a machine. I need to create a FTD entry for the MCTP-PCC implementation I am writing in Qemu. Since this is new to me, and I am working (as I most often do) via Ttrial and error, I want to see the FTD entry after I write it. Here is how I am dumping it.

Continue reading →