[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <65187421-39c8-617f-56bd-d6bd69dfbaee@mellanox.com>
Date: Thu, 22 Dec 2016 15:56:57 -0500
From: Chris Metcalf <cmetcalf@...lanox.com>
To: Paolo Bonzini <pbonzini@...hat.com>,
yunhong jiang <yunhong.jiang@...ux.intel.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Questions on the task isolation patches
On 12/20/2016 4:27 AM, Paolo Bonzini wrote:
> On 16/12/2016 22:00, Chris Metcalf wrote:
>> Sorry, I think I wasn't clear. Normally when you are running task
>> isolated and you enter the kernel, you will get a fatal signal. The
>> exception is if you call prctl itself (or exit), the kernel tolerates
>> it without a signal, since obviously that's how you need to cleanly
>> tell the kernel you are done with task isolation.
> Running in a guest is pretty much the same as running in userspace.
> Would it be possible to exclude the KVM_RUN ioctl as well? QEMU would
> still have to run prctl when a CPU goes to sleep, and KVM_RUN would have
> to enable/disable isolated mode when a VM executes HLT (which should
> never happen anyway in NFV scenarios).
I think that probably makes sense. The flow would be that qemu executes
first the prctl() for task isolation, then the KVM_RUN ioctl. We obviously can't
do it in the other order, so we'd need to make task isolation tolerate KVM_RUN.
I won't try to do it for my next patch series (based on 4.10) though, since I'd
like to get the basic support upstreamed before trying to extend it.
--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com
Powered by blists - more mailing lists