[Qemu-devel] Re: [PATCH] Fix up pxe boot

[Glauber Costa <glommer@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]

On Sun, Sep 07, 2008 at 09:42:07AM +0300, Avi Kivity wrote:
> Glauber Costa wrote:
>> After a second look, here's what it seems to me:
>>
>> It's not in a generic place, such as ldl, because in general, we may want to grab
>> a 32-bit value from a 64-bit address. This is perfectly valid.
>>
>> It's a specifity that the pop instruction, when not in long mode (manual says that in 64-bit mode
>> no 32-bit operand is valid, but then again, qemu should use the POPQ macro), that ssp:sp may overflow,
>> but we don't want it.
>>
>> It would be possible to do something more generic if we had a segment_to_linear() function, that returned
>> the linear address, but we don't.
>>
>> Does it make more sense to you?
>>   
>
> Yes.
>
> I guess tcg code is mostly safe since it generates 32-bit additions for  
> segment bases, so this is limited to the places you identified.  And a  
> helper to add segment bases would be helpful.
>
> -- 
> error compiling committee.c: too many arguments to function
>

what do you think of the attached version?

[-- Attachment #2: 0001-Fix-up-pxe-boot.patch --]
[-- Type: text/plain, Size: 2166 bytes --]

>From e185d17904febce8b9fe0b0d403c0ee9df92ca38 Mon Sep 17 00:00:00 2001
From: Glauber Costa <glommer@redhat.com>
Date: Mon, 1 Sep 2008 17:49:23 -0300
Subject: [PATCH] Fix up pxe boot

As discussed in
http://lists.gnu.org/archive/html/qemu-devel/2008-08/msg00667.html,
current pxe boot is broken for some use cases. The problem
goes away if we reduce the number of allowed bits in the address space
to 32 (which has the side effect of reducing guest max mem size to 4Gb).

After digging for a while, it turns out that it happens because pxelinux
tries to access address 0x10009e9a6, which does not fit a 32-bit address.
A closer look, however, reveals this access is totally valid: It's just
0x9e9a6 with an add carry.

To avoid this, this patch casts the address passed to the POPL macro to
a 32-bit value. This is also done, although just theorectically, for
PUSHL too.

Signed-off-by: Glauber Costa <glommer@redhat.com>
Reported-by: Chris Lalancette <clalance@redhat.com>
CC: Eduardo Habkost <ehabkost@redhat.com>
---
 target-i386/op_helper.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/target-i386/op_helper.c b/target-i386/op_helper.c
index 0b5fdc0..4c3ee06 100644
--- a/target-i386/op_helper.c
+++ b/target-i386/op_helper.c
@@ -590,6 +590,10 @@ do {\
 #define SET_ESP(val, sp_mask) ESP = (ESP & ~(sp_mask)) | ((val) & (sp_mask))
 #endif
 
+/* in 64-bit machines, this can overflow. So this segment addition macro
+ * can be used to trim the value to 32-bit whenever needed */
+#define SEG_ADDL(ssp, sp, sp_mask) ((uint32_t)((ssp) + (sp & (sp_mask))))
+
 /* XXX: add a is_user flag to have proper security support */
 #define PUSHW(ssp, sp, sp_mask, val)\
 {\
@@ -600,7 +604,7 @@ do {\
 #define PUSHL(ssp, sp, sp_mask, val)\
 {\
     sp -= 4;\
-    stl_kernel((ssp) + (sp & (sp_mask)), (val));\
+    stl_kernel(SEG_ADDL(ssp, sp, sp_mask), (uint32_t)(val));\
 }
 
 #define POPW(ssp, sp, sp_mask, val)\
@@ -611,7 +615,7 @@ do {\
 
 #define POPL(ssp, sp, sp_mask, val)\
 {\
-    val = (uint32_t)ldl_kernel((ssp) + (sp & (sp_mask)));\
+    val = (uint32_t)ldl_kernel(SEG_ADDL(ssp, sp, sp_mask));\
     sp += 4;\
 }
 
-- 
1.5.5.1