From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751010AbdJBMsT (ORCPT <rfc822;w@1wt.eu>);
        Mon, 2 Oct 2017 08:48:19 -0400
Received: from merlin.infradead.org ([205.233.59.134]:43270 "EHLO
        merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750957AbdJBMsS (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 2 Oct 2017 08:48:18 -0400
Date: Mon, 2 Oct 2017 14:48:11 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
        Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, mingo@redhat.com,
        kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
        Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [patch 3/3] x86: kvm guest side support for KVM_HC_RT_PRIO
 hypercall\
Message-ID: <20171002124811.fryss7fdgghuwopg@hirez.programming.kicks-ass.net>
References: <20170926224925.GA9119@amt.cnet>
 <6f4afefd-8726-13ff-371e-0d3896b4cf6a@redhat.com>
 <20170928004452.GA30040@amt.cnet>
 <10635834-459a-9ec1-624d-febd6b5af243@redhat.com>
 <20170928213508.GA14053@amt.cnet>
 <06b714d8-7b66-6e03-a992-e359241abf84@redhat.com>
 <20170929164006.GC29391@amt.cnet>
 <e3f4e6b0-4974-f1e2-b8a2-6b8cd1fb759e@redhat.com>
 <20170929201747.GB12447@amt.cnet>
 <7bef8150-724f-7021-2a7b-cdc3e193b4c9@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7bef8150-724f-7021-2a7b-cdc3e193b4c9@redhat.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Oct 02, 2017 at 02:30:33PM +0200, Paolo Bonzini wrote:
> I don't understand why is it correct to delay interrupt injection just
> because VCPU0 is running in a spinlock-protected region?  I just cannot
> see the reason why it's safe and not a recipe for priority inversions.

It is indeed not right. Something like:

	raw_spin_lock(&some_lock);

	/* do crud */

	raw_spin_unlock(&some_lock);

Should not hold off the interrupt that tells you your finger is in
imminent danger of becoming detached. Only when we do
local_irq_disable() (ie. raw_spin_lock_irq*() and the like) should we
avoid interrupt delivery.

This whole fixation on spinlock regions is misguided and must stop, its
wrong on all levels.