On 04/08/2011 02:20 PM, Andrea Arcangeli wrote:
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.
Yeah, if that's the goal, skip all the mini-BIOS junk and just rely on a PV kernel in the guest.
I think a mini userspace that assumes that we can change the guest kernel and avoids having a ton of complexity to do things like CMOS emulation would be a really interesting thing to do.
Regards, Anthony Liguori -- 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
