Re: [RFC 7/11] virtio_pci: new, capability-aware driver.
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On Wed, Jan 11, 2012 at 12:25 AM, Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote: > On Tue, 10 Jan 2012 19:03:36 +0200, "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote: >> On Wed, Dec 21, 2011 at 11:03:25AM +1030, Rusty Russell wrote: >> > Yes. The idea that we can alter fields in the device-specific config >> > area is flawed. There may be cases where it doesn't matter, but as an >> > idea it was holed to begin with. >> > >> > We can reduce probability by doing a double read to check, but there are >> > still cases where it will fail. >> >> Okay - want me to propose an interface for that? > > Had a brief chat with BenH (CC'd). > > I think we should deprecate writing to the config space. Only balloon > does it AFAICT, and I can't quite figure out *why* it has an 'active' > field. This solves half the problem, of sync guest writes. For the > other half, I suggest a generation counter; odd means inconsistent. The > guest can poll. > > BenH also convinced me we should finally make the config space LE if > we're going to change things. Since PCI is the most common transport, > guest-endian confuses people. And it sucks for really weird machines. > > We should also change the ring (to a single ring, I think). Descriptors > to 24 bytes long (8 byte cookie, 8 byte addr, 4 byte len, 4 byte flags). > We might be able to squeeze it into 20 bytes but that means packing. We > should support inline, chained or indirect. Let the other side ack by > setting flag, cookie and len (if written). > > Moreover, I think we should make all these changes at once (at least, in > the spec). That makes it a big change, and it'll take longer to > develop, but makes it easy in the long run to differentiate legacy and > modern virtio. This is also an opportunity to stop using CPU physical addresses in the ring and instead perform DMA like a normal PCI device (use bus addresses). Stefan _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization