On Wed, Jul 25, 2018 at 04:39:28PM +0200, Igor Mammedov wrote:
> > > > +void cst_register(FWCfgState *s, uint16_t ioport)
> > > > +{
> > > > + cst_ssdt_setup();
> > > > +
> > > > + /* Allocate guest scratch memory for the table */
> > > > + cst_scratch = g_array_new(false, true, 1);
> > > > + acpi_data_push(cst_scratch, 4096);
> > > > + fw_cfg_add_file(s, ACPI_SCRATCH_BUFFER_NAME, cst_scratch->data,
> > > > + cst_scratch->len);
> > > > +
> > > > + /* setup io to trigger updates */
> > > > + memory_region_init_io(&cst_mr, NULL, &cst_ops, NULL,
> > > > "cst-update-request", 4);
> > > > + memory_region_add_subregion(get_system_io(), ioport, &cst_mr);
> > > it eats yet another IO port and a 4K page just for CST.
> >
> > 4K is a scratch pad we can reuse for any dynamic table.
> >
> > Address is in fact 4K aligned - what if we reuse low bits in the io port
> > for signal type? This way we won't burn more ports for the next dynamic
> > table.
> yep, and we already use it for nvdimm's NFIT table.
> Earlier I've commented on HMAT series that tried to allocate another
> IO&4K page that we should generalize and reuse NFIT implementation.
That's a good point, I forgot about NFIT.
I agree there's no good reason to burn up more IO ports and memory,
I'll look into reusing NFIT buffer and ports.
--
MST
