On Thu, Apr 09, 2015 at 02:06:47PM +0200, Andrew Jones wrote:
> 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.
huh? I don't understand this, sorry.
> 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.
>
We've reserved a Xen table on ACPI, not sure why we can't do the same
for KVM or a generic ARM PV table for that matter... ?
-Christoffer
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
