![]() | |||||||||||
Messages in this thread |
Avi Kivity wrote: > Anthony Liguori wrote: >>> >>> We started using VT only for 64 bit, then added 32 bit, then 16-bit >>> protected, then vm86 and real mode. We'd transfer the x86 state on >>> each mode change, but it was (a) fragile (b) considered unclean. >>> >>> You're right that "big real" mode is not supported, but so far that >>> hasn't been a problem. Do you know of an OS that needs big real mode? >> >> AFAIK the SLES boot splash patches to grub use it. It's definitely a >> requirement. Currently, there is an effort in Xen to use QEMU for >> partial emulation. Hopefully, it will be there for the next release. >> > > Ouch. Boot splash patches. > > Well, we had real mode in qemu once, we can put it there again. > >> Allowing QEMU to do emulation also will help with IO performance. >> Instead of having to take many trips to userspace for MMIO >> especially, you can allow QEMU to execute a certain number of basic >> blocks and then return. Minimizing trips between userspace and the >> kernel is going to be critical performance wise. >> > > My plan was to allow userspace to register certain mmio addresses for > cacheing, so that if the guest code had a code sequence like > > writel(dst_x_reg, x); > writel(dst_y_reg, y) > writel(width_reg, w); > writel(height_reg, h); > writel(blt_cmd_reg, fill); > > then kvm would cache the first four in a mmap()able memory area and > only exit to userspace on the fifth. Userspace would then read the > cached registers from memory and emulate the command. Letting QEMU do a certain amount of emulation after every transition would the problem in a more elegant and generic way. > This saves userspace transitions but not guest/host switches. I'm > counting on Intel and AMD to reduce the cost of these, but it will > probably never be cheap. > > Paravirtualized drivers are also an option; we may try to keep > compatibility with Xen's. Please no! With proper device emulation, paravirtualized drivers shouldn't be necessary. > >> >> I've been tossing around the idea of doing partial IO emulation in >> the kernel. If you could sync the device states between userspace >> and kernel, it should be possible. Given that the you're already in >> the kernel at VMEXIT time, if you could feed something right to the >> block driver or network driver, you ought to be able to get pretty >> darn good performance. >> > > Do you mean putting the device model into the kernel? Perhaps part of it. Still an idea at this point. Regards, Anthony Liguori - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2006-10-19 21:35 [from the cache] ©2003-2008 | |||||||||||