Re: [PATCH] hw/i2c/pmbus_device: Fix a possible crash when requesting too many bytes
Titus Rwantare <[email protected]> Tue, 9 Jun 2026 08:51:13 -0700
| Newsgroups | org.nongnu.qemu-trivial,org.nongnu.qemu-arm,org.nongnu.qemu-devel |
|---|---|
| Message-ID | <CAMvPwGpzAcDxeqSvQmOjzkQn6T91CAmTO31bNs0wmSMqQKG=Qg@mail.gmail.com> |
On Tue, 9 Jun 2026 at 08:25, Peter Maydell <[email protected]> wrote: > > 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 I'm not sure this can happen on hardware. The device puts all the bytes on the bus, and the controller can interrupt it with a Repeated START SMBus v3.3 6.5: ``` The data formats implemented by SMBus are: • Controller-transmitter transmits to target-receiver: The transfer direction in this case is not changed. • Controller reads target immediately after the first byte: At the moment of the first acknowledgment (provided by the target-receiver) the controller-transmitter becomes a controller-receiver and the target-receiver becomes a target-transmitter. • Combined format: During a change of direction within a transfer, the controller generates a REPEATED START condition and the target address but with the R/W# set to 1. In this case the controller receiver terminates the transfer by generating a NACK on the last byte of the transfer and a STOP condition. ``` Hmm, seems to me the data gets cleared with a change in direction. -Titus