lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 1 Dec 2016 14:28:12 -0800
From:   yunhong jiang <yunhong.jiang@...ux.intel.com>
To:     Chris Metcalf <cmetcalf@...lanox.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Paolo Bonzini <pbonzini@...hat.com>
Subject: Questions on the task isolation patches

Hi, Chris
    I noticed your task isolation patch set at
https://lkml.org/lkml/2016/8/9/759 . Thanks a lot for the great effort.

    I checked the patch and have some questions about how to use this
functionality on the NFV environment. In the NFV scenario, high speed network
code runs on a VM user space and the VM is hosted by KVM hypervisor. To achieve
the high speed network, not only the network code should be isolated, also the
vCPU thread.

    I checked your patch to think how to isolate the vCPU thread, and I have
some questions and hope your hints:

a) If the task isolation need prctl to mark itself as isolated,
possibly the vCPU thread can't achieve it. First, the vCPU thread may
need system service during OS booting time, also it's the application,
instead of the vCPU thread to decide if the vCPU thread should be
isolated. So possibly we need a mechanism so that another process can
set the vCPU thread's task isolation?

b) I noticed that curently the task_isolation_prepare() is invoked on
exit_to_usermode_loop(), while we may need such job on VM Exit procedure, or
interrupt handling during VM exit handling.

    Also, I'm also considering how to utilize this task_isolation for network
node which is not busy-loop, like the interrupt mode DPDK code. In the
interrupt mode DPDK code, the application may yield the CPU if there is no
network packet for a very long time and it will re-enter the busy loop mode
once new packet arrived. This interrupt mode will be helpful for both power
management and resource utilization. Per my understanding, the application
should turn off the task isolation before yield the CPU and the restart the
task isolation after the new packet, right?

Thanks
--jyh 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ