Re: [PATCH] Add I/O hypercalls for i386 paravirt



Zachary Amsden wrote:
Avi Kivity wrote:
Zachary Amsden wrote:
In general, I/O in a virtual guest is subject to performance
problems. The I/O can not be completed physically, but must be
virtualized. This means trapping and decoding port I/O instructions
from the guest OS. Not only is the trap for a #GP heavyweight, both
in the processor and the hypervisor (which usually has a complex #GP
path), but this forces the hypervisor to decode the individual
instruction which has faulted. Worse, even with hardware assist such
as VT, the exit reason alone is not sufficient to determine the true
nature of the faulting instruction, requiring a complex and costly
instruction decode and simulation.

This patch provides hypercalls for the i386 port I/O instructions,
which vastly helps guests which use native-style drivers. For certain
VMI workloads, this provides a performance boost of up to 30%. We
expect KVM and lguest to be able to achieve similar gains on I/O
intensive workloads.



Won't these workloads be better off using paravirtualized drivers? i.e., do the native drivers with paravirt I/O instructions get anywhere
near the performance of paravirt drivers?

Yes, in general, this is true (better off with paravirt drivers). However, we have "paravirt" drivers which run in both fully-paravirtualized and fully traditionally virtualized environments. As a result, they use native port I/O operations to interact with virtual hardware.

Suffering from terminology overdose here: "fully traditionally virtualized, fully-paravirtuallized, para-fullyvirtualized".

Since this is only for newer kernels, won't updating the driver to use a hypercall be more efficient? Or is this for existing out-of-tree drivers?


Since not all hypervisors have paravirtualized driver infrastructures and guest O/S support yet, these hypercalls can be advantages to a wide range of scenarios. Using I/O hypercalls as such gives exactly the same performance as paravirt drivers for us, by eliminating the costly decode path, and the simplicity of using the same driver code makes this a huge win in code complexity.

Ah, seems the answer to the last question is yes.


--
error compiling committee.c: too many arguments to function

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • Re: [PATCH] Add I/O hypercalls for i386 paravirt
    ... This means trapping and decoding port I/O instructions ... This patch provides hypercalls for the i386 port I/O instructions, ... Yes, in general, this is true (better off with paravirt drivers). ... Since not all hypervisors have paravirtualized driver infrastructures and guest O/S support yet, these hypercalls can be advantages to a wide range of scenarios. ...
    (Linux-Kernel)
  • [7/15] orinoco merge preliminaries - comment/whitespace/spelling updates
    ... * try newer firmware in the card. ... and one that's 0x40 long mapped to the PCMCIA slot I/O ... read the COR register back and make sure ... except for crashing drivers not written to expect it. ...
    (Linux-Kernel)
  • Oops 2.6.23.1 in ext3+jbd at journal_put_journal_head
    ... A one-time event thus far, happened under very heavy I/O, ... : BUG: unable to handle kernel paging request at virtual address 430a7261 ... # Firmware Drivers ... # PCCARD support ...
    (Linux-Kernel)
  • Re: Code density and performance?
    ... Maybe I write OS code and IO drivers for an Alpha based O/S? ... the I/O buffer is provided by an entity that you do not control. ... However, C and Unix support were a sine qua non for the Alpha, ... POSIX asynchronous I/O semantics. ...
    (comp.arch)
  • [PATCH/RFC] I/O-check interface for drivers error handling
    ... I/O error is not a leading cause of system failure. ... So I'd like to suggest new interfaces that enable drivers to ... Additionally adds special token - abstract "iocookie" structure ...
    (Linux-Kernel)