> From: Michael S. Tsirkin <m...@redhat.com> > Sent: Wednesday, June 28, 2023 1:16 PM
> > 1. Because than device is 100% sure that it does not fulfill MMIO > > needs 2. Single interface to access extended config space, which is what you > asked for. > > 3. Single driver code because there is single way to get it. > > > > Right. But I think there's a better way. > Just say that any feature in MMIO MUST be also in DMA. > So any modern driver will have no reason at all to use MMIO - DMA is a > superset. > How does that relax the need of MMIO for the device? > If we say that drivers should use DMA, they will. If we additionally explain > that > some features might not be in MMIO no sane driver will use MMIO if it does not > have to. > Or if it does then it has violated the spec and will get less features? > So than why to have it in MMIO anyway? Why not say driver must use dma? > > This demands two ways of access and that conflicts with your point of desire > to do single way. > > I proposed single way, extended config space via DMA interface, that is > > really > as simple as that. > > > My desire is to have a single way that works for everything. > We have legacy so we will have legacy ways too, these might not work for > everything. Here is what can work well, A device tells the offset of the extended config space to the driver. Any field starting from that offset must be accessed via a DMA interface. This way, driver must support DMA and all new features come from there. If device chose to use MMIO, say sw, it can still do it using MMIO. --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
