<div dir="auto">You did the msi interrupt thing for hdmi audio right?<br><br><div data-smartmail="gmail_signature">scott</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Jan 23, 2017 3:34 PM, "Alex Williamson" <<a href="mailto:alex.l.williamson@gmail.com">alex.l.williamson@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 23, 2017 at 12:50 PM, Laszlo Ersek <span dir="ltr"><<a href="mailto:lersek@redhat.com" target="_blank">lersek@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 01/23/17 20:02, Alex Williamson wrote:<br>
<br>
> isolcpus<br>
> <a href="http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/kernel-parameters.txt#n1669" rel="noreferrer" target="_blank">http://git.kernel.org/cgit/lin<wbr>ux/kernel/git/torvalds/linux.<wbr>git/tree/Documentation/admin-<wbr>guide/kernel-parameters.txt#<wbr>n1669</a><br>
<br>
BTW, do you know a method to massage isolcpus without a host reboot? The<br>
last paragraph of the linked section doesn't look promising ("... can<br>
cause problems and suboptimal load balancer performance").<br>
<br>
Sometimes the same host is temporarily dedicated to run a VM where<br>
latency doesn't matter much, but throughput does (example: distcc server<br>
with assigned 1Gbit NIC VF); and sometimes the host is dedicated to a VM<br>
where isolcpus would be beneficial to latency (example: interactive 3D<br>
stuff with assigned GPU).<br>
<br>
It's quite a pain to reboot the host just to switch between these two;<br>
that sort of eliminates the benefits of virtualization. Furthermore,<br>
<br>
- the LUKS password for the host needs to be entered again,<br>
- startup of guests with bridged virtual NICs has to await host DHCP for<br>
internet connectivity again,<br>
- for remote management with virt-manager, the multiplexing SSH master<br>
process on the client has to be re-launched (and then virt-manager has<br>
to be reconnected over the local muxer socket),<br>
- etc<br></blockquote><div><br></div><div>No need to sell me on it, I agree it'd be useful.  I imagine there's some way to do this with cgroups, ie. dynamically add/remove cpus from the default init process cpuset, but it hasn't nagged at me enough to find time to investigate further.  It seems like someone had reported a more dynamic setup.  Thanks,</div><div><br></div><div>Alex</div></div></div></div>
<br>______________________________<wbr>_________________<br>
vfio-users mailing list<br>
<a href="mailto:vfio-users@redhat.com">vfio-users@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/vfio-users" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/vfio-users</a><br>
<br></blockquote></div></div>