<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 8, 2022 at 2:56 PM Daniel P. Berrangé <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Sep 08, 2022 at 02:24:00PM +0200, Roman Mohr wrote:<br>
> Hi,<br>
> <br>
> <br>
> I have a question regarding capability caching  in the context of KubeVirt.<br>
> Since we start in KubeVirt one libvirt instance per VM, libvirt has to<br>
> re-discover on every VM start the qemu capabilities which leads to a 1-2s+<br>
> delay in startup.<br>
> <br>
> We already discover the features in a dedicated KubeVirt pod on each node.<br>
> Therefore I tried to copy the capabilities over to see if that would work.<br>
> <br>
> It looks like in general it could work, but libvirt seems to detect a<br>
> mismatch in the exposed KVM CPU ID in every pod. Therefore it invalidates<br>
> the cache. The recreated capability cache looks esctly like the original<br>
> one though ...<br>
> <br>
> The check responsible for the invalidation is this:<br>
> <br>
> ```<br>
> Outdated capabilities for '%s': host cpuid changed<br>
> ```<br>
> <br>
> So the KVM_GET_SUPPORTED_CPUID call seems to return<br>
> slightly different values in different containers.<br>
> <br>
> After trying out the attached golang scripts in different containers, I<br>
> could indeed see differences.<br>
> <br>
> I can however not really judge what the differences in these KVM function<br>
> registers mean and I am curious if someone else knows. The files are<br>
> attached too (as json for easy diffing).<br>
<br>
Can you confirm whether the two attached data files were captured<br>
by containers running on the same physical host, or could each<br>
container have run on a different host.<br></blockquote><div><br></div><div>They are coming from the same host, that is the most surprising bit for me.</div><div>I am also very sure that this is the case, because I only had one k8s node from where I took these.</div><div>The containers however differ (obviously) on namespaces and on the privilege level (less obvious). The handler dump is from a fully privileged container.</div><div> </div><div>Thanks for checking.</div><div><br></div><div>Best regards,</div><div>Roman</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
My understanding is that KVM_GET_SUPPORTED_CPUID returns the intersection<br>
of CPUID flags supported by the physical CPUs and CPUID flag supported by<br>
the KVM kernel module.<br>
<br>
IOW, I believe the results should only differe if run across hosts with<br>
differing CPU models and/or kernel versions.<br>
<br>
I've not tried to diagnose exactly which feature bits are different<br>
in your dumps yet.<br>
<br>
With regards,<br>
Daniel<br>
-- <br>
|: <a href="https://berrange.com" rel="noreferrer" target="_blank">https://berrange.com</a>      -o-    <a href="https://www.flickr.com/photos/dberrange" rel="noreferrer" target="_blank">https://www.flickr.com/photos/dberrange</a> :|<br>
|: <a href="https://libvirt.org" rel="noreferrer" target="_blank">https://libvirt.org</a>         -o-            <a href="https://fstop138.berrange.com" rel="noreferrer" target="_blank">https://fstop138.berrange.com</a> :|<br>
|: <a href="https://entangle-photo.org" rel="noreferrer" target="_blank">https://entangle-photo.org</a>    -o-    <a href="https://www.instagram.com/dberrange" rel="noreferrer" target="_blank">https://www.instagram.com/dberrange</a> :|<br>
<br>
</blockquote></div></div>