On Sun, Feb 27, 2011 at 06:04:16PM +0200, Avi Kivity wrote: > On 02/27/2011 05:58 PM, Avi Kivity wrote: > > > >>The problem with using top of slot > >>zero is that this memory is available for guest use and we do not even > >>put it into e820 map as far as I see. Also there are patches floating > >>around that re-arrange memslots or even put them in a tree. They will > >>break old guests too. > > > >Well, slot 0 still exists even if it is moved somewhere else. > > > >Something we can do is put the tss slot just below the highest > >slot that is still below 4G, and hope there is no mmio there. > >Once the user issues KVM_SET_TSS_ADDR, use that. We'll have to > >keep juggling that slot as the user creates more slots, icky. > > > > Or we can keep the old behaviour. If KVM_SET_TSS_ADDR hasn't been > called by the time of the first entry into real mode (the first > KVM_CREATE_VCPU?), use the top of the first slot. > Do we require that KVM_SET_TSS_ADDR is called before first KVM_CREATE_VCPU? We may still break some theoretical userspaces this way. > We can avoid the SMP problem by initializing the memory in a single > pass, writing each byte exactly once with its final value. This way > concurrent initialization doesn't corrupt an in-use TSS. > Sounds hackish, but may work. Doing so will make entering pmode much more slow. -- 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
