[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Fix acpi_dmar_zap/reinstate() (fixes S3 regression)



>>> On 22.01.13 at 14:36, Tomasz Wroblewski <tomasz.wroblewski@xxxxxxxxxx> 
>>> wrote:
> 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).

Oh, indeed, I had overlooked that.

> I'll have a go at trying this with ioremap() and retrievable table's 
> physical pointer instead.

Thanks.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.