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 kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
