[vfio-users] CPU pinning with cgroups

[Blank Field]

...but wait, there's more!
If you unplug the p-t'd device from the host while VM is offline, the VM
will fail to boot.
There's still a lot of work to be done with USB.
On Sep 8, 2015 5:51 PM, "Will Marler" <will at wmarler.com> wrote:

> USB pass-through works quite well with libvirt/virt-manager now; I've used
> it for mouse, keyboard, two different audio devices, while the guest was
> running. There's one feature request that I haven't gotten around to
> submitting; have an "enable/disable" checkbox in the virt-manager gui (I
> will not always want to p-t a USB device, but I will want to frequently
> enough that deleting it & re-adding it each time gets on my nerves).
>
> On Tue, Sep 8, 2015 at 12:15 AM, Quentin Deldycke <
> quentindeldycke at gmail.com> wrote:
>
>> My main problem with libvirt was:
>>
>>
>>    - no ovmf support at the time i created my vm on debian
>>    - No correct usb passthrough
>>
>>
>> The qemu monitor support the device_add command. Which let me bind /
>> unbind usb devices at runtime, without limit of number.
>>
>> I really love libvirt at my job, but for this particular case, i found it
>> less interesting..
>>
>>
>> --
>> Deldycke Quentin
>>
>>
>> On 8 September 2015 at 06:23, Will Marler <will at wmarler.com> wrote:
>>
>>> Not to mention, you can still see the actual qemu invocation script in
>>> the logs when you use libvirt, in case you *really* want to (though a
>>> pastebin share of your libvirt xml config is better, imo ...)
>>>
>>> On Mon, Sep 7, 2015 at 10:15 PM, Jon Panozzo <jonp at lime-technology.com>
>>> wrote:
>>>
>>>> Just to second Alex's point here, I see a lot of folks doing QEMU the
>>>> old fashioned way, which is to say, manual invocation.  Libvirt really is
>>>> an amazing management solution and makes things so much easier.  Lots of
>>>> things can go awry if you're invoking QEMU manually, and libvirt can
>>>> prevent that, as well as automate many other aspects of management that
>>>> manual QEMU invocation cannot.
>>>> On Sep 7, 2015 3:20 PM, "Alex Williamson" <alex.l.williamson at gmail.com>
>>>> wrote:
>>>>
>>>>> On Sun, Sep 6, 2015 at 7:19 PM, Garrett Powell <
>>>>> garretttracypowell at gmail.com> wrote:
>>>>>
>>>>>> I've been having trouble with my guest freezing up, which I'm told is
>>>>>> due to a lack of CPU pinning. I'm currently trying to set up CPU pinning
>>>>>> with cgroups (specifically cpuset), but the freezing isn't going away.
>>>>>> Could anyone tell me what I'm doing wrong? I'm specifically referring to
>>>>>> the *cgcreate*, *cgset *and* cgexec* lines. Here's my launch script:
>>>>>>
>>>>>> #!/bin/bash
>>>>>>
>>>>>> export QEMU_AUDIO_DRV=pa
>>>>>> export QEMU_PA_SERVER=localhost
>>>>>> export PULSE_SERVER=localhost
>>>>>>
>>>>>> vfio-bind 0000:06:00.0
>>>>>>
>>>>>> synergys --daemon --config /etc/synergy.conf
>>>>>>
>>>>>> for i in {0..3}; do
>>>>>>     echo performance >
>>>>>> /sys/devices/system/cpu/cpu${i}/cpufreq/scaling_governor
>>>>>> done
>>>>>>
>>>>>> echo 5120 > /proc/sys/vm/nr_hugepages
>>>>>>
>>>>>> cgcreate -g cpuset:kvm
>>>>>> cgset -r cpuset.cpus=0-3 -r cpuset.mems=0 -r cpuset.cpu_exclusive=1
>>>>>> kvm
>>>>>> cgexec -g cpuset:kvm qemu-system-x86_64 \
>>>>>>
>>>>>
>>>>> Ok, so you've change to pCPUs 0-3 instead of 4-7, but doesn't this
>>>>> have the same problem as your previous attempt with taskset?  You're using
>>>>> a different tool, but afaict you're still not doing 1:1 pinning of vCPUs,
>>>>> you're pining them to a set of pCPUs.  Taskset can work, but you need to
>>>>> get the thread ID for each vCPU thread and pin it.  The problem is not the
>>>>> tool you're using but how you're using it, to set the entire process and
>>>>> all the threads it will launch to a range of CPUs rather than pulling out
>>>>> the vCPU threads and individually pinning them.  There's this really great
>>>>> tool that already does this, it's called libvirt.  Thanks,
>>>>>
>>>>> Alex
>>>>>
>>>>> _______________________________________________
>>>>> vfio-users mailing list
>>>>> vfio-users at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/vfio-users
>>>>>
>>>>>
>>>> _______________________________________________
>>>> vfio-users mailing list
>>>> vfio-users at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/vfio-users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> vfio-users mailing list
>>> vfio-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/vfio-users
>>>
>>>
>>
>
> _______________________________________________
> vfio-users mailing list
> vfio-users at redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20150908/951faa8d/attachment.htm>