Re: [RFC PATCH v3 0/3] Add segment limit checks to emulator
On Mon, Jul 26, 2010 at 12:47 PM, Avi Kivity wrote: > On 07/25/2010 07:23 PM, Kevin O'Connor wrote: >> >> On Sun, Jul 25, 2010 at 11:54:20AM +0300, Avi Kivity wrote: >>> >>> On 07/24/2010 06:45 PM, Kevin O'Connor wrote: On Mon, Jul 12, 2010 at 04:13:06PM +0300, Avi Kivity wrote: > > Does SeaBIOS use big real mode now? SeaBIOS calls option roms in big real mode. This is required by the relevant specs. >>> >>> Can you provide a pointer? >> >> See the PMM spec section 2.2 and section 3.2.4. (Sadly, I can't find >> a link to the PMM spec on the web anymore - hopefully you have a >> copy.) Also see the PCI Firmware Specification v3.0 - section >> 5.2.1.9. > > Unfortunately, I don't have a copy. There were some links here but they don't work anymore. The file name is specspmm101.pdf: http://lists.xensource.com/archives/html/xen-changelog/2009-01/msg00153.html >> The specs don't require any code addresses to be>64K, but it does >> require data access over 64K. I doubt there are many systems that use >> a code address>64K, because an interrupt in big real mode still only >> stores a 16bit return address - thus an irq (or nmi) in that mode will >> basically cause a crash. > > Ok. Flat 4G segments happen to accidentally work in kvm-intel, and we can > keep it working. > > -- > 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 > -- 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
Re: [RFC PATCH v3 0/3] Add segment limit checks to emulator
On 07/25/2010 07:23 PM, Kevin O'Connor wrote: On Sun, Jul 25, 2010 at 11:54:20AM +0300, Avi Kivity wrote: On 07/24/2010 06:45 PM, Kevin O'Connor wrote: On Mon, Jul 12, 2010 at 04:13:06PM +0300, Avi Kivity wrote: Does SeaBIOS use big real mode now? SeaBIOS calls option roms in big real mode. This is required by the relevant specs. Can you provide a pointer? See the PMM spec section 2.2 and section 3.2.4. (Sadly, I can't find a link to the PMM spec on the web anymore - hopefully you have a copy.) Also see the PCI Firmware Specification v3.0 - section 5.2.1.9. Unfortunately, I don't have a copy. The specs don't require any code addresses to be>64K, but it does require data access over 64K. I doubt there are many systems that use a code address>64K, because an interrupt in big real mode still only stores a 16bit return address - thus an irq (or nmi) in that mode will basically cause a crash. Ok. Flat 4G segments happen to accidentally work in kvm-intel, and we can keep it working. -- 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
Re: [RFC PATCH v3 0/3] Add segment limit checks to emulator
On Sun, Jul 25, 2010 at 09:34:38PM +0300, Avi Kivity wrote: > On 07/25/2010 08:19 PM, Kevin O'Connor wrote: > >Only the ljmpw is in big real mode with a code address>64K - the > >"Disable protected mode" code is technically in 16bit protected mode. > >I'm not sure if that helps explain why it works. > > What happens is kvm enters real mode with cs.limit=0x, the > guest #GPs due to segment limit violation, and enters the emulator, > which emulates the far jump correctly. > > So this works, and will continue to work even after we fix limit > checking. It's still cleaner IMO to use normal code segments. Makes sense. I committed the patch that avoids this behavior to SeaBIOS git. -Kevin -- 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
Re: [RFC PATCH v3 0/3] Add segment limit checks to emulator
On 07/25/2010 08:19 PM, Kevin O'Connor wrote: On Sun, Jul 25, 2010 at 12:42:46PM -0400, Kevin O'Connor wrote: On Sun, Jul 25, 2010 at 11:55:47AM +0300, Avi Kivity wrote: What conditions are needed to trigger this path? This can't occur under normal operation, since it will fail badly with kvm on Intel. It's called on every boot. I've personally only tested kvm on amd, but I'd have to assume something must be allowing this to work on intel. BTW, the transition16big code does: ljmpl $SEG32_MODE16BIG_CS, $(0xf + 1f) .code16gcc 1: // Disable protected mode movl %cr0, %eax andl $~CR0_PE, %eax movl %eax, %cr0 // far jump to flush CPU queue after transition to real mode ljmpw $0xf000, $2f 2: Only the ljmpw is in big real mode with a code address>64K - the "Disable protected mode" code is technically in 16bit protected mode. I'm not sure if that helps explain why it works. What happens is kvm enters real mode with cs.limit=0x, the guest #GPs due to segment limit violation, and enters the emulator, which emulates the far jump correctly. So this works, and will continue to work even after we fix limit checking. It's still cleaner IMO to use normal code segments. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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
Re: [RFC PATCH v3 0/3] Add segment limit checks to emulator
On Sun, Jul 25, 2010 at 12:42:46PM -0400, Kevin O'Connor wrote: > On Sun, Jul 25, 2010 at 11:55:47AM +0300, Avi Kivity wrote: > > What conditions are needed to trigger this path? This can't occur > > under normal operation, since it will fail badly with kvm on Intel. > > It's called on every boot. I've personally only tested kvm on amd, > but I'd have to assume something must be allowing this to work on > intel. BTW, the transition16big code does: ljmpl $SEG32_MODE16BIG_CS, $(0xf + 1f) .code16gcc 1: // Disable protected mode movl %cr0, %eax andl $~CR0_PE, %eax movl %eax, %cr0 // far jump to flush CPU queue after transition to real mode ljmpw $0xf000, $2f 2: Only the ljmpw is in big real mode with a code address >64K - the "Disable protected mode" code is technically in 16bit protected mode. I'm not sure if that helps explain why it works. -Kevin -- 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
Re: [RFC PATCH v3 0/3] Add segment limit checks to emulator
On Sun, Jul 25, 2010 at 11:55:47AM +0300, Avi Kivity wrote: > On 07/24/2010 07:16 PM, Kevin O'Connor wrote: > >On Sat, Jul 24, 2010 at 11:45:22AM -0400, Kevin O'Connor wrote: > >>On Mon, Jul 12, 2010 at 04:13:06PM +0300, Avi Kivity wrote: > >>>Does SeaBIOS use big real mode now? > >>SeaBIOS calls option roms in big real mode. This is required by the > >>relevant specs. > >> > >>See the transition16big function in src/romlayout.S. It briefly jumps > >>to an address at 0xffxxx during the transition to real-mode. At a > >>quick glance, it looks like it could probably be changed to not use a > >>code address>64K. > >I put together a SeaBIOS patch so it does not use code addresses>64K > >in big real mode - in case anyone wants to test it. Note, this only > >reduces the use of code addresses>64K - SeaBIOS will still try to use > >data addresses>64K (eg, in option rom PMM code). > > > > What conditions are needed to trigger this path? This can't occur > under normal operation, since it will fail badly with kvm on Intel. It's called on every boot. I've personally only tested kvm on amd, but I'd have to assume something must be allowing this to work on intel. On option rom execution (eg, video rom), there is a call to optionrom.c:__callrom() which calls util.c:call16big() which calls romlayout.S:__transition16big. This has been in place since SeaBIOS-0.4.0 - well before the integration with kvm. Is the kvm restriction just on the code address, or is it also for data accesses? -Kevin -- 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
Re: [RFC PATCH v3 0/3] Add segment limit checks to emulator
On Sun, Jul 25, 2010 at 11:54:20AM +0300, Avi Kivity wrote: > On 07/24/2010 06:45 PM, Kevin O'Connor wrote: > >On Mon, Jul 12, 2010 at 04:13:06PM +0300, Avi Kivity wrote: > >>Does SeaBIOS use big real mode now? > >SeaBIOS calls option roms in big real mode. This is required by the > >relevant specs. > > Can you provide a pointer? See the PMM spec section 2.2 and section 3.2.4. (Sadly, I can't find a link to the PMM spec on the web anymore - hopefully you have a copy.) Also see the PCI Firmware Specification v3.0 - section 5.2.1.9. The specs don't require any code addresses to be >64K, but it does require data access over 64K. I doubt there are many systems that use a code address >64K, because an interrupt in big real mode still only stores a 16bit return address - thus an irq (or nmi) in that mode will basically cause a crash. -Kevin -- 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
Re: [RFC PATCH v3 0/3] Add segment limit checks to emulator
On 07/24/2010 07:16 PM, Kevin O'Connor wrote:
On Sat, Jul 24, 2010 at 11:45:22AM -0400, Kevin O'Connor wrote:
On Mon, Jul 12, 2010 at 04:13:06PM +0300, Avi Kivity wrote:
Does SeaBIOS use big real mode now?
SeaBIOS calls option roms in big real mode. This is required by the
relevant specs.
See the transition16big function in src/romlayout.S. It briefly jumps
to an address at 0xffxxx during the transition to real-mode. At a
quick glance, it looks like it could probably be changed to not use a
code address>64K.
I put together a SeaBIOS patch so it does not use code addresses>64K
in big real mode - in case anyone wants to test it. Note, this only
reduces the use of code addresses>64K - SeaBIOS will still try to use
data addresses>64K (eg, in option rom PMM code).
What conditions are needed to trigger this path? This can't occur under
normal operation, since it will fail badly with kvm on Intel.
-Kevin
diff --git a/src/misc.c b/src/misc.c
index 354df87..108c332 100644
--- a/src/misc.c
+++ b/src/misc.c
@@ -156,8 +156,8 @@ u64 rombios32_gdt[] VAR16VISIBLE __aligned(8) = {
GDT_LIMIT(BUILD_BIOS_SIZE-1) | GDT_CODE | GDT_BASE(BUILD_BIOS_ADDR),
// 16 bit data segment base=0x0 limit=0x (SEG32_MODE16_DS)
GDT_LIMIT(0x0) | GDT_DATA,
-// 16 bit code segment base=0 limit=0x (SEG32_MODE16BIG_CS)
-GDT_LIMIT(0xf) | GDT_CODE | GDT_G,
+// 16 bit code segment base=0xf limit=0x (SEG32_MODE16BIG_CS)
+GDT_LIMIT(0xf) | GDT_CODE | GDT_G | GDT_BASE(BUILD_BIOS_ADDR),
// 16 bit data segment base=0 limit=0x (SEG32_MODE16BIG_DS)
GDT_LIMIT(0xf) | GDT_DATA | GDT_G,
};
diff --git a/src/romlayout.S b/src/romlayout.S
index 54e5a4d..a469596 100644
--- a/src/romlayout.S
+++ b/src/romlayout.S
@@ -105,7 +105,7 @@ transition16big:
movw %ax, %fs
movw %ax, %gs
-ljmpl $SEG32_MODE16BIG_CS, $(BUILD_BIOS_ADDR + 1f)
+ljmpw $SEG32_MODE16BIG_CS, $1f
.code16gcc
1:
--
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
--
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
Re: [RFC PATCH v3 0/3] Add segment limit checks to emulator
On 07/24/2010 06:45 PM, Kevin O'Connor wrote: On Mon, Jul 12, 2010 at 04:13:06PM +0300, Avi Kivity wrote: Does SeaBIOS use big real mode now? SeaBIOS calls option roms in big real mode. This is required by the relevant specs. Can you provide a pointer? See the transition16big function in src/romlayout.S. It briefly jumps to an address at 0xffxxx during the transition to real-mode. At a quick glance, it looks like it could probably be changed to not use a code address>64K. Yes please. -- 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
Re: [RFC PATCH v3 0/3] Add segment limit checks to emulator
On Sat, Jul 24, 2010 at 11:45:22AM -0400, Kevin O'Connor wrote:
> On Mon, Jul 12, 2010 at 04:13:06PM +0300, Avi Kivity wrote:
> > Does SeaBIOS use big real mode now?
>
> SeaBIOS calls option roms in big real mode. This is required by the
> relevant specs.
>
> See the transition16big function in src/romlayout.S. It briefly jumps
> to an address at 0xffxxx during the transition to real-mode. At a
> quick glance, it looks like it could probably be changed to not use a
> code address >64K.
I put together a SeaBIOS patch so it does not use code addresses >64K
in big real mode - in case anyone wants to test it. Note, this only
reduces the use of code addresses >64K - SeaBIOS will still try to use
data addresses >64K (eg, in option rom PMM code).
-Kevin
diff --git a/src/misc.c b/src/misc.c
index 354df87..108c332 100644
--- a/src/misc.c
+++ b/src/misc.c
@@ -156,8 +156,8 @@ u64 rombios32_gdt[] VAR16VISIBLE __aligned(8) = {
GDT_LIMIT(BUILD_BIOS_SIZE-1) | GDT_CODE | GDT_BASE(BUILD_BIOS_ADDR),
// 16 bit data segment base=0x0 limit=0x (SEG32_MODE16_DS)
GDT_LIMIT(0x0) | GDT_DATA,
-// 16 bit code segment base=0 limit=0x (SEG32_MODE16BIG_CS)
-GDT_LIMIT(0xf) | GDT_CODE | GDT_G,
+// 16 bit code segment base=0xf limit=0x (SEG32_MODE16BIG_CS)
+GDT_LIMIT(0xf) | GDT_CODE | GDT_G | GDT_BASE(BUILD_BIOS_ADDR),
// 16 bit data segment base=0 limit=0x (SEG32_MODE16BIG_DS)
GDT_LIMIT(0xf) | GDT_DATA | GDT_G,
};
diff --git a/src/romlayout.S b/src/romlayout.S
index 54e5a4d..a469596 100644
--- a/src/romlayout.S
+++ b/src/romlayout.S
@@ -105,7 +105,7 @@ transition16big:
movw %ax, %fs
movw %ax, %gs
-ljmpl $SEG32_MODE16BIG_CS, $(BUILD_BIOS_ADDR + 1f)
+ljmpw $SEG32_MODE16BIG_CS, $1f
.code16gcc
1:
--
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
Re: [RFC PATCH v3 0/3] Add segment limit checks to emulator
On Mon, Jul 12, 2010 at 04:13:06PM +0300, Avi Kivity wrote: > Does SeaBIOS use big real mode now? SeaBIOS calls option roms in big real mode. This is required by the relevant specs. See the transition16big function in src/romlayout.S. It briefly jumps to an address at 0xffxxx during the transition to real-mode. At a quick glance, it looks like it could probably be changed to not use a code address >64K. -Kevin -- 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
Re: [RFC PATCH v3 0/3] Add segment limit checks to emulator
On 07/12/2010 05:41 PM, Gleb Natapov wrote: A good way to do this is to add a segment variable to 'struct operand', and doing all the base adjustment at the end (instead of up front as we do now). That means we'll have the minimum number of places to add checks to. ->read_emulated(), ->write_emulated() get liner address as a parameter and know nothing about 'struct operand'. Luckily emulator.c has only one call for each one of them, so segment checking can be done there just before call to the functions. I'd prefer a new helper (with an additional parameter) so that if a new call is added, we don't need to change anything. -- 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
Re: [RFC PATCH v3 0/3] Add segment limit checks to emulator
On Mon, Jul 12, 2010 at 04:51:10PM +0300, Avi Kivity wrote: > On 07/12/2010 04:39 PM, Mohammed Gamal wrote: > > > >>>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 so, ftrace shows a CR0 access just before the instruction that > >causes the failure. I am not 100% sure though. > > Ok, will be good to know. In any case, I think it can be made to > work even without e_i_g_s=1. > > > >>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)? > >Let me make sure I am understanding this correctly. I added a check in > >do_insn_fetch_byte() checking for CS limit. Similar checks in > >emulate_push() ane emulate_pop() for SS, and checks in > >x86_decode_insn() for SrcSI and DstDI since they causes accesses to > >segment override and ES respectively. Are we on the same page? > > You have to do the check wherever you have a read or write that is > qualified by a segment. So the best place for them is in > ->read_emulated(), ->write_emulated(), and similar. > > A good way to do this is to add a segment variable to 'struct > operand', and doing all the base adjustment at the end (instead of > up front as we do now). That means we'll have the minimum number of > places to add checks to. ->read_emulated(), ->write_emulated() get liner address as a parameter and know nothing about 'struct operand'. Luckily emulator.c has only one call for each one of them, so segment checking can be done there just before call to the functions. > > > >I haven't looked into expand down segments, but I don't think it's > >much of an effort to add though. > > It's needed, since guests will start failing mysteriously if they > use those segments and the limits are incorrect (though I doubt > there are any guests which use expand-down segments). > > -- > 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 -- Gleb. -- 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
Re: [RFC PATCH v3 0/3] Add segment limit checks to emulator
On 07/12/2010 04:39 PM, Mohammed Gamal wrote: 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 so, ftrace shows a CR0 access just before the instruction that causes the failure. I am not 100% sure though. Ok, will be good to know. In any case, I think it can be made to work even without e_i_g_s=1. 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)? Let me make sure I am understanding this correctly. I added a check in do_insn_fetch_byte() checking for CS limit. Similar checks in emulate_push() ane emulate_pop() for SS, and checks in x86_decode_insn() for SrcSI and DstDI since they causes accesses to segment override and ES respectively. Are we on the same page? You have to do the check wherever you have a read or write that is qualified by a segment. So the best place for them is in ->read_emulated(), ->write_emulated(), and similar. A good way to do this is to add a segment variable to 'struct operand', and doing all the base adjustment at the end (instead of up front as we do now). That means we'll have the minimum number of places to add checks to. I haven't looked into expand down segments, but I don't think it's much of an effort to add though. It's needed, since guests will start failing mysteriously if they use those segments and the limits are incorrect (though I doubt there are any guests which use expand-down segments). -- 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
Re: [RFC PATCH v3 0/3] Add segment limit checks to emulator
On 07/12/2010 03:36 PM, Mohammed Gamal wrote: On Mon, Jul 12, 2010 at 9:26 AM, Avi Kivity 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3 0/3] Add segment limit checks to emulator
On Mon, Jul 12, 2010 at 9:26 AM, Avi Kivity 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. > >> >> >> 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. > > -- > I have a truly marvellous patch that fixes the bug which this > signature is too narrow to contain. > > -- 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
Re: [RFC PATCH v3 0/3] Add segment limit checks to emulator
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. 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 have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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
[RFC PATCH v3 0/3] Add segment limit checks to emulator
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! Changes from v2: - Addeded generic segment limit check helpers - Removed individual segment register segment helpers as they're no longer needed Mohammed Gamal (3): Add helper methods to get segment limits x86 emulator: Add segment limit checking helpers x86 emulator: Add segment limit checks to emulator arch/x86/include/asm/kvm_emulate.h |1 + arch/x86/include/asm/kvm_host.h|1 + arch/x86/kvm/emulate.c | 112 --- arch/x86/kvm/svm.c |8 +++ arch/x86/kvm/vmx.c |8 +++ arch/x86/kvm/x86.c | 12 6 files changed, 119 insertions(+), 23 deletions(-) -- 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
