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:	Fri, 17 Jul 2015 16:46:34 +0100
From:	Marc Zyngier <marc.zyngier@....com>
To:	Suravee Suthikulpanit <Suravee.Suthikulpanit@....com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	"hanjun.guo@...aro.org" <hanjun.guo@...aro.org>,
	"tomasz.nowicki@...aro.org" <tomasz.nowicki@...aro.org>
CC:	"rjw@...ysocki.net" <rjw@...ysocki.net>,
	"al.stone@...aro.org" <al.stone@...aro.org>,
	Catalin Marinas <Catalin.Marinas@....com>,
	Will Deacon <Will.Deacon@....com>,
	"msalter@...hat.com" <msalter@...hat.com>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"leo.duran@....com" <leo.duran@....com>,
	"sherry.hurwitz@....com" <sherry.hurwitz@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: Re: [RFCv2 PATCH 0/8] Introducing ACPI support for GICv2m

Hi Suravee,

On 13/07/15 10:14, Suravee Suthikulpanit wrote:
> ACPI core patches for ARM64 are now upstreamed in 4.1. The PCI support
> patches for ARM64 ACPI are also in progress. I am sending out this RFC to
> introduce ACPI support for GICv2m. This would allow MSI to work when
> booting ACPI.
> 
> There are some modifications to the irq_domain and acpi/gsi code.
> 
> Due to a large number of prerequisite patches, I have put together a branch
> on GitHub for review and testing:
> 
> 	https://github.com/ssuthiku/linux.git acpi-pci-msi-rfc2
> 
> This branch has been tested on AMD Seattle Platform. Any feedback and
> comments are appreciated.

I've had a look at this, and mostly the init_alloc_info method you
introduce. I have a few issues with the concept:

- The first thing that annoys me a tiny bit is that the bottom irqchip
(the GIC in your case) is allocating memory on the behalf of all the
others in the stack, while the actual users are sitting on top. It feels
really backward. Why can't this allocation be performed at the top of
the stack? The order of the request goes from top to bottom anyway, so
what am I missing?

- This gic_irq_alloc_info structure is completely GIC specific, and
contains things that don't make much sense to most domains. Here, it is
only useful to the GICv2m driver, but not to the top MSI layer. So why
should this structure be passed around across domains that don't care?

So I'd like to get back to the intent: why do you need to turn the logic
around? I understand that of_phandle_args is not ideal for ACPI, and I'm
happy to find ways around its limitations. But why do we need to reverse
the allocation logic and make this structure global along the stack,
rather than keeping it for local interaction at the frontier of two domains?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ