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

Pavel Machek
2007-08-24T12:20:50Z

Hi!

> >>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.
> >>
> >>
> >
> >What about cost on hardware?
> >
>
> On modern hardware, port I/O is about the most expensive
> thing you can do. The extra function call cost is
> totally masked by the stall. We have measured with port
> I/O converted like this on real hardware, and have seen
> zero measurable impact on macro-benchmarks.
> Micro-benchmarks that generate massively repeated port
> I/O might show some effect on ancient hardware, but I
> can't even imagine a workload which does such a thing,
> other than a polling port I/O loop perhaps - which would
> not be performance critical in any case I can reasonably
> imagine.

SCSI controller in ISA slot? IDE without DMA enabled?

Yes, those are performance-critical. The second case seems common with
compactflash cards.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html