[libvirt PATCH v2 3/3] qemu: add vdpa support
jjongsma at redhat.com
Thu Sep 3 19:07:12 UTC 2020
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
> 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
> 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
> in the initial patch set.
> Same question for migration - is it not possible with these devices,
> we're just not certain or are missing some pieces so we're disabling
> out of caution? For migration it's even more important to implement
> 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
> destination of a migration supports migrating vdpa devices. (I can
> 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.
More information about the libvir-list