[Xen-devel] [PATCH] [HVM] Patches to make HVM capable of running OS/2.

["Trolle Selander" <trolle.selander@xxxxxxxxx>]

This is a set of patches that makes it possible to run OS/2 in a fully virtualized guest. Because of the limited real-mode support on Intel VT, this will currently only work on AMD-V  CPUs.
One of the patches (the smsw instruction emulation) is very "stop-gap" and ugly as sin, but arguably even that is better than the current case which blissfully does the wrong thing and then resumes execution from the wrong EIP. :) The "right thing" is probably to add the lmsw/smsw instructions to x86_emulate, and use that instead, unless something about how the control register intercepts & emulation makes x86_emulate the wrong tool for the job. Suggestions welcome, because I do want to make a proper general-case fix for this, rather than the ugly special-case kludge provided here.

Patch descriptions:

Patch 1:
vpic-prio-fix.patch

This is plain bugfix - IRQ priority calculation is currently broken in the virtual vpic. The priority shift should be a right-rotation, not a left-rotation.

Patch 2:
mmio_ops.patch

Just two additional mmio ops that OS/2 needs emulated.

Patch 3:
qemu-dm_xchg.patch

Adds support for IOREQ_TYPE_XCHG in qemu-dm. 

Patch 4:
ropmbios-e801-fix.patch


This is a "minimally intrusive" way to fix an issue that I think should really be fixed in a different way.
Currently, the shared info, ioreq and buffered_io pages are mapped into the guest's memory space as the three highest page frames. They are "protected" from use by being marked as reserved in the e820 ram map. However, legacy software won't know about the e820 call, and since the older e801 call reports all ram, including the shared pages, the guest OS will end up using them as regular ram with disastrous results.
This patch makes the older e801 bios call report one 64kb block less memory, thus "protecting" the shared pages from older OS's in a similar manner to the e820 call, at the expense of 52kb of wasted ram (the e801 call reports memory in 64kb blocks, so no way around this).

However, while I think shared_info might be needed by PV-on-HVM drivers, I don't see why the ioreq and buffered_iopage pages should be guest-accessible at all. Rather they should be shared only between HV and Dom0, since their use is strictly for the qemu-dm device model, which should happen entirely "out of sight" of a fully virtualized guest.

Patch 5:

svm_smsw_modrm.patch

This is the abovementioned ugly patch.
The current SVM emulation of the smsw instruction makes the assumption that the destination for the msw is always a register. While i think this is true for the newer MOV from CRx, the legacy smsw can also copy to mem. Since I've only encountered one specific usage of msw->mem this, which is msw->segment base + offset, I've put in handling only of this special case. Consider this one very temporary.

Attachment: pic-prio-fix.patch
Description: Text Data

Attachment: mmio_ops.patch
Description: Text Data

Attachment: qemu-dm_xchg.patch
Description: Text Data

Attachment: rombios_e801_fix.patch
Description: Text Data

Attachment: svm_smsw_modrm.patch
Description: Text Data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel