linux-kernel - Re: [patch 0/3] kvm tool: Serial emulation overhaul

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: <4EE729B3.9010809@redhat.com>
Date:	Tue, 13 Dec 2011 12:32:19 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Ingo Molnar <mingo@...e.hu>, Sasha Levin <levinsasha928@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Pekka Enberg <penberg@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [patch 0/3] kvm tool: Serial emulation overhaul

On 12/12/2011 11:36 PM, Alan Cox wrote:
> On Mon, 12 Dec 2011 20:16:50 +0200
> Avi Kivity <avi@...hat.com> wrote:
>
> > On 12/12/2011 01:20 PM, Alan Cox wrote:
> > > > [*] Also, those 10K cycles include some significant Qemu 
> > > >     overhead - a couple of thousand cycles - that should be much 
> > > >     lower in the tools/kvm case.
> > >
> > > Are all the traps going into qemu
> > 
> > Only the ones that go to devices modelled in userspace.
> > 
> > >  - is KVM still that braindead ?
> > 
> > How would you do it?
>
> See my posting from years back about this...

Must have missed it.

>
> Your trap handler returns the kernel a predictor tree (say a 1 page tree)
> of the next expected ins out and actions - where the action is either
> store, or trap out.
>
> Each kernel trap then boils down to
>
> Does this trap match an entry in the top of our predictor tree. Ie is it
> an in/out (or equivalent mmio) that the driver has given us expected
> behaviour for.
>
> We could of course have several for different ranges of devices
>
> 	no - hit emulator and return position in predictor tree we failed
> 		at plus tree buffer if needed
>
> 	yes - follow the tree node
>
> 	For IN
> 		copy predicted byte/word/dword to tree buffer
> 		move along tree
> 		return
>
> 	For Out
> 		store store byte/word/dword in tree buffer
> 		(one of which can be used for discard)
> 		move along the tree
> 		return
>
> Thats enough to do things like write predictors for the kernel console
> emulating the serial fifo, to script PIO IDE transfers etc
>
> The kernel side is miniscule and generic, the user space can migrate to
> doing this where it pays off and not where it doesn't.

Looks incredibly fragile.  As soon as the guest changes its behaviour a
tiny bit, this breaks.  It doesn't work for any device that has even a
bit of indirection (like IDE DMA), or needs timers, or is misdesigned in
any of the hundreds of ways hardware designers have discovered over the
years.  And in the end, performance is still low compared to a
paravirtual device that was designed for minimizing exits - an exit that
is terminated in the kernel is cheaper than userspace, but still very
expensive.

-- 
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/