On Sat, Apr 18, 2015 at 10:12:04AM +0800, eJim Lee wrote:
> Hi all,
> I have had two trouble.
> There is a program named wbc and run it on WinXP that was on qemu+kvm+qxl+spice.
> https://drive.google.com/file/d/0BwZHW2TTkEdRNm1rVUZwakxrQTQ/view?usp=sha...
Do you still have trouble when not using qxl/spice? I tested your
program using regular "-vga std" and I don't see any corruption.
-Kevin
Hi all,
I have had two trouble.
There is a program named wbc and run it on WinXP that was on qemu+kvm+qxl+spice.
https://drive.google.com/file/d/0BwZHW2TTkEdRNm1rVUZwakxrQTQ/view?usp=sha...
######################################################
The first trouble:
The program cause screen mess, looked like:
https://drive.google.com/file/d/0BwZHW2TTkEdRajE5cUsyLWY0dU0/view?usp=sha...
I have debugged vgabios and found gfx_write_char have never arrived.
But looked nice after I commented this:
-------------------------------------------------------------------------------------------
// Write a character to the screen.
void
vgafb_write_char(struct cursorpos cp, struct carattr ca)
{
struct vgamode_s *vmode_g = get_current_mode();
if (!vmode_g)
return;
vgafb_set_swcursor(0);
if (GET_GLOBAL(vmode_g->memmodel) != MM_TEXT) {
//gfx_write_char(vmode_g, cp, ca);
return;
}
void *dest_far = text_address(cp);
if (ca.use_attr) {
u16 dummy = (ca.attr << 8) | ca.car;
SET_FARVAR(GET_GLOBAL(vmode_g->sstart), *(u16*)dest_far, dummy);
} else {
SET_FARVAR(GET_GLOBAL(vmode_g->sstart), *(u8*)dest_far, ca.car);
}
}
-------------------------------------------------------------------------------------------
looked like:
https://drive.google.com/file/d/0BwZHW2TTkEdRMDhiNUY2emJFQm8/view?usp=sha...
The following commit also effect screen:
f864b6023ed7b5d6fe8355e7ef2c6f78cd23ecad
vgabios: Rewrite vgafb.c graphics operations to set of 4 standard
operators.
And before patched it, looked like:
https://drive.google.com/file/d/0BwZHW2TTkEdRQXZnWFBLaklwZTQ/view?usp=sha...
######################################################
The Second trouble:
Screen mess after I move mouse whenever I changed or commented
anything, looked like:
https://drive.google.com/file/d/0BwZHW2TTkEdRc3BCdXFZa013UEU/view?usp=sha...
######################################################
In fact, I have tried more:
On XP
----------------------------------
spice qxl ERROR
gtk qxl ERROR
spice cirrus ERROR
spice VGA ERROR
----------------------------------
On spice:
----------------------------------
xp qxl ERROR
win7 qxl ERROR
dos qxl NICE *
xp cirrus ERROR
xp VGA ERROR
----------------------------------
*: work perfectly.
On XP:
------------------------------------------------------------
lgpl_vgabios qxl ERROR
lgpl_vgabios cirrus ERROR
seavgabios qxl ERROR
seavgabios cirrus ERROR
vmware_vgabios vmware_vga WORKED *
------------------------------------------------------------
*: vmware_vgabios is from vmware workstation. That worked but only
support bpp 4 on desktop.
######################################################
I also tried LGPL VGABios and looked like before patch that commit.
I have found the program didn't use vgabios api, but vgabios effect the screen.
######################################################
This is my qemu command:
qemu-system-x86_64 \
-machine pc-i440fx-2.1,accel=kvm,usb=off \
-m 1024 \
-realtime mlock=off \
-smp 1,sockets=1,cores=1,threads=1 \
-no-user-config \
-nodefaults \
-rtc base=localtime \
-no-shutdown \
-global PIIX4_PM.disable_s3=1 \
-global PIIX4_PM.disable_s4=0 \
-boot strict=on \
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
-drive file=/root/ram/xp.append,if=none,id=drive-ide0-0-0,format=qcow2,cache=writeback,discard=unmap
\
-device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2 \
-chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev pty,id=charserial1 \
-device isa-serial,chardev=charserial1,id=serial1 \
-chardev spicevmc,id=charchannel0,name=vdagent \
-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
\
-device usb-tablet,id=input0 \
-spice port=5900,addr=0.0.0.0,disable-ticketing,seamless-migration=on \
-device qxl-vga,id=video0,bus=pci.0,addr=0x2,romfile=/root/seabios/out/vgabios.bin
\
-device AC97,id=sound0,bus=pci.0,addr=0x4 \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \
-cpu 'SandyBridge,hv-relaxed=on' \
-netdev user,id=hostnet0 \
-device virtio-net-pci,netdev=hostnet0,id=net1,bus=pci.0,addr=0x7 \
-chardev stdio,id=debugcon \
-device isa-serial,iobase=0x0402,chardev=debugcon \
Could anyone provide me some idea?
Thanks.
eJim Lee
On Thu, Apr 16, 2015 at 10:08:48PM +0800, penghao122(a)sina.com wrote:
> I configure ram to 4GB,then the win7-64bit vm can boot successfully
> using unmodified seabios. And I find that the vm can boot up after
> about 2 hours when configuring ram to 8G using unmodfied seabios.
What is your qemu/kvm command line?
It works fine for me (with a win7 beta I have locally). I do see a
brief pause around the point where you show a 2 hour delay, but the
delay for me is only a few seconds.
This is the command I used:
../qemu/qemu-2.2.0/x86_64-softmmu/qemu-system-x86_64 -k en-us -snapshot -L test -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios -m 8192 -hda win7beta.img -enable-kvm -vga cirrus -smp 2 -usb
I think your issue should be reported on the QEMU/KVM mailing lists.
It's common to put reserved memory at the end of ram - for example,
run "dmesg | grep e820" on a real machine and see what it reports.
So, this doesn't look like a seabios issue to me.
-Kevin
Hello,
El 16/04/15 a les 15.29, Idwer Vollering ha escrit:
> What does 'readelf -a out/bios.bin.elf' tell you, for each build where
> you either override, or aren't overriding, CC with coreboot's
> i386-elf-gcc or pkg's gcc48 and/or LD from FreeBSD's base or pkg?
>
> payloads/external/SeaBIOS/seabios $ gmake CC=gcc48
> LD=/usr/local/bin/ld &>/dev/null ; readelf -h out/bios.bin.elf | egrep
> 'OS/ABI'
> OS/ABI: UNIX - FreeBSD
>
> payloads/external/SeaBIOS/seabios $
> PATH=/home/idwer/coreboot/git/coreboot/util/crossgcc/xgcc/bin:$PATH
> gmake CROSS_PREFIX=i386-elf- &>/dev/null ; readelf -h out/bios.bin.elf
> | egrep 'OS/ABI'
> OS/ABI: UNIX - System V
I don't seem to have an out/bios.bin.elf after compilation, I only have:
out/bios.bin out/bios.bin.prep out/bios.bin.raw
Roger.
El 15/04/15 a les 20.27, Idwer Vollering ha escrit:
> 2015-04-15 19:31 GMT+02:00 Roger Pau Monné <roger.pau(a)citrix.com>:
>> Hello,
>>
>> I've compiled SeaBIOS on FreeBSD with gcc48
>
> _or_ build and use coreboot's crossgcc toolchain:
> PATH=/path/to/coreboot_git_dir/util/crossgcc/xgcc/bin:$PATH gmake
> CROSS_PREFIX=i386-elf-
I've tried compiling SeaBIOS with gcc and binutils from ports the
following way:
# pkg install binutils gcc48
# PATH=/usr/local/bin/:$PATH gmake V=1 CC=gcc48
And the result is the same, the binary compiles fine but fails to work
as expected.
On the other hand, when using the crossgcc toolchain from coreboot the
resulting binary seems to be working fine.
I've looked at the gcc48 and binutils ports, and they don't seem to
contain any patches that would affect SeaBIOS, but I'm not sure:
https://svnweb.freebsd.org/ports/head/devel/binutils/files/https://svnweb.freebsd.org/ports/head/lang/gcc48/files/
Roger.
----- 原始邮件 -----
发件人：<penghao122(a)sina.com>
收件人："Kevin O'Connor" <kevin(a)koconnor.net>
主题：回复：Re: [SeaBIOS] about ZoneHigh occupying ram from last address of below 4G ram
日期：2015年04月15日 21点15分
----- 原始邮件 -----
发件人：Kevin O'Connor <kevin(a)koconnor.net>
收件人：penghao122(a)sina.com
抄送人：seabios <seabios(a)seabios.org>
主题：Re: [SeaBIOS] about ZoneHigh occupying ram from last address of below 4G ram
日期：2015年04月15日 00点45分
On Tue, Apr 14, 2015 at 11:57:08PM +0800, penghao122(a)sina.com wrote:
> I'm using seabios 1.7.5-0 for kvm ,and I find some problem when
> using windows 7 64bit bandvirtual machine.If I configure the windows
> 7 64bit vm memory to 8GB ,the vm can't boot up very often(some
> win7-64bit version easy to trigger) .I use trace-cmd tool to trace
> it ,the vm just scan from last ram of below 4G(0xc000_0000) to 4G
> address byte by byte.This is very time-consuming.From E820 table,the
> address range contain nothing(it is an address hole).
>
> I query clue from seabios because I can't find any problems in kvm
> or qemu. seabios keep a range of ram from last address below 4G as
> zonehigh ram .I guess the windows os see a not aligned ram address
> space and scan from 0xc000_0000. so I try to change the ZoneHigh to
> low address space (I choose 128MB,grub use from 1MB address
> space).after I changed,I can boot win7-64bit vm normally.
>
> So I want to know whether changing ZoneHigh to 128MB can be a
> general modification.
I haven't seen any other reports of issues like this with Win7. I
suspect something else is going on. Please provide the full debug log
(as described at: http://seabios.org/Debugging ) with an unmodified
seabios from both a succesful boot event and a failed boot event.
-Kevin
I just can' boot succesfully if I use unmodified seabios (vm using 8 GB memory).I will try again.
The attachment is the output of seabios when booting failed.
I'm using seabios 1.7.5-0 for kvm ,and I find some problem when using windows 7 64bit bandvirtual machine.If I configure the windows 7 64bit vm memory to 8GB ,the vm can't boot up very often(some win7-64bit version easy to trigger) .I use trace-cmd tool to trace it ,the vm just scan from last ram of below 4G(0xc000_0000) to 4G address byte by byte.This is very time-consuming.From E820 table,the address range contain nothing(it is an address hole).
I query clue from seabios because I can't find any problems in kvm or qemu.
seabios keep a range of ram from last address below 4G as zonehigh ram .I guess the windows os see a not aligned ram address space and scan from 0xc000_0000. so I try to change the ZoneHigh to low address space (I choose 128MB,grub use from 1MB address space).after I changed,I can boot win7-64bit vm normally.
So I want to know whether changing ZoneHigh to 128MB can be a general modification.
With a few additional checks it's possible to emulate all the leal
cases without requiring a function call. Although this makes the
vgafixup.py code a little more complex it eliminates the need for the
"emulate_leal" function and it produces better code. In my tests,
almost all "leal" instructions are replaced with 4 (or fewer)
instructions.
-Kevin
Kevin O'Connor (2):
vgabios: Add config option for assembler fixups
vgabios: Emulate "leal" instruction
Makefile | 21 +++++++++---------
scripts/vgafixup.py | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++---
vgasrc/Kconfig | 10 +++++++++
vgasrc/vgaentry.S | 28 +++++------------------
4 files changed, 87 insertions(+), 36 deletions(-)
--
1.9.3
This series extends the existing "vgafixup.py" assembler patching
mechanism to also patch out the "leal" instruction that old versions
of x86emu don't support. With this series in place, fc11 and fc12 can
now boot into graphics when using qemu with "std" vga.
Because the assembler munging is getting a bit complicated, the first
patch adds a compile time option to disable all of it. This allows
one to build the vgabios without any of the workarounds.
The out-of-line emulate_leal function does have a bit of overhead -
one x86 instruction is replaced with over 20 instructions. The last
patch in the series optimizes the common case so that most leal
instructions are replaced with only 4-6 instructions.
Also at:
https://github.com/KevinOConnor/seabios/tree/testing
-Kevin
Kevin O'Connor (3):
vgabios: Add config option for assembler fixups
vgabios: Emulate "leal" instruction
vgabios: Optimize leal instruction fixup
Makefile | 21 +++++++++---------
scripts/vgafixup.py | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++---
vgasrc/Kconfig | 10 +++++++++
vgasrc/vgaentry.S | 49 +++++++++++++++++++++++-------------------
4 files changed, 107 insertions(+), 35 deletions(-)
--
1.9.3
On Thu, Apr 09, 2015 at 11:32:25PM +0200, Jon Doe wrote:
> On Thu, Apr 9, 2015 at 6:54 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
> > I gave it a shot anyway - seabios patch is below.
[...]
>
> I can report that this patch also works for FreeBSD 8.2's VESA
> console. There seems to be some unrelated problem when running
> 1.8-stable so I applied it to rel-1.7.5.2
I'm not surprised seabios master would still have a problem (due to
recently reported issue with smsww), but I am surprised 1.8-stable
would have a problem. Can you confirm it was 1.8-stable that was
still broken with the patch?
-Kevin
