Re: Design doc of adding ACPI support for arm64 on Xen - version 5

From: Ian Campbell <ian.campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>,
	Shannon Zhao <zhaoshenglong@huawei.com>,
	Shannon Zhao <shannon.zhao@linaro.org>
Cc: Hangaohuai <hangaohuai@huawei.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	andrew@fubar.geek.nz,
	"Huangpeng (Peter)" <peter.huangpeng@huawei.com>,
	Julien Grall <julien.grall@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	BorisOstrovsky <boris.ostrovsky@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Parth Dixit <parth.dixit@linaro.org>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	RogerPauMonne <roger.pau@citrix.com>
Subject: Re: Design doc of adding ACPI support for arm64 on Xen - version 5
Date: Wed, 2 Sep 2015 13:54:18 +0100	[thread overview]
Message-ID: <1441198458.26292.172.camel@citrix.com> (raw)
In-Reply-To: <55E43D3A020000780009E3B2@prv-mh.provo.novell.com>

On Mon, 2015-08-31 at 03:40 -0600, Jan Beulich wrote:
> > d) Copy MADT table
> > > > > > It needs to change MADT table to restrict the number of vCPUs. 
> > > > > > We choose
> > > > > > to copy the first dom0_max_vcpus GICC entries of MADT to new 
> > > > > > created
> > > > > > MADT table when numa is not supported currently.
> > > > > 
> > > > > Copy means you imply to have an original?
> > > > 
> > > > So I'll change it to "create".
> > > > 
> > > > > What if dom0_max_vcpus
> > > > > is larger than the physical CPU count?
> > > > 
> > > > I think it only needs to care the cpu_interface_number, uid and 
> > > > mpidr
> > > > field of GICC entry and other fields could be same with the host 
> > > > GICC
> > > > entry. It could get the mpidr from the vCPU index.
> > > 
> > > You again suggest to use data from host entries, i.e. you leave
> > > incompletely addressed the original question: "What source of
> > > information do you intend to use when the Dom0's vCPU count is
> > > higher than the host's pCPU count?"
> > > 
> > 
> > There are only the cpu_interface_number, uid and mpidr which need to
> > change. Other fields could copy from any one of the GICC entries from
> > host MADT table.
> 
> Hmm, okay, if _any one_ is indeed fine, then okay. But then please
> change to wording in your document to make this explicit (and to also
> make explicit that you consider this an okay thing to do in the first
> place, just to catch others' attention to double check it really is).

In the DT world we completely ignore the host /cpus/* nodes when creating
dom0's /cpus/ and instead create our own directly. It would seem logical to
me to do the same for the MADR in ACPI world as well.

Above the cpu_interface_number, uid and mpidr are called out as things we
we know how to create/determine ourselves.

For the other fields you propose copying from a host entry in the MADT, but
it would be better where possible to create our own. Looking at ACPI 6.0 I
see for the MADT table and the various ARM related structures I'm not
immediately seeing any fields which Xen shouldn't be able to decide for
itself.

When creating the node we may of course be relying on things (such as d
->arch.vgic or maybe in some small cases gic_hw_ops) which are initialised
(elsewhere) by values from the host, but form the PoV of creating the MADT
this is abstracted away.

So to give some examples:

      * The GIC redistributor addresses come from d
        ->arch.vgic.rdist_regions[i].
      * the "Parking Protocol Version" ought to be set to reflect Xen's
        support for PSCI, not whatever the host says.
      * "Processor Power Efficiency Class" ought to be some number made up
        by Xen for all processors (probably 0), since the power efficiency
        of a VCPU has nothing to do with any particular PCPU and we assume
        (today) that all VCPUs are equivalent.
      * The GICD version field comes from d->arch.vgic.version

What, if any, fields do you now think should be copied directly from the
host MADT?

Ian.