On Sun, Aug 28, 2011 at 7:27 PM, Huang Ying [off-list ref] wrote:

On 08/26/2011 09:43 PM, Bjorn Helgaas wrote:

quoted

On Thu, Aug 25, 2011 at 10:13 PM, Huang Ying [off-list ref] wrote:

quoted

Hi, Pavel,

Sorry,  there is a minor issue in the patch.  Do you have time to try
the updated version attached.

I think Yinghai's patch is a better approach (though it needs a changelog).

The ACPI NVS space should not be marked as "busy" by the e820 code in
the iomem_resource tree.

It's way too complicated to mess around with registering NVS space and
trying to deal with it specially in APEI.

ACPI NVS is different, it can be used only by firmware, and its
interpreter, such as ACPI AML interpreter and APEI interpreter.  It can
not be used by ordinary driver.  If my understanding is correct, this is
why ACPI NVS is marked as busy.

I don't understand why ACPI NVS is different.  If we reserve it in
iomem_resource (without marking it busy), it's already unavailable to
anything else unless you know something connected to the NVS region.

The only way to allocate space inside NVS is to first discover the
ACPI NVS resource, so you could pass it to request_resource() or
allocate_resource() as the "root" to allocate from.  There's no
mechanism for locating that resource, so it's already protected in
that sense.

To use request_mem_region() (which marks the region busy), you all you
need is an address.  The only way for a driver to learn an address
inside NVS is from the ACPI tables.  So I think it's effectively
limited to APEI there, too.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html