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