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

Re: [Xen-devel] [PATCH V2 9/25] tools/libxl: build DMAR table for a guest with one virtual VTD

On Wed, Aug 23, 2017 at 01:35:17PM +0800, Lan Tianyu wrote:
> On 2017年08月22日 21:48, Wei Liu wrote:
> >> > Hi, Wei
> >> > Thanks for your comments.
> >> > 
> >> > iirc, HVM only supports one module; 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?
> >> > 
> > Thinking a bit more about this, when I first said "conflicts" I didn't
> > mean to parse the content. I was referring to the code in
> > libxl_x86_apci.c which also seems to manipulate acpi_modules.
> Code in libxl_x86_acpi.c works for Hvmlite/PVHv2. The code we added is
> for hvm guest.

That's correct for the code as-is but what is preventing the code there
from working with HVM? Assuming correct checks and branches are added
to appropriate places?

I'm against having multiple locations doing things that could
potentially clash with each other. In the foreseeable future PVH is
going to get need similar functionality.

My expectation is that if the existing code needs to be taken into
consideration and the contributors need to figure out if and how it can
be modified to suite their needs. If everyone is doing their own thing
in their own little function Xen will eventually become unmaintainable.

> > 
> > I would like the code to generate dmar take into consideration
> > libxl__dom_load_acpi.
> > 
> If add dmar table for hvmlite, we should combine dmar table with other
> ACPI table and populate into acpi_modules[2]. This is how hvmlite add
> other ACPI tables in libxl__dom_load_acpi().

Sure, that sounds plausible.

What I would like to see is to have one entry point to manipulate APCI

Given the patch volume we're seeing now, we expect contributors to drive
the discussion forward. If you're not sure, feel free to ask more questions.

> -- 
> Best regards
> Tianyu Lan

Xen-devel mailing list



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