Re: Limitations for Running Xen on KVM Arm64

Hi, I have sent out a patch using IPAS2E1IS. The R version RIPAS2E1IS would only be helpful if we have to invalidate more than one page at a time and this is not possible unless a batch version of hypercall is implemented because otherwise there is only one page removed per hypercall. Although

Limitations for Running Xen on KVM Arm64

Hello Xen development community, I wanted to discuss the limitations that I have faced while running Xen on KVM on Arm64 machines. I hope I am using the right mailing list. The biggest limitation is the costly emulation of instruction tlbi vmalls12e1is in KVM. The cost is exponentially proporti

Re: Limitations for Running Xen on KVM Arm64

Hi, > To clarify, Xen is using the local TLB version. So it should be vmalls12e1. If I understood correctly, won't HCR_EL2.FB makes local TLB, a broadcast one? Mohamed mentioned this in earlier email: > If a core-local TLB invalidate was issued, this bit forces it to become a > broadcast, so tha

Re: Limitations for Running Xen on KVM Arm64

Hi, > Does this mean only one ioctl call will be issue per blob will be used? Yes, one ioctl is issued to add all pages to physmap IOCTL_PRIVCMD_MMAPBATCH_V2 then all pages are removed from physmap as a result of munmap(). > At least to me, it feels like switching to TLBI range (or a series os

Re: Limitations for Running Xen on KVM Arm64

Adding @[email protected] and replying to his questions he asked over #XenDevel:matrix.org. can you add some details why the implementation cannot be optimized in KVM? Asking because I have never seen such issue when running Xen on QEMU (without nested virt enabled). AFAIK w

Re: Limitations for Running Xen on KVM Arm64

> >> Hi Mohamed, >> >> On 30/10/2025 18:33, Mohamed Mediouni wrote: >>>> On 30. Oct 2025, at 14:41, [email protected] wrote: >>>> >>>> Adding @[email protected] and replying to his questions he asked over >>>> #XenDevel:matrix.

Re: [XEN PATCH] xen/arm/p2m: perform IPA-based TLBI for arm64 when IPA is known

Hi Julien, Thanks for your review. > > The first one is addressed by relaxing VMALLS12E1IS -> VMALLE1IS. > > Each CPU have their own private TLBs, so flush between vCPU of the > > same domains is required to avoid translations from vCPUx to "leak" > > to the vCPUy. > > This doesn't really tell me