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