On Sun, Feb 27, 2011 at 06:31:13PM +0200, Avi Kivity wrote:
> On 02/27/2011 06:27 PM, Gleb Natapov wrote:
> >>
> >> 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.
>
> The documentation doesn't say, but I think it's unlikely that
> userspace will start a guest and then configure it.
>
KVM_CREATE_VCPU is done before guest is started. Starting of a guest
happens when KVM_RUN is done for the first time.
> >
> >> 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.
>
> Why? do it at most once per vcpu.
>
The reboot may fail since guest may have used the memory while running,
so memory should be reinited on reboot, but since KVM doesn't always
know about reboot it should be done at each protected mode entry.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
