On Fri, Aug 18, 2017 at 01:45:50PM +0800, Chao Gao wrote: > > > >> > + } > >> > + } > >> > + } > >> > >> This still looks wrong to me. How do you know acpi_modules[0] is DMAR > >> table? > >> > > > >Oh, I sorta see why you do this, but I still think this is wrong. The > >DMAR should either be a new module or be joined to the existing one (and > >with all conflicts resolved). > > Hi, Wei > Thanks for your comments. > > iirc, HVM only supports one module;
This is indeed how it is stated in various comments. I'm not sure why there is such restriction. Maybe x86 maintainers can shed more light on this? > DMAR cannot be a new module. Joining to > the existing one is the approach we are taking. > > Which kind of conflicts you think should be resolved? If you mean I > forget to free the old buf, I will fix this. If you mean the potential > overlap between the binary passed by admin and DMAR table built here, I > don't have much idea on this. Even without the DMAR table, the binary > may contains MADT or other tables and tool stacks don't intrepret the > binary and check whether there are conflicts, right? That's true. Ignore the comment about fixing up conflicts then. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
