[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] RT Xen on ARM - R-Car series
Hi,
Sorry for the formatting.
On 04.02.19 13:21, Julien Grall wrote:
> What I meant is the virtual address stays the same but the guest physical address may change. I don't see how this could be broken today, can you explain it?
I suppose guest's mapping change is not quite atomic from the hypervisor point of view, so domain could be caught in the middle.
Well that's an issue with any hypercall using virtual address. You are not even protected because of shatterring.
Thanksfully that does not seem to happen on Linux. Although, I have seen error some times on osstest...
Virtual address has other issues if you can't access page-tables. So ideally, we want to switch all hypercalls to use guest physical address.
>
>> Moreover, having that buffer mapped to XEN will reduce context switch time as a side effect.
>
> I am still unsure whether we really want to keep that always mapped.
>
> Each guest can support up to 128 vCPUs. So we would have 128 runstates mapped. Each runstate would take up to 2 pages. This means that each guest would require up to 1MB of vmap.
Here buffer allocation on XEN side might benefit, even aligning/fitting the runstate into one page might work. But I understand it is undesirable and requires lot of changes
For a new interface, the way to go is using guest physical address. Any hypercall using virtual address should be killed.
> I thought more about it during the week-end. I would actually not implement get_gfn but implement a function similar to get_page_from_gva on x86. The reason behind this is the function on Arm is quite complex as it caters many different use case.
I'll look into this. But I have to massage my yocto first.
Thank you!
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
