> Hmm. I was wrong. There is no way to disable CVQ feature bit. > > 1. Reset the device. > 2. Set the ACKNOWLEDGE status bit: the guest OS has notice the device. > 3. Set the DRIVER status bit: the guest OS knows how to drive the device. > 4. Read device feature bits, and write the subset of feature bits understood by the OS and driver to the > device. During this step the driver MAY read (but MUST NOT write) the device-specific configuration > fields to check that it can support the device before accepting it. > 5. Set the FEATURES_OK status bit. The driver MUST NOT accept new feature bits after this step. > 6. Re-read device status to ensure the FEATURES_OK bit is still set: otherwise, the device does not > support our subset of features and the device is unusable. > 7. Perform device-specific setup, including discovery of virtqueues for the device, optional per-> bus setup, > reading and possibly writing the device’s virtio configuration space, and population of virtqueues. > 8. Set the DRIVER_OK status bit. At this point the device is “live”. > > > So features are confirmed before find vqs. > > The rest of stuff can probably just be moved to after find_vqs without > much pain. > Actually, I think that with a little bit of pain :) If we use small vrings and a GRO feature bit is set, Linux will need to allocate 64KB of continuous memory for every receive descriptor.. Instead of failing probe if GRO/CVQ are set, can we just reset the device if we discover small vrings and start over? Can we remember that this device uses small vrings, and then just avoid negotiating the features that we cannot support? _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
