On Thu, 2020-09-03 at 00:55 -0400, Laine Stump wrote: > On 9/2/20 3:25 PM, Jonathon Jongsma wrote: > > Enable <interface type='vdpa'> for qemu domains. This provides > > basic > > support and does not support hotplug or migration. > > Is there something specifically preventing hotplug, or you just > haven't > implemented it yet? I don't think there's anything preventing it. I avoided it for this first patch in order to keep things simpler, and because I am currently unable to test with actual hardware... > > (How does that work with FD passing, anyway? I haven't really looked > at > the details of FD passing...) I believe it requires first calling the qmp add-fd command to register an fd with a /dev/fdset/N "filename". Then I can use the /dev/fdset/N for the netdev_add qmp command. It's a little less straightforward than doing it launch time. At launch time you have an array of all of the fds that are passed to qemu via virCommandPassFD() and you can register the fdset id 'N' based on the array index. But at runtime, you don't know what fdsets have already been registered with the current qemu process. But it should be doable. I had actually started working on that before sending out this series. I'll try to finish it up. > > If hotplug is possible, then I really think that needs to be > implemented > in the initial patch set. > > > Same question for migration - is it not possible with these devices, > or > we're just not certain or are missing some pieces so we're disabling > it > out of caution? For migration it's even more important to implement > it > with the initial patches if it works at all. Otherwise, once we do > implement it, we'll have to have a way of detecting whether or not > the > destination of a migration supports migrating vdpa devices. (I can > see > where it simply may not work, since I guess the hardware's memory is > used for packet buffers, right?) Unfortunately, I'm not sure about this. I'll have to ask around. Jonathon
