Re: [PATCH 2/2] qemu: Update next usable PCI slot on domain reconnect

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > The hash iterator visits in an unpredictable order. It shouldn't matter
> > because for this usage, all that is important is that 'nextslot' eventually
> > ends up with the largest slot ID + 1.
> 
> We don't want the first unused slot, rather the last slot reservation
> that was in place before the reconnect (often the first unused slot if
> you haven't done a lot of hot-unplugging, but not necessarily the case).
>  The only way I can see to get at this is to revisit the reservations in
> the same order as they were reserved, rather than in the random order

Actually, thinking about it you are right that setting nextslot to the largest
slot used + 1 is not always correct. Even when no PCI devices are
added/removed after a guest is started, nextslot doesn't have to look like
that. E.g., if there is a device with explicit PCI address 0:0:31 in the XML.
Although in normal configurations it would work.

However, if we start thinking about hot(un)plugging PCI devices, even your
suggestion of revisiting reservations in the original order wouldn't help much
since the last device which influenced nextslot value might have been already
unplugged from the guest. The only solution which really updates nextslot to
exactly the same value it had before restarting libvirt is storing it in the
runtime XML inside <domstatus>, from where it can be just read when the domain
is being reconnected.

Jirka

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]