On Mon, Nov 02, 2009 at 04:33:53PM -0600, Anthony Liguori wrote: > Michael S. Tsirkin wrote: >> devices should have the final say over which virtio features they >> support. E.g. indirect entries may or may not make sense in the context >> of virtio-console. In particular, for vhost, we do not want to report to >> guest bits not supported by kernel backend. Move the common bits from >> virtio-pci to an inline function and let each device call it. >> >> No functional changes. >> > > This is a layering violation. There are transport specific features and > device specific features. The virtio-net device should have no > knowledge or nack'ing ability for transport features. We could pass "vhost" flag to virtio, and have virtio query the device for features. Would that be better? > If you need to change transport features, it suggests you're modeling > things incorrectly and should be supplying an alternative transport > implementation. > Regards, > > Anthony Liguori Yes, you can make vhost an alternative transport in qemu. This might be one way to handle this. However, this seems to go contrary to your previous proposal to make vhost a networking back end. Which will it be? -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
