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 -- 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
