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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070824122025.GA3886@ucw.cz>
Date:	Fri, 24 Aug 2007 12:20:25 +0000
From:	Pavel Machek <pavel@....cz>
To:	Zachary Amsden <zach@...are.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Andrew Morton <akpm@...l.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Virtualization Mailing List <virtualization@...ts.osdl.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Chris Wright <chrisw@...s-sol.org>,
	Avi Kivity <avi@...ranet.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: [PATCH] Add I/O hypercalls for i386 paravirt

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