[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC 09/15] xen/arm: refactor construct_dom0



On Thu, 5 Jul 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 05/07/2018 21:55, Stefano Stabellini wrote:
> > On Fri, 15 Jun 2018, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 06/15/2018 12:35 AM, Stefano Stabellini wrote:
> > > > On Thu, 14 Jun 2018, Julien Grall wrote:
> > > > > On 13/06/18 23:15, Stefano Stabellini wrote:
> > > if ( !is_hardware_domain(d) )
> > >    prepare_dtb_domU(...);
> > > else if ( acpi_disabled )
> > >    prepare_acpi_hwdom(...);
> > > else
> > >    prepare_dt_hwdom(....);
> > 
> > The few remaining things in construct_dom0 and construct_domU are
> > different enough that I don't think there is much gain in trying to
> > merge them.
> 
> Do you have a concrete example? When I looked at it the only things I can find
> different are:
>    - iommu_hwdom_init() -> Most likely you would need a similar call somewhere
> for Guest DomU.
>    - find_gnttab_region -> I think this could be re-ordered
>    - gic_map_hwdom_extra_mappings & platform_specific_mapping -> This can be
> called before the construct.
> 
> So I don't see why we can't merge most of the code and still have few lines
> for Dom0.
> 
> Overall I would much prefer if we don't duplicate the allocation of the memory
> or anything that is not Dom0 specific.

You might be right, but the series has changed significantly since the
RFC. Let's give a look at v2, you'll get a more concrete idea. Then,
I'll do any required changes in v3.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.