From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomasz Wroblewski Subject: Re: [PATCH] Fix acpi_dmar_zap/reinstate() (fixes S3 regression) Date: Tue, 22 Jan 2013 14:36:46 +0100 Message-ID: <50FE95EE.207@citrix.com> References: <50FE8126.8080005@citrix.com> <50FE9B1802000078000B84A1@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <50FE9B1802000078000B84A1@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 22/01/13 13:58, Jan Beulich wrote: Jan, thanks for your comments > I recognize the need of fixing this, but not this way. We have > ioremap() now, and hence the patch could be using this, > without re-running the whole acpi_get_table(), but just using > the stored physical address of the table (retrieving of which > would be the only real code addition needed here). > > For the older trees with non-functional ioremap(), I'd prefer > simply adding the table range to the 1:1 mapping (thus making > ioremap() work for that range, should use of that be needed; > if not needed, that's certainly worth considering this even for > -unstable). > > Also, with your change not even attempting to fix the underlying > issue of the ACPI code storing a pointer to the mapped table in > acpi_gbl_root_table_list.tables[].pointer, I can't even see how > your patch is supposed to work. I'd expect the stored pointer to > get re-used by acpi_get_table()/acpi_tb_verify_table(), and hence > this shouldn't win you anything. > It works because the existing code in acpi_get_table actually sets acpi_gbl_root_table_list.tables[i].pointer = NULL every call anyway (after setting *out_table pointer). I'll have a go at trying this with ioremap() and retrievable table's physical pointer instead.