Hi Sameer,
On 22/11/17 02:17, Goel, Sameer wrote:
On 11/20/2017 7:25 AM, Julien Grall wrote:
On 19/11/17 07:45, Goel, Sameer wrote:
On 10/12/2017 10:36 AM, Julien Grall wrote:
Please use #if 0 rather than removing the code + comment on top. But I am not
sure why you drop the S2 free code. Shouldn't we allocate VMID from the SMMU?
I am picking up the vmid from the domain I am sharing the page tables with.
domain->arch.p2m.vmid. This seemed valid. Please let me know if we want to
generate a different vmid?
The processor and the SMMU may support either 8 or 16bits VMID but I don't
think any thing in the spec says that both processor and SMMU must support the
same value.
So it would be possible to have a processor supporting 16-bits VMID and the
SMMU only 8-bits VMID.
Adding a check at the SMMU initialization might be a solution. But as the code
for allocating the VMID is already present, then I would prefer to we stick
with different the VMID.
Sure. For this iteration I will generate an SMMU specific VMID. Do you think it
would be an optimization to reuse the CPU VMID if SMMU supports 16bit VMID?
The only benefit I can see is if the SMMU support broadcast TLB
maintenance. AFAICT, the driver would need to configure the SMMU for that.
However, I think we should first focus on getting a basic SMMUv3 driver
in Xen. Once this is done, we can look at optimizing the driver.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel