Bug in protected mode segments?

Bug in protected mode segments?

[Mathias Gottschlag]

I am currently working on my own hobby kernel and tested it on kvm 
today. I think I found a bug in kvm with it (already discussed it on IRC):

I wanted my kernel to be at a higher virtual address, in my case 
0xE0000000. To get it there (Grub loaded it at physical addr 0x100000), 
I followed the steps at http://wiki.osdev.org/Higher_Half_With_GDT:

Grub inits the CPU with no paging and flat segmenting, I now activate 
segments to move the code to 0xE0000000 and later activate paging and 
reset the segments. When I run this code on qemu or on real hardware 
(Athlon XP), everything works well, but on kvm I get several hangs. For 
example I try to write to 0xE00B8000 to write into the VGA framebuffer. 
This addres should now get translated back to 0xB8000 by the segment 
which has the base address 0x20000000, and this definately works on real 
hardware, but on kvm I only notice a hang at the instruction which 
writes at that address (kvm still responds, but doesn't update eip 
anymore, execution stops.

Someone on IRC told me that this might be because address wrapping isn't 
implemented properly (this could have been unnoticed until now as no 
real OS uses such weird segmenting).

You can try it out yourself using the code at 
http://wiki.osdev.org/Higher_Half_With_GDT, this code will work for 
example in qemu, but not in kvm. I attached a version including a build 
script and a script to create the floppy image (you only need gcc, nasm 
and grub, type in "sh build.sh" and you get your image) for testing. It 
should show "Hello world" on a machine where it runs correctly.

Mathias Gottschlag

Re: Bug in protected mode segments?

[Anthony Liguori]

Mathias Gottschlag wrote:
> I am currently working on my own hobby kernel and tested it on kvm 
> today. I think I found a bug in kvm with it (already discussed it on 
> IRC):
>
> I wanted my kernel to be at a higher virtual address, in my case 
> 0xE0000000. To get it there (Grub loaded it at physical addr 
> 0x100000), I followed the steps at 
> http://wiki.osdev.org/Higher_Half_With_GDT:
>
> Grub inits the CPU with no paging and flat segmenting, I now activate 
> segments to move the code to 0xE0000000 and later activate paging and 
> reset the segments. When I run this code on qemu or on real hardware 
> (Athlon XP), everything works well, but on kvm I get several hangs. 
> For example I try to write to 0xE00B8000 to write into the VGA 
> framebuffer. This addres should now get translated back to 0xB8000 by 
> the segment which has the base address 0x20000000, and this definately 
> works on real hardware, but on kvm I only notice a hang at the 
> instruction which writes at that address (kvm still responds, but 
> doesn't update eip anymore, execution stops.

I looked briefly and there didn't appear to be any explicit checks for 
wrap around but I think that it will work correctly since we're always 
using at least unsigned long in the host.  My suspicion is that we're 
somehow getting something wrong with MMIO decoding.

Regards,

Anthony Liguori

> Someone on IRC told me that this might be because address wrapping 
> isn't implemented properly (this could have been unnoticed until now 
> as no real OS uses such weird segmenting).
>
> You can try it out yourself using the code at 
> http://wiki.osdev.org/Higher_Half_With_GDT, this code will work for 
> example in qemu, but not in kvm. I attached a version including a 
> build script and a script to create the floppy image (you only need 
> gcc, nasm and grub, type in "sh build.sh" and you get your image) for 
> testing. It should show "Hello world" on a machine where it runs 
> correctly.
>
> Mathias Gottschlag
> -- 
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in protected mode segments?

[Avi Kivity]

Anthony Liguori wrote:
> Mathias Gottschlag wrote:
>>
>> Grub inits the CPU with no paging and flat segmenting, I now activate 
>> segments to move the code to 0xE0000000 and later activate paging and 
>> reset the segments. When I run this code on qemu or on real hardware 
>> (Athlon XP), everything works well, but on kvm I get several hangs. 
>> For example I try to write to 0xE00B8000 to write into the VGA 
>> framebuffer. This addres should now get translated back to 0xB8000 by 
>> the segment which has the base address 0x20000000, and this 
>> definately works on real hardware, but on kvm I only notice a hang at 
>> the instruction which writes at that address (kvm still responds, but 
>> doesn't update eip anymore, execution stops.
>
> I looked briefly and there didn't appear to be any explicit checks for 
> wrap around but I think that it will work correctly since we're always 
> using at least unsigned long in the host.  My suspicion is that we're 
> somehow getting something wrong with MMIO decoding.

Well, unsigned long is 64-bits on a 64-bit host, so the generated 
address will be 0x1000b8000 instead of 0xb8000.  So the problem here is 
likely to be a missing wraparound, rather than a wraparound.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.