On Fri, Sep 22, 2023 at 11:40:58AM -0400, Michael S. Tsirkin wrote: > On Fri, Sep 22, 2023 at 12:15:34PM -0300, Jason Gunthorpe wrote: > > On Fri, Sep 22, 2023 at 11:13:18AM -0400, Michael S. Tsirkin wrote: > > > On Fri, Sep 22, 2023 at 12:25:06PM +0000, Parav Pandit wrote: > > > > > > > > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > > > > Sent: Friday, September 22, 2023 5:53 PM > > > > > > > > > > > > > > And what's more, using MMIO BAR0 then it can work for legacy. > > > > > > > > > > Oh? How? Our team didn't think so. > > > > > > > > It does not. It was already discussed. > > > > The device reset in legacy is not synchronous. > > > > The drivers do not wait for reset to complete; it was written for the sw backend. > > > > Hence MMIO BAR0 is not the best option in real implementations. > > > > > > Or maybe they made it synchronous in hardware, that's all. > > > After all same is true for the IO BAR0 e.g. for the PF: IO writes > > > are posted anyway. > > > > IO writes are not posted in PCI. > > Aha, I was confused. Thanks for the correction. I guess you just buffer > subsequent transactions while reset is going on and reset quickly enough > for it to be seemless then? >From a hardware perspective the CPU issues an non-posted IO write and then it stops processing until the far side returns an IO completion. Using that you can emulate what the SW virtio model did and delay the CPU from restarting until the reset is completed. Since MMIO is always posted, this is not possible to emulate directly using MMIO. Converting IO into non-posted admin commands is a fairly close recreation to what actual HW would do. Jason
