[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: Xen 3.2 and Big Real Mode support?

On 6/2/08 08:20, "Guillaume Thouvenin" <guillaume.thouvenin@xxxxxxxxxxxx>

>> By the way, this is now fixed with tip of the xen-unstable tree (changeset
>> 16980), obtainable from http://xenbits.xensource.com/staging/xen-unstable.hg
> Waow. I don't understand everything (and especially how you find that
> the problem was here) but it works now.
>  I have another question, why did you remove VMXASSIST? I saw that you
> replaced all invocation to VMXASSIST by only one call to
> vmx_goto_realmode() in arch/x86/hvm/svm/x86_64/exits.S. Are there some
> links to any discussion about this choice?

The new emulation replaces vmxassist. There are fundamental limitations to
teh vmxassist approach which mean that it could never execute, for example,
the openSuSE install CDs because of their use of 'big real' mode. This is
talked about in a few threads on xen-devel, e.g.:
It's bit hard to understand without more context though!

Roughly speaking the main pro for emulation is more accurate execution
leading to working with a wider range of bootloaders. It's also less code,
and I understand the code (since I wrote it) so I can maintain it better in
future. The main con is that it may be a bit slower than vmxassist, since
vmxassist did direct execution of most real-mode instructions rather than
emulating all of them. But actually most time is spent emulating I/O in both
cases, so I think the speed difference is not that important.

Now that emulation seems to work reliably in xen-unstable (apart from
openSuSE 10.1 CD, argh!) I will remove vmxassist entirely. Also I will
backport the emulation fixes to 3.2-testing so that real-mode emulation will
work properly in 3.2.1. I will keep VMXASSIST as the default in 3.2 branch

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.