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

Re: [Xen-devel] [PATCH v2 0/2] ARM: ACPI: IORT: Hide SMMU from hardware domain's IORT table





On 10/12/2017 5:14 PM, Julien Grall wrote:


On 12/10/17 12:22, Manish Jaggi wrote:
Hi Julien,

Why do you omit parts of mail where I have asked a question , please avoid skiping that removes the context.

I believe I answered it just after because you asked twice the same thing. So may I dropped the context but the answer was there...

For your convenience here the replicated answer.

"Why? The generation of IORT is fairly standalone.

And again, this was suggestion to share in the future and an expectation for this series. What I care the most is the generation to be fully separated from the rest."

I raised a valid point and it was totally ignored and you asked me to explain the rationale on a later point.
So if you choose to ignore my first point, how can I put any point.

Well, maybe you should read the e-mail more carefully because your point have been addressed. If they are not, then please say it rather than accusing the reviewers on spending not enough time on your series...

[...]

Now if you see both the codes are quite similar and there is redundancy in libxl and in xen code for preparing ACPI tables for dom0 and domU. The point I am raising is quite clear, if all other tables like MADT, XSDT, RSDP, GTDT etc does not share a common generation code with xen what is so special about IORT. Either we move all generation into a common code or keep redundancy for IORT.

I hope I have shown the code and made the point quite clear.
Please provide a technical answer rather than a simple "Why".

Why do you still continue arguing on how this is going to interact with libxl when your only work now (as I stated in every single e-mail) is for Dom0.

If the generation is generic enough, it will require little code to interface. After all, you only need:
    - informations (e.g DeviceID, MasterID...)
    - buffer for writing the generated IORT

So now it is maybe time for you to suggest an interface we can discuss on.
Sure. A quick draft is shared on mailing list. [1]

[1] https://marc.info/?l=xen-devel&m=150784236208192&w=2

Cheers,



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

 


Rackspace

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