Re: [PATCH] hw/i2c/pmbus_device: Fix a possible crash when requesting too many bytes

Peter Maydell <[email protected]> Tue, 9 Jun 2026 16:25:37 +0100
Newsgroups org.nongnu.qemu-trivial,org.nongnu.qemu-arm,org.nongnu.qemu-devel
Message-ID <CAFEAcA9N_O7RZRU+SPTfB_ePasjVZvUsFPhndfQDuHgQ+4Q-5A@mail.gmail.com>
On Tue, 9 Jun 2026 at 15:52, Titus Rwantare <[email protected]> wrote:
>
> On Tue, 9 Jun 2026 at 04:01, Peter Maydell <[email protected]> wrote:
> > I had a look at this bug earlier, but was not sure that this is the
> > right thing. What happens is that the guest does something that
> > causes the device to queue up data X ready for the guest to
> > read, but then instead of reading it, the guest does another
> > "I would like data X please" action. My guess is that the way
> > the hardware handles this is probably not "add the second
> > copy of data X after the first one". Perhaps it is "drop the
> > data the guest didn't read, so the next guest read gets the
> > second lot of data, not the first". But maybe the spec really
> > does say "you can do things in the order 'ask for A, ask for
> > B, read data for A, read data for B".
> >
> > I couldn't conveniently find the pmbus spec to find out what
> > the hardware is supposed to do here. We need some input from
> > somebody who knows about pmbus.

> Queueing reads are an implementation detail I decided on, not part of
> the spec. How the data gets discarded is up to the device
> manufacturer.

So what *does* the spec say? Does it just say that if you don't
read all the data before doing something else then it's all
unpredictable? Is there a way for the guest to get the device
back into a sane state after it's broken it like that?

-- PMM