I''ve been getting a "Failed VMEntry" when trying to boot a second VMX guest (while the first one is still running, but is no longer in real mode). This patch fixes it. VMX(assist) uses vm86 in its real mode emulation. Upon vmentry into a guest in vm86 mode, all segment bases must be equal to the corresponding segment selector shifted left four bits. The vmx routine vmx_load_cpu_guest_regs() was loading the segment selectors. Now it makes sure to set the segment bases appropriately if we''re in vm86 mode. Tested on 64bit hypervisor with 2 64-bit VMX domUs (on 2-way dom0). Dave _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Petersson, Mats
2006-May-02 15:30 UTC
RE: [Xen-devel] [PATCH] fix for Failed VMEntry on VMX
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > David Lively > Sent: 02 May 2006 15:58 > To: xen-devel@lists.xensource.com > Subject: [Xen-devel] [PATCH] fix for Failed VMEntry on VMX > > I''ve been getting a "Failed VMEntry" when trying to boot a > second VMX guest (while the first one is still running, but > is no longer in real mode). This patch fixes it. > > VMX(assist) uses vm86 in its real mode emulation. Upon > vmentry into a guest in vm86 mode, all segment bases must be > equal to the corresponding segment selector shifted left four > bits. The vmx routine vmx_load_cpu_guest_regs() was loading > the segment selectors. Now it makes sure to set the segment > bases appropriately if we''re in vm86 mode. > > Tested on 64bit hypervisor with 2 64-bit VMX domUs (on 2-way dom0).Will this not break "big real-mode" type behaviour? Or am I missing something here? Certainly the x86 architecture itself allows the segment (in real mode) to have a different base address than the "selector << 4" that you get when you LOAD a selector in REAL MODE. It''s just that in real-mode, you can''t set a different base, but code that has temporarily run in non-real mode (i.e. enter protected mode then set segment register than exit back to real-mode) can do all sorts of magic. If this is really expected behaviour, it would also be expected to have a limit of 0xffff, or you''re sort of half-breaking the rules still... -- Mats> > Dave >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I don''t think so. If a CPU in real mode is allowed to use a segment base set in another mode (to something other than sel << 4), I think that''s outside the scope of what vmxassist was designed to do. (Because vmxassist relies on vm86 mode, and the VMX spec says vm86 mode guests must have their segment bases = sel << 4 upon vmentry ... and the chips certainly behave as specified in this regard.) I don''t really understand the implications of not supporting arbitrary segment bases in real mode guests (what code actually does this?), but since it can''t work in the current implementation, this patch must not be breaking it ... Dave Will this not break "big real-mode" type behaviour? Or am I missing> something here? Certainly the x86 architecture itself allows the segment > (in real mode) to have a different base address than the "selector << 4" > that you get when you LOAD a selector in REAL MODE. It''s just that in > real-mode, you can''t set a different base, but code that has temporarily > run in non-real mode (i.e. enter protected mode then set segment > register than exit back to real-mode) can do all sorts of magic. If this > is really expected behaviour, it would also be expected to have a limit > of 0xffff, or you''re sort of half-breaking the rules still... > > -- > Mats >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 2 May 2006, at 15:58, David Lively wrote:> I''ve been getting a "Failed VMEntry" when trying to boot a second > VMX guest (while the first one is still running, but is no longer in > real mode). This patch fixes it.Please `or'' the vmread/vmwrite error returns together into an error variable and BUG_ON(error) just once at the bottom of the function. Also extend the comment a little to explicitly explain that this is working around a VMENTRY validation check. Apart from that it looks good. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Petersson, Mats
2006-May-02 16:34 UTC
RE: [Xen-devel] [PATCH] fix for Failed VMEntry on VMX
Leendert was fixing problems caused by this a while back. The essence is that you have some code that want''s to generally access real-mode BIOS functions, but also access "high memory", typically when booting [loading the image from disk - once the image is in memory we can switch to protected mode once and for all] (this is ONE example, there''s other things you can do that needs this functionality). There''s two solutions to my example: 1. Switch between real-mode and protected mode many times - this is not just performance-wise a bad idea, but it also makes the code have lots of stuff in it that causes problems - for example, do you allow interrupts only when in protected mode, only in real-mode, or do you have TWO sets of interrupt handling and switch that too? [If you rely on the BIOS, you probably need to use REAL MODE for interrupt handling]. 2. Do a short visit into protected mode and set some segment register to base = 0, limit = 4G and use that for the duration of this processing. Typically, this is the GS or FS segment, since that segment isn''t being used by the BIOS or commonly used in real-mode code. Then you can use a GS prefix together with a 32-bit address override [i.e. mov %eax, gs:(%ebx) - or whatever the syntax is in gas]. If you tried this in a "traditional" real-mode register, it would GP-fault if the ebx register is bigger than 64K, and combined with the maximum segment base being 0xFFFF, you can only access (1M + 64K - 16) bytes of memory, which may not be good enough to for example load the OS into memory. I know that SLES 9 uses this mode of operation for graphical boot mode - it loads the graphics image from the disk onto the VGA card using "big real mode". What I''m not sure about is whether this gets run only once during boot (in which case it''s fine) or every time you switch to/from the domain (in which case it isn''t fine). -- Mats ________________________________ From: Dave Lively [mailto:dave.lively@gmail.com] Sent: 02 May 2006 17:05 To: Petersson, Mats Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] fix for Failed VMEntry on VMX I don''t think so. If a CPU in real mode is allowed to use a segment base set in another mode (to something other than sel << 4), I think that''s outside the scope of what vmxassist was designed to do. (Because vmxassist relies on vm86 mode, and the VMX spec says vm86 mode guests must have their segment bases = sel << 4 upon vmentry ... and the chips certainly behave as specified in this regard.) I don''t really understand the implications of not supporting arbitrary segment bases in real mode guests (what code actually does this?), but since it can''t work in the current implementation, this patch must not be breaking it ... Dave Will this not break "big real-mode" type behaviour? Or am I missing something here? Certainly the x86 architecture itself allows the segment (in real mode) to have a different base address than the "selector << 4" that you get when you LOAD a selector in REAL MODE. It''s just that in real-mode, you can''t set a different base, but code that has temporarily run in non-real mode (i.e. enter protected mode then set segment register than exit back to real-mode) can do all sorts of magic. If this is really expected behaviour, it would also be expected to have a limit of 0xffff, or you''re sort of half-breaking the rules still... -- Mats _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Okay - revised patch attached. Thanks, Dave Keir Fraser wrote:> > On 2 May 2006, at 15:58, David Lively wrote: > >> I''ve been getting a "Failed VMEntry" when trying to boot a second >> VMX guest (while the first one is still running, but is no longer in >> real mode). This patch fixes it. > > > Please `or'' the vmread/vmwrite error returns together into an error > variable and BUG_ON(error) just once at the bottom of the function. > Also extend the comment a little to explicitly explain that this is > working around a VMENTRY validation check. > > Apart from that it looks good. > > -- Keir >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel