linux-kernel - Re: [PATCH 1/1] x86/apic: Introduce paravirq irq

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 15 Aug 2016 14:51:38 +0300
From:	Alexander Popov <alex.popov@...ux.com>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Christoph Hellwig <hch@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Marc Zyngier <marc.zyngier@....com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kees Cook <keescook@...omium.org>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	Jiang Liu <jiang.liu@...ux.intel.com>,
	Jason Cooper <jason@...edaemon.net>,
	Radim Krcmar <rkrcmar@...hat.com>,
	Joerg Roedel <joro@...tes.org>, linux-kernel@...r.kernel.org,
	x86@...nel.org, kvm@...r.kernel.org
Subject: Re: [PATCH 1/1] x86/apic: Introduce paravirq irq_domain

On 13.08.2016 09:20, Paolo Bonzini wrote:
> On 13/08/2016 00:07, Alexander Popov wrote:
>> I.e. our irq_mask()/irq_unmask() callbacks get irq_desc of the interrupt
>> which should be masked/unmasked and can ask the hypervisor to stop/start
>> injecting the vector of that particular interrupt.
> 
> So just let the irqdomain know about your hypervisor and avoid the
> pointless indirection through function pointers, and only call
> arch_init_paravirq_domain in a file specific to your hypervisor.

Paolo, I would like paravirq irq_domain to be useful for many hypervisors,
not only for one developed by Positive Technologies.

It seems to me that the idea of an irq_domain for interrupts injected
by a hypervisor is quite generic.

I don't like such a way of initializing paravirq_chip very much too.
But to my mind, putting some custom hypervisor API to the generic code
in Linux kernel mainline is less attractive. Can we find another solution?

Thank you.
Best regards,
Alexander