On 10/04/15 03:36, Mario Smarduch wrote: > On 04/09/2015 12:57 AM, Marc Zyngier wrote: >> On Thu, 9 Apr 2015 02:46:54 +0100 >> Mario Smarduch <m.smarduch@xxxxxxxxxxx> wrote: >> >> Hi Mario, >> >>> I'm working with AsyncPF, and currently using >>> hyp call to communicate guest GFN for host to inject >>> virtual abort - page not available/page available. >>> >>> Currently only PSCI makes use of that interface, >>> (handle_hvc()) can we overload interface with additional >>> hyp calls in this case pass guest gfn? Set arg0 >>> to some range outside of PSCI use. >> >> I can't see a reason why we wouldn't open handle_hvc() to other >> paravirtualized services. But this has to be done with extreme caution: >> >> - This becomes an ABI between host and guest >> - We need a discovery protocol >> - We need to make sure other hypervisors don't reuse the same function >> number for other purposes >> >> Maybe we should adopt Xen's idea of a hypervisor node in DT where we >> would describe the various services? How will that work with ACPI? >> >> Coming back to AsyncPF, and purely out of curiosity: why do you need a >> HYP entry point? From what I remember, AsyncPF works by injecting a >> fault in the guest when the page is found not present or made >> available, with the GFN being stored in a per-vcpu memory location. >> >> Am I missing something obvious? Or have I just displayed my ignorance on >> this subject? ;-) > Hi Marc, > > Or it might be me :) > > But I'm thinking Guest and host need to agree on some per-vcpu > guest memory for KVM to write PV-fault type, and Guest to read > the PV-fault type, ack it, i.e. Having the guest allocate the per-cpu > PV-fault memory and inform KVM with its GPA via hyp call is one > approach I was thinking off. Ah, I see what you mean. I was only looking at the runtime aspect of things, and didn't consider the (all important) setup stage. > I was looking through x86 that's based on CPUID extended with > PV feature support. In the guest if the ASYNC PF feature is enabled > it writes GPA to ASYNC PF MSR that's resolved in KVM (x86 folks > can correct if I'm off here). > > I'm wondering if we could build on this concept maybe PV ID_* registers, > to discover existence of ASYNC PF feature? I suppose we could do something similar with the ImpDef encoding space (i.e. what is trapped using HCR_EL2.TIDCP). The main issue with that is to be able to safely carve out a range that will never be used by any HW implementation, ever. I can't really see how we enforce this. Also, it will have the exact same cost as a hypercall, so maybe it is bit of a moot point. Anyway, this is "just" a matter of being able to describe the feature to the guest (and it seems like this is the real controversial aspect)... Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
