Re: [Xen-devel] [RFC] Device memory mappings for Dom0 on ARM64 ACPI systems

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Fri, Jan 20, 2017 at 02:53:34PM -0800, Stefano Stabellini wrote:
> On Fri, 20 Jan 2017, Roger Pau Monné wrote:
> > > > > So you need DOM0 to tell the list of regions.
> > > > 
> > > > Yes, I agree that we need such hypercall ATM, although I think that we 
> > > > might be
> > > > able to get rid of it in the long term if we are able to parse the AML 
> > > > tables
> > > > from Xen.
> > > 
> > > Are you suggesting to bring a full AML parser in Xen? If so, it will be 
> > > much
> > > bigger than Xen ARM itself. I would need a strong use case to accept a 
> > > such
> > > thing.
> > 
> > It could be placed in the init section, and get rid of it after boot. Also, 
> > I
> > find it hard to believe that an AML parser is bigger than the whole Xen on 
> > ARM.
> > The OpenBSD folks have a DSDT parser in ~4000 lines of code [0], and that's
> > probably way more than what Xen actually needs.
> 
> Even if it were actually possible, 4 KLOC is a significant increase in
> code size, given that last time I counted Xen on ARM was under 90 KLOC.
> Regardless, some AML methods have side effects. I don't know if the plan
> of accessing some AML in Xen, then remapping tables and accessing them
> again in Dom0 is actually sound. I don't think the spec supports it.

Sure, Xen wouldn't be allowed to execute any AML method (so it's probably even
less than 4KLOC, if the code is ripped). But Xen would be able to discover
OperationRegions. In any case this is future work, and the hypercall route
seems the most sensible one right now, we could always return -EEXIST if Xen
starts mapping all this on behalf of the hardware domain at some point.

I just wanted to point this out because I think the claims that have been made
about AML parsers being bigger than Xen itself are not true, and discarding
them based on size only is not reasonable.

Roger.

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