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

[Xiao Guangrong]

On 11/09/2015 07:13 PM, Igor Mammedov wrote:
> On Fri, 6 Nov 2015 16:31:43 +0800
> Xiao Guangrong <address@hidden> wrote:
>
> > On 11/05/2015 10:49 PM, Igor Mammedov wrote:
> > > On Thu, 5 Nov 2015 21:33:39 +0800
> > > Xiao Guangrong <address@hidden> wrote:
> > >
> > > > On 11/05/2015 09:03 PM, Igor Mammedov wrote:
> > > > > On Thu, 5 Nov 2015 18:15:31 +0800
> > > > > Xiao Guangrong <address@hidden> wrote:
> > > > >
> > > > > > On 11/05/2015 05:58 PM, Igor Mammedov wrote:
> > > > > > > On Mon,  2 Nov 2015 17:13:27 +0800
> > > > > > > Xiao Guangrong <address@hidden> 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 <address@hidden>
> > > > > > > [...]
> > > > > > >
> > > > > > > > @@ -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