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. 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? - Mario > > Thanks, > > M. > _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
