Re: [Xen-devel] [PATCH for-4.12] arm/p2m: do not invalidate p2m root if it is shared with IOMMU

[Julien Grall <julien.grall@xxxxxxx>]

On 1/28/19 4:32 PM, Andrii Anisov wrote:
> Hello Julien,
>
> Actually I was going to send this patch as RFC, but dropped it at the 
> last moment.
> On 28.01.19 17:55, Julien Grall wrote:
> > This was missed on purpose. Let me explain why. The call to 
> > p2m_invalidate_root() arch_domain_creation_finished is called by *all* 
> > the domain at boot to try to optimize the set/way case.
> > The check iommu_use_hap_pt in that context is to prevent guest not 
> > using Set/Way to become unusable under the IOMMU use-case.
> > In your case, you seem to have a guest OS using set/way and yet 
> > sharing the P2M with the IOMMU. You have the choice between:
> >      1) Crashing on IOMMU fault
> >      2) Become very slow and potentially unusable because you now have 
> > to go through the full P2M every time you do a Set/Way.
> > 1) was my favored option because Set/Way should really not be used by 
> > the guest. It was implemented by courtesy to the guest OS and I would 
> > not rely on everything working.
> > Can you explain what is your use-case (OS used, IOMMU, platform...)
> Yep, I'm nearly finished moving our development setup to XEN 4.12-rc.
> The platform is R-Car Gen3 (CA57+CA53), Renesas'es IOMMU named IPMMU is 
> utilized for all peripherals assigned to DomD and GPU shared between 
> DomD and DomA.
> Three OS'es are running on the HW: HW-less Dom0, driver domain DomD with 
> GPU sharing, Android running on PV drivers and GPU sharing.
> So on system start (DomD booting) I see few translation faults from DomD 
> only assigned peripherals. But then Android starts and there are lot of 
> translation faults from GPU trying access DomA memory. Then GPU FW dies.
Hold on, CA57 and CA53 are ARMv8 cores. So are you using 32-bit or 
64-bit guests?
64-bit guest should not have any Set/Way operations unless you are using 
a very very old Linux. So what is the version of each guest?
Cheers,

--
Julien Grall

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