Re: [Xen-devel] [PATCH RFC 31/35] arm : acpi map status override table to dom0

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 11 Feb 2015, Julien Grall wrote:
> Hi Ian,
> 
> On 05/02/2015 19:47, Ian Campbell wrote:
> > On Thu, 2015-02-05 at 16:27 +0530, Parth Dixit wrote:
> > > > > +    stao->header.length = sizeof(struct acpi_table_header) + 1;
> > > > > +    stao->header.checksum = 0;
> > > > > +    ACPI_MEMCPY(stao->header.oem_id, "LINARO", 6);
> > > > > +    ACPI_MEMCPY(stao->header.oem_table_id, "RTSMVEV8", 8);
> > > > 
> > > > 
> > > > I though the plan was to use a Xen OEM ID?
> > > yes, but its not clear what should be used as xen oem id is not finalized
> > > yet.
> > 
> > Are these IDs the ones defined for x86 in
> > tools/firmware/hvmloader/acpi/acpi2_0.h:
> >          #define ACPI_OEM_ID             "Xen"
> >          #define ACPI_OEM_TABLE_ID       "HVM"
> >          #define ACPI_OEM_REVISION       0
> > 
> >          #define ACPI_CREATOR_ID         ASCII32('H','V','M','L') /*
> > HVMLoader */
> >          #define ACPI_CREATOR_REVISION   0
> > 
> > ? If so we should reuse them, although maybe not OEM_TABLE_ID and
> > CREATOR_ID since those are x86/HVM specific.
> 
> I didn't know that HVMLoader was using one.
> 
> "XenVMM" was decided for ARM (see see
> http://wiki.xenproject.org/mediawiki/images/c/c4/Xen-environment-table.pdf).
> 
> Although, it would be good to have a single OEM ID for Xen project.
> 
> > What is the process for assigning those? Given our unique OEM_ID are we
> > allowed to just declare them ourselves?
> 
> Stefano sent an email to the ACPI guys to know the process. I guess the x86
> one has not been declared?

I don't know the process but on x86 we are already using "Xen" as
OEM_ID, see tools/firmware/hvmloader/acpi/acpi2_0.h

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel