On Thu, Apr 09, 2015 at 08:57:23AM +0100, 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
To expand on that, if the benefits don't out weight the maintenance
required for that ABI, for life, then it turns into a life-time burden.
Any guest-host speedups that can be conceived, which require hypercalls,
should probably be bounced of the hardware people first. Waiting for
improvements in the virt extensions may be a better choice than
committing to a PV solution.
> - We need a discovery protocol
Hopefully all users of the PSCI hypcall have been using function #0,
because handle_hvc unfortunately hasn't been checking it. In any case,
I'm not sure we have much choice but to start enforcing it now. Once we
do, with something like
switch(hypcall_nr) {
case 0: /* handle psci call */
default: return -KVM_ENOSYS;
}
then, I think the guest's discovery protocol can simply be
if (do_hypercall() == -ENOSYS) {
/* PV path not supported, fall back to whatever... */
}
> - We need to make sure other hypervisors don't reuse the same function
> number for other purposes
I'm not sure what this means. Xen already has several hypercalls defined
for ARM, the same that they have for x86, which don't match any of the
KVM hypercalls. Now, KVM for other arches (which is maybe what you meant)
does define a handful, which we should integrate with, as KVM mixes
architectures within it's hypercall number allocation, see
include/uapi/linux/kvm_para.h. Just using the common code should make it
easy to avoid problems. We don't have a problem with the PSCI hypcall, as
zero isn't allocated. Ideally we would define PSCI properly though,
e.g. KVM_HC_ARM_PSCI, and still reserve zero in the common header. To do
that maybe we'll need to keep #0 as an ARM-only alias for the new number
for compatibility now?
>
> 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?
I don't think we'll ever have a "virt guest" ACPI table that we can
use for this stuff, so this won't work for ACPI. But I think the ENOSYS
probing should be sufficient for this anyway.
drew
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
