On Mon, Aug 02, 2010 at 11:54:58AM +0300, Avi Kivity wrote: > On 08/02/2010 11:34 AM, Gleb Natapov wrote: > >On Mon, Aug 02, 2010 at 11:24:14AM +0300, Avi Kivity wrote: > >> On 08/02/2010 11:17 AM, Gleb Natapov wrote: > >>>>We don't know what they'll do. API stability means we only change > >>>>things to fix bugs. > >>>Is this API documented? Do we guaranty somewhere anywhere that rip during io > >>>point past the instruction? I think it should be documented that cpu > >>>state cannot be accessed during io emulation. > >>The user code was written before the documentation. > >> > >We did it with unmapped pages in the middles of the slot recently. > > What guests did we break? > The one that uses device assignment with old qemu-kvm userspace. Old qemu-kvm copied assigned card's ROM into memory and made it read only (mprotect(RO)) to get MMIO exists on it. Even older device assignment code unmapped one page in the middle of a slot to get mmio exist if the page is accessed (and this breaks if mmap decides to mmap something else there). > >>IIRC it leaves fs and gs pointing to large segments, but it never > >>accesses them. Since we can't tell whether the guest will use those > >>segments, we can't avoid emulating big real mode. Right now most > >>things work, but that's because we hacked around everything. > >> > >We have logic in TPR patching code that tries to detect WindowsXP guest > >and if XP is detected it enables vapic. We can disable e_i_g_s if vapic > >is enabled. > > That code is in userspace. If we can change userspace, the whole > problem is gone. Userspace calls kvm_enable_vapic() to let kernel know that vapic is enabled. -- Gleb. -- 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
