Anthony Liguori wrote:
Avi Kivity wrote:
There's no reason that the PIO operations couldn't be handled in the
kernel. You'll already need some level of cooperation in userspace
unless you plan on implementing the PCI bus in kernel space too.
It's easy enough in the pci_map function in QEMU to just notify the
kernel that it should listen on a particular PIO range.
This is a config space write, right? If so, the range is the regular
0xcf8-0xcff and it has to be very specially handled.
This is a per-device IO slot and as best as I can tell, the PCI device
advertises the size of the region and the OS then identifies a range of
PIO space to use and tells the PCI device about it. So we would just
need to implement a generic userspace virtio PCI device in QEMU that did
an ioctl to the kernel when this happened to tell the kernel what region
to listen on for a particular device.
vmcalls will certainly get faster but I doubt that the cost
difference between vmcall and pio will ever be greater than a few
hundred cycles. The only performance sensitive operation here would
be the kick and I don't think a few hundred cycles in the kick path
is ever going to be that significant for overall performance.
Why do you think the different will be a few hundred cycles?
The only difference in hardware between a PIO exit and a vmcall is that
you don't have write out an exit reason in the VMC[SB]. So the
performance difference between PIO/vmcall shouldn't be that great (and
if it were, the difference would probably be obvious today). That's
different from, say, a PF exit because with a PF, you also have to
attempt to resolve it by walking the guest page table before determining
that you do in fact need to exit.
And if you have a large number of devices, searching the list
becomes expensive too.
The PIO address space is relatively small. You could do a radix tree or
even a direct array lookup if you are concerned about performance.
So why introduce the extra complexity?
Overall I think it reduces comlexity if we have in-kernel devices.
Anyway we can add additional signalling methods later.
In-kernel virtio backends add quite a lot of complexity. Just the
mechanism to setup the device is complicated enough. I suspect that
it'll be necessary down the road for performance but I certainly don't
think it's a simplification.
I believe that the network interface will quickly go to the kernel since
copy takes most of the
cpu time and qemu does not support scatter gather dma at the moment.
Nevertheless using pio seems good enough, Anthony's suggestion of
notifying the kernel using ioctls
is logical. If we'll run into troubles further on we can add a hypercall
capability and if exist use hypercalls
instead of pios.
Regards,
Anthony Liguori
-------------------------------------------------------------------------
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
-------------------------------------------------------------------------
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
