linux-kernel - Re: [ANNOUNCE] Native Linux KVM tool

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20110408192039.GJ29444@random.random>
Date:	Fri, 8 Apr 2011 21:20:39 +0200
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	Anthony Liguori <anthony@...emonkey.ws>
Cc:	Pekka Enberg <penberg@...nel.org>, Ingo Molnar <mingo@...e.hu>,
	Avi Kivity <avi@...hat.com>, linux-kernel@...r.kernel.org,
	mtosatti@...hat.com, kvm@...r.kernel.org, joro@...tes.org,
	penberg@...helsinki.fi, asias.hejun@...il.com, gorcunov@...il.com
Subject: Re: [ANNOUNCE] Native Linux KVM tool

Hi Anthony,

On Fri, Apr 08, 2011 at 09:00:43AM -0500, Anthony Liguori wrote:
> An example is ioport_ops.  This maps directly to 
> ioport_{read,write}_table in QEMU.  Then you use ioport__register() to 
> register entries in this table similar register_ioport_{read,write}() in 
> QEMU.
> 
> The use of a struct is a small improvement but the fundamental design is 
> flawed because it models a view of hardware where all devices are 
> directly connected to the CPU.  This is not how hardware works at all.

Not sure if I've the whole picture on this but I see no answer to your
email and I found your remark above the most interesting. This is
because I thought the whole point of a native kvm tool was to go all
the paravirt way to provide max performance and maybe also depend on
vhost as much as possible.

I mean if we have to care to emulate hardware _again_ and end up
replicating qemu (with the only exception of TCG) I don't see an need
of an alternative userland, let's not understimate how qemu is already
mature and good to emulate real hardware. I thought the whole point
was to exactly avoid any complaint like "this is not how the hardware
works" and focus only to optimize for smp and max scalability and
ignore how a real hardware would actually work to get there faster
than qemu can.

I had no time to read/try it yet I'm just reading the thread here...

Thanks,
Andrea
--
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/