On Tue, 3 Jul 2018 09:28:17 -0500 Venu Busireddy <venu.busire...@oracle.com> wrote:
> On 2018-07-03 12:58:25 +0300, Roman Kagan wrote: > > On Mon, Jul 02, 2018 at 02:14:52PM -0700, si-wei liu wrote: > > > On 7/2/2018 9:14 AM, Roman Kagan wrote: > > > > Is the scheme going to be applied/extended to other transports (vmbus, > > > > virtio-ccw, etc.)? > > > Well, it depends on the use case, and how feasible it can be extended to > > > other transport due to constraints and transport specifics. > > > > > > > Is the failover group concept going to be used beyond PT-PV network > > > > device failover? > > > Although the concept of failover group is generic, the implementation > > > itself > > > may vary. > > > > My point with these two questions is that since this patchset is > > defining external interfaces -- with guest OS, with management layer -- > > This patch set is not defining any external interfaces. All this is doing > is provide the means and locations to store the "group identifier". How > that info will be used, I thought, should be another patch set. > > Venu > > > which are not easy to change later, it might make sense to try and see > > if the interfaces map to other usecases. E.g. I think we can get enough > > information on how Hyper-V handles PT-PV network device failover from > > the current Linux implementation; it may be a good idea to share some > > concepts and workflows with virtio-pci. But this patch set defines a host<->guest interface to make pairing information on the host available to the guest, no? From my point of view, there are several concerns: - This approach assumes a homogeneous pairing (same transport), and even more, it assumes that this transport is pci. - It won't work for zPCI (although zPCI is really strange) -- this means it will be completely unusable on s390x. - It is too focused on a narrow use case. How is it supposed to be extended? What I would prefer: - Implement a pairing id support that does not rely on a certain transport, but leverages virtio (which is in the game anyway). We'd get at least the "virtio-net device paired with vfio" use case, which is what is currently implemented in the Linux kernel. - Think about a more generic way to relay configuration metadata to the host. --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
