Dor Laor wrote: >> >> Thinking a little more about this, it isn't about handling hypercalls >> > in > >> userspace, but about handling a virtio sync() in userspace. >> >> So how about having a KVM_HC_WAKE_CHANNEL hypercall (similar to Xen's >> event channel, but assymetric) that has a channel parameter. The >> > kernel > >> handler for that hypercall dispatches calls to either a kernel handler >> or a userspace handler. That means we don't need a separate ETH_SEND, >> ETH_RECEIVE, or BLOCK_SEND hypercalls. >> >> > > Some points: > - These were none receive/send/block_send hypercalls on the first place. > There were just register and notify hypercalls. >
But they were ethernet/block/whatever specific. I'm proposing a single "wake this channel up" hypercall. > - The balloon code also uses hypercalls and let userspace handle them so > higher layer will allow the guest inflate/deflate actions. > That could be ported to virtio. It is actually advantageous to balloon asynchronously. -- Any sufficiently difficult bug is indistinguishable from a feature. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
