On 12/2/20 9:20 AM, Paolo Bonzini wrote: > On 30/11/20 23:42, David Woodhouse wrote: >> Yes, good point. >> >> Xen*does* allow one hypercall (HVMOP_guest_request_vm_event) from >> !CPL0 so I don't think I can get away with allowing only CPL0 like >> kvm_hv_hypercall() does. >> >> So unless I'm going to do that filtering in kernel (ick) I think we do >> need to capture and pass up the CPL, as you say. Which means it doesn't >> fit in the existing kvm_run->hypercall structure unless I'm prepared to >> rename/abuse the ->hypercall.pad for it. >> >> I'll just use Joao's version of the hypercall support, and add cpl to >> struct kvm_xen_exit.hcall. Userspace can inject the UD# where >> appropriate. > > Or you can use sync regs perhaps. For your specific use I don't expect > many exits to userspace other than Xen hypercalls, so it should be okay > to always run with KVM_SYNC_X86_REGS|KVM_SYNC_X86_SREGS in > kvm_run->kvm_valid_regs. > For interdomain event channels, you can still expect quite a few, if your blkfront and netfront are trying to go at maximum offered throughput. Meaning it's not only setup of the guest, but also driver datapath operations. Assuming of course that vTimer/vIPI are offloaded to the kernel.
