On Fri, 2022-10-28 at 13:36 +0200, Paolo Bonzini wrote: > We _should_ be following the Xen API, which does not even say that the > areas have to fit in a single page. In fact, even Linux's > > struct vcpu_register_runstate_memory_area area; > > area.addr.v = &per_cpu(xen_runstate, cpu); > if (HYPERVISOR_vcpu_op(VCPUOP_register_runstate_memory_area, > xen_vcpu_nr(cpu), &area)) > > could fail or not just depending on the linker's whims, if I'm not > very confused. > > Other data structures *do* have to fit in a page, but the runstate area > does not and it's exactly the one where the cache comes the most handy. > For this I'm going to wait for David to answer. Yeah, I recall vetting a bunch of these to ensure that it's safe to assume that it does fit within the page... but that clearly isn't true for the runstate_area. As things stand, I believe a guest is perfectly entitled to provide a region which crosses a page boundary, and Xen copes with that. But as you say, KVM doesn't. However, I don't think this *is* the case where the cache comes in the most handy. The cache is really useful where we have to do *atomic* operations on guest addresses, and doing so directly is a whole lot nicer than futex-style try-it-and-fail-gracefully operations on userspace addresses. For the runstate area, I think we can live with using a gfn_to_hva cache instead, and writing via the userspace address (with appropriate atomicity for the RUNSTATE_runnable case as we have at the moment gating the refresh).
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
