[Qemu-devel] Ask for ACK (was Re: [PATCH v7 25/35] nvdimm acpi: init the resource used by NVDIMM ACPI)

[Xiao Guangrong <guangrong.xiao@linux.intel.com>]

On 11/09/2015 07:13 PM, Igor Mammedov wrote:
> On Fri, 6 Nov 2015 16:31:43 +0800
> Xiao Guangrong <guangrong.xiao@linux.intel.com> wrote:
>
>>
>>
>> On 11/05/2015 10:49 PM, Igor Mammedov wrote:
>>> On Thu, 5 Nov 2015 21:33:39 +0800
>>> Xiao Guangrong <guangrong.xiao@linux.intel.com> wrote:
>>>
>>>>
>>>>
>>>> On 11/05/2015 09:03 PM, Igor Mammedov wrote:
>>>>> On Thu, 5 Nov 2015 18:15:31 +0800
>>>>> Xiao Guangrong <guangrong.xiao@linux.intel.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 11/05/2015 05:58 PM, Igor Mammedov wrote:
>>>>>>> On Mon,  2 Nov 2015 17:13:27 +0800
>>>>>>> Xiao Guangrong <guangrong.xiao@linux.intel.com> wrote:
>>>>>>>
>>>>>>>> A page staring from 0xFF00000 and IO port 0x0a18 - 0xa1b in guest are
>>>>>>>                                    ^^ missing one 0???
>>>>>>>
>>>>>>>> reserved for NVDIMM ACPI emulation, refer to docs/specs/acpi_nvdimm.txt
>>>>>>>> for detailed design
>>>>>>>>
>>>>>>>> A parameter, 'nvdimm-support', is introduced for PIIX4_PM and ICH9-LPC
>>>>>>>> that controls if nvdimm support is enabled, it is true on default and
>>>>>>>> it is false on 2.4 and its earlier version to keep compatibility
>>>>>>>>
>>>>>>>> Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
>>>>>>> [...]
>>>>>>>
>>>>>>>> @@ -33,6 +33,15 @@
>>>>>>>>       */
>>>>>>>>      #define MIN_NAMESPACE_LABEL_SIZE      (128UL << 10)
>>>>>>>>
>>>>>>>> +/*
>>>>>>>> + * A page staring from 0xFF00000 and IO port 0x0a18 - 0xa1b in guest are
>>>>>>>                                      ^^^ missing 0 or value in define below has an extra 0
>>>>>>>
>>>>>>>> + * reserved for NVDIMM ACPI emulation, refer to docs/specs/acpi_nvdimm.txt
>>>>>>>> + * for detailed design.
>>>>>>>> + */
>>>>>>>> +#define NVDIMM_ACPI_MEM_BASE          0xFF000000ULL
>>>>>>> it still maps RAM at arbitrary place,
>>>>>>> that's the reason why VMGenID patches hasn't been merged for
>>>>>>> more than several months.
>>>>>>> I'm not against of using (more exactly I'm for it) direct mapping
>>>>>>> but we should reach consensus when and how to use it first.
>>>>>>>
>>>>>>> I'd wouldn't use addresses below 4G as it may be used firmware or
>>>>>>> legacy hardware and I won't bet that 0xFF000000ULL won't conflict
>>>>>>> with anything.
>>>>>>> An alternative place to allocate reserve from could be high memory.
>>>>>>> For pc we have "reserved-memory-end" which currently makes sure
>>>>>>> that hotpluggable memory range isn't used by firmware.
>>>>>>>
>>>>>>> How about making API that allows to map additional memory
>>>>>>> ranges before reserved-memory-end and pushes it up as mappings are
>>>>>>> added.
> [...]
>
>>
>> Really a good study case to me, i tried your patch and moved the 64 bit
>> staffs to the private method, it worked. :)
>>
>> Igor, is this the API you want?
>
> Lets get ack from Michael on the idea of RAM mapping before
> "reserved-memory-end" first.
> If he rejects it then there isn't any other way except of switching
> to MMIO instead.

Michael, what's your idea?

BTW, this is the reason why we prefer to reserve memory space just in case
if you missed the thread:
       http://marc.info/?l=qemu-devel&m=144530844718146&w=2