Re: [PATCH 2/2] KVM: VMX: Initialize vm86 TSS only once.

[Avi Kivity <avi@redhat.com>]

On 02/27/2011 06:12 PM, Gleb Natapov wrote:
> On Sun, Feb 27, 2011 at 05:58:54PM +0200, Avi Kivity wrote:
> >  On 02/27/2011 05:52 PM, Gleb Natapov wrote:
> >  >>
> >  >>   According to my reading of the code, if KVM_SET_TSS_ADDR is not
> >  >>   invoked, the guest would fail both before and after the patch, yes?
> >  >>
> >  >Hmmm. Actually no. Before the patch guest that doesn't use KVM_SET_TSS_ADDR
> >  >will use the top of slot zero. Should I fix that (how?), or should we
> >  >drop support for those old guests?
> >
> >  I don't think we have a problem with older qemus, but perhaps we do
> >  with non-qemu users.  The API clearly requires the ioctl to be
> >  called, but I don't think we can blame anyone for forgetting to do
> >  so, especially if it worked silently.
> >
> It may have worked as in "no error returned from KVM_RUN", but if
> userspace does not call to KVM_SET_TSS_ADDR kvm silently uses part of
> a guest memory to store its data which may cause guest to fail long after
> it was started. It is true that for that to happen guest needs to enter
> protected mode during its lifetime and not many guests do that usually.
> The only cases I can think of are during some guests installation and
> S3 suspend/resume.

Right.  I prefer to keep this partially working state if users didn't 
have a problem with it.

> >  >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.
> >
> I have a question about our current placement of tss addr. Qemu-kvm
> places it at 4G-16M and comment says that this is just below BIOS ROM,
> but BIOS ROM takes only upper 128K.

Are you surprised that a comment is inaccurate?

Likely it was moved to make room for larger bioses.

-- 
error compiling committee.c: too many arguments to function