On Wed, Feb 15, 2023 at 04:06:41PM -0500, Laine Stump wrote: I thought you are missing the @upstream member comparison here, but it looks like it is not used anywhere in the code. So I guess Reviewed-by: Martin Kletzander <mkletzan(a)redhat.com&gt; and I'll do some grave-digging about the long lost member. [...] If I were a nit picker I could tell you to start the sentence with an uppercase letter or remove the full stop. O:-)

On 2/21/23 4:20 AM, Martin Kletzander wrote: Well, yeah, I did miss that, but on the other hand, that isn't in <backend>, which is what the BZ was filed about, and the subject of the patch (and more specifically of this function). I know that's nitpicking, but that explains why the check isn't here (I mean that, along with the fact that I forgot :-)) Believe me when I say there is *a lot* of stuff not checked in that function; at one time it may have been closer to complete, but things get added and people forget to add them to that function. I definitely should have included a check for ->sourceDev (and all the stuff in ->backend / <backend>) in the original patches. It *shouldn't* be copied from olddev to newdev because it is never autofilled during parse or guest startup / device hotplug - the parts of the object that are copied from old to new (if new->blah is empty) are only those things that get filled in automatically with "something" if the attribute isn't specified in the original XML. If you don't specify <source dev='blah'> then sourceDev remains empty. (And in the case of the <source dev='blah'> for direct (macvtap) interfaces, it is a required field, so it can never be empty, and therefore will never be auto-filled with some value if it's missing) olddev->ifname, on the other hand, almost always is auto-filled by libvirt as the guest is starting (a tap/macvtap device is created using a generated name, and that generated name is stored in ->ifname, which ends up being displayed in <target dev='blah'> when the netdef is formatted to XML). If the user has specified a <target dev> in the update XML, and that dev is different from what's in use, we do need to flag that as an error; but if they don't specify anything for target dev, or if what they specified happens to match what it is already set to, then that isn't an error; the cleanest way to handle those cases properly is to copy the attribute from olddev to newdev iff the attribute is empty in newdev. needReconnect was a very nice idea, based on the (false) promise that it was going to be possible to restart the netdev (host) side of an emulated network device without completely unplugging it on the guest side. At one point back in 2011 or 2012 or something, *someone* on the QEMU team made a patch that madde this "kind of" work, and so I modified the update function to classify some previously disallowed changes as needing a full "reconnect" (basically remove the current -netdev and replace it with a new one, without the need of completely unplugging the device on the guest side). Until QEMU had that working, a single check for needReconnect at the end was left generating an error. Unfortunately the QEMU side of that never happened (I have a vague memory that the person who at first suggested they could do it, later told me it simply wasn't possible, for [reasons that sounded plausible], so the bit that logs an error when needReconnect == true was never replaced with code to actually implement the reconnect. Well, you're correct that <source dev='blah'> should be checked for being changed, when the netdev type is 'user' (so it's in ->sourceDev), 'direct' (so it's in ->data.direct.linkdev), and vdpa (so it's in ->data.vdpa.devicepath). But again that's not in <backend>, and there are *so many* other things not being checked for, and it could be a real rabbit hole :-) P.S. I forgot to add your Reviewed-by: before pushing (and also forgot to capitalize the first word of the comment). Sorry. That's what happens when I don't get enough sleep and then wake up early and push something before my brain is fully functioning :-/