Re: [RFC PATCH v3 0/3] Add segment limit checks to emulator

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

 



On 07/12/2010 03:36 PM, Mohammed Gamal wrote:
On Mon, Jul 12, 2010 at 9:26 AM, Avi Kivity<avi@xxxxxxxxxx>  wrote:
On 07/12/2010 01:56 AM, Mohammed Gamal wrote:
fter some conversation with Avi concerning why unreal mode has been seen
to work
with KVM on Intel. It clears out the scenario is caused as follows:

- guest enters big real mode
- kvm squashes limit to 64k-1
- guest executes instructions with offset>    64k
- cpu issues #GP due to limit violation
- kvm handle_rmode_exception() ->    emulator
- emulator ignores limit, emulates instruction

With these applied I am getting vmentry failures with SeaBIOS and
gPXE. I could still get SeaBIOS to work with
emulate_invalid_guest_state=1.
So it's needless to say that these patches are not meant for merging!

Well, eventually you need to fix this.
What happens is that guests are switched to big real mode so either
gPXE and SeaBIOS need to be modified to work with the way KVM handles
segment limits when switching to real mode, but that'd be only a
temporary solution. The other - and better IMO - option is to get
e_i_g_s=1 completely functional, which is something we want to do
anyway. So we can address all the comments you have on these patches
and eventually merge them along with the rest of e_i_g_s patches.

Does SeaBIOS use big real mode now?

I think this can work even with e_i_g_s=0. Simply return vmx->rmode.seg.limit instead of GUEST_seg_LIMIT. In fact we need to do this anyway, so live migration migrates the correct limit, not the hack that we do for vmx.

--------

Changes from v2:
- Addeded generic segment limit check helpers
- Removed individual segment register segment helpers as they're no longer
needed


What about the rest of my comments?
I did change the limit calculations to avoid overflows, and
re-arranged patches as per your suggestion. Sorry for not pointing
this out in the change log. Check the patches I sent out for details.

What about expand-down segments? and moving the limit check where the access is emulated (so we are sure we don't miss a check)?

--
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux