[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 0/2 for-4.12] Introduce runstate area registration with phys address
On 07.03.19 16:02, Julien Grall wrote: So I assume you say about you preferences to not have runstate area mapped because of consuming vmap space for arm64. Also, along that thread you mentioned you that guest might change gva mapping, what is irrelevant to registration with physical address. My reasons to have that runstate mapped are following: - Introducing the new interface we are not burden with legacy, so in charge to impose requirements. In this case - to have runstate area not crossing a page boundary - Global mapping used here does not consume vmap space on arm64. It seems to me x86 guys are ok with mapping as well, at least Roger suggested it from the beginning. So it should be ok for them as well.You left arm32 out of your equations here... Yes, I left arm32 aside. - In case domain is mapping runstate with physical address, it can not change the mapping.This is not entirely correct. The domain can not change the mapping under our feet, but it can still change via the hypercall. There are nothing preventing that with current hypercall and the one your propose. Could you please describe the scenario with more details and the interface used for it? Also vcpu_info needs protections from it. Do you agree? Well the number you showed in the other thread didn't show any improvement at all... So please explain why we should call map_domain_page_global() here and using more vmap on arm32 I'm not expecting vmap might be a practical problem for arm32 based system. With the current implementation numbers are equal to those I have for runstate mapping on access. But I'm not sure my test setup able to distinguish the difference. - IMHO, this implementation is simpler and cleaner than what I have for runstate mapping on access.Did you implement it using access_guest_memory_by_ipa? Not exactly, access_guest_memory_by_ipa() has no implementation for x86. But it is made around that code. But I don't think the implementation you suggest will be that simpler once you deal with the problem above.I missed that problem. Will look at it. -- Sincerely, Andrii Anisov. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |