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]
Date:	Mon, 12 Dec 2011 21:36:52 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Avi Kivity <avi@...hat.com>
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 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...

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.


Alan
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ