| Message ID | 1334657499-20105-1-git-send-email-kraxel@redhat.com |
|---|---|
| State | New |
| Headers | show |
On Tue, 17 Apr 2012, Gerd Hoffmann wrote: > Hi, > > This patch series switches the vgabios binaries shipped by qemu from the > lgpl'ed vgabios to the seabios version. > > There should be no guest-visible changes (especially no regressions) in > theory. The only known (and intentional) exception is the vesa 2.0 > protected mode interface which is not implemented by the seavgabios. What's the reason for it not being done? Regardless, the switch shouldn't happen unless there are glaring omissions like this one. > There are no known issues with linux and windows guests. Testing with > other, more exotic guests is very welcome. > > Note #1: Just pull from git to test, I've zapped the big binary patches > so you can't 'git am' them. > > Note #2: This goes on top of the seabios-1.7.0 pull request just sent, > so pulling this will pull the seabios update too. > > please give it a spin, > Gerd > > The following changes since commit 6b034aa138716a515c88f7894940d5d0aff2f3ed: > > seabios: update to 1.7.0 (2012-04-17 10:51:41 +0200) > > are available in the git repository at: > git://git.kraxel.org/qemu seavgabios-1.7.0 > > Gerd Hoffmann (3): > Add seavgabios build rules to roms/Makefile > Update vgabios binaries > Switch isa vga to seavgabios too. > > hw/vga-isa.c | 2 +- > hw/vga_int.h | 1 - > pc-bios/vgabios-cirrus.bin | Bin 35840 -> 37888 bytes > pc-bios/vgabios-isavga.bin | Bin 0 -> 37888 bytes > pc-bios/vgabios-qxl.bin | Bin 40448 -> 37888 bytes > pc-bios/vgabios-stdvga.bin | Bin 40448 -> 37888 bytes > pc-bios/vgabios-vmware.bin | Bin 40448 -> 37888 bytes > roms/Makefile | 13 +++++++++++++ > roms/config.vga.cirrus | 3 +++ > roms/config.vga.isavga | 3 +++ > roms/config.vga.qxl | 6 ++++++ > roms/config.vga.stdvga | 3 +++ > roms/config.vga.vmware | 6 ++++++ > 13 files changed, 35 insertions(+), 2 deletions(-) > create mode 100644 pc-bios/vgabios-isavga.bin > create mode 100644 roms/config.vga.cirrus > create mode 100644 roms/config.vga.isavga > create mode 100644 roms/config.vga.qxl > create mode 100644 roms/config.vga.stdvga > create mode 100644 roms/config.vga.vmware >
On 04/17/12 13:40, malc wrote: > On Tue, 17 Apr 2012, Gerd Hoffmann wrote: > >> Hi, >> >> This patch series switches the vgabios binaries shipped by qemu from the >> lgpl'ed vgabios to the seabios version. >> >> There should be no guest-visible changes (especially no regressions) in >> theory. The only known (and intentional) exception is the vesa 2.0 >> protected mode interface which is not implemented by the seavgabios. > > What's the reason for it not being done? In summary: Nontrivial effort for questionable gains. First, the lgpl'ed vgabios provides the vesa pmi for the bochs interface (-vga std) only, for the cirrus it is not available. => It can't be a critical feature if our default vga is not supported. Second, the display panning via vesa pmi was broken in qemu for three years(!) and nobody noticed. The linux kernel's vesafb can use the vesa pmi, it is disabled by default though due to bioses tending to be buggy. I'm not aware of other users. => Is this actually used by anyone? Seems not ... Also it can be used by 32bit guests only while the x86 world moves to 64bit ... cheers, Gerd
On Tue, 17 Apr 2012, Gerd Hoffmann wrote: > On 04/17/12 13:40, malc wrote: > > On Tue, 17 Apr 2012, Gerd Hoffmann wrote: > > > >> Hi, > >> > >> This patch series switches the vgabios binaries shipped by qemu from the > >> lgpl'ed vgabios to the seabios version. > >> > >> There should be no guest-visible changes (especially no regressions) in > >> theory. The only known (and intentional) exception is the vesa 2.0 > >> protected mode interface which is not implemented by the seavgabios. > > > > What's the reason for it not being done? > > In summary: Nontrivial effort for questionable gains. It worked before, and it should continue to do so. Seabios not having a PM interface is a regression. > > First, the lgpl'ed vgabios provides the vesa pmi for the bochs interface > (-vga std) only, for the cirrus it is not available. Well aware, Revision 1.48 has some comments. > > => It can't be a critical feature if our default vga is not supported. Opinions are irrelevant, the feature was available before it should continue to be available. > > Second, the display panning via vesa pmi was broken in qemu for three > years(!) and nobody noticed. The linux kernel's vesafb can use the vesa > pmi, it is disabled by default though due to bioses tending to be buggy. > I'm not aware of other users. > > => Is this actually used by anyone? Seems not ... It's used by me, when i feel nostalgic and want to watch old DOS stuff. > > Also it can be used by 32bit guests only while the x86 world moves to > 64bit ... You (plural) don't care about my use cases, i don't care about yours. In a nutshell, i'm opposed to introduction of this since it breaks stuff that works.
On 04/17/2012 07:33 AM, malc wrote: > On Tue, 17 Apr 2012, Gerd Hoffmann wrote: > >> On 04/17/12 13:40, malc wrote: >>> On Tue, 17 Apr 2012, Gerd Hoffmann wrote: >>> >>>> Hi, >>>> >>>> This patch series switches the vgabios binaries shipped by qemu from the >>>> lgpl'ed vgabios to the seabios version. >>>> >>>> There should be no guest-visible changes (especially no regressions) in >>>> theory. The only known (and intentional) exception is the vesa 2.0 >>>> protected mode interface which is not implemented by the seavgabios. >>> >>> What's the reason for it not being done? >> >> In summary: Nontrivial effort for questionable gains. > > It worked before, and it should continue to do so. Seabios not having a PM > interface is a regression. > >> >> First, the lgpl'ed vgabios provides the vesa pmi for the bochs interface >> (-vga std) only, for the cirrus it is not available. > > Well aware, Revision 1.48 has some comments. > >> >> => It can't be a critical feature if our default vga is not supported. > > Opinions are irrelevant, the feature was available before it should > continue to be available. I don't think that's a reasonable position to take. Do you have a specific workload that uses the pm interface? >> Second, the display panning via vesa pmi was broken in qemu for three >> years(!) and nobody noticed. The linux kernel's vesafb can use the vesa >> pmi, it is disabled by default though due to bioses tending to be buggy. >> I'm not aware of other users. >> >> => Is this actually used by anyone? Seems not ... > > It's used by me, when i feel nostalgic and want to watch old DOS stuff. Do you have a specific workload that you know uses the pm interface that you can share? I'd like to confirm that the code actually works today before we try to make it work in a new firmware. Regards, Anthony LIguori
On Tue, 17 Apr 2012, Anthony Liguori wrote: > On 04/17/2012 07:33 AM, malc wrote: > > On Tue, 17 Apr 2012, Gerd Hoffmann wrote: > > > > > On 04/17/12 13:40, malc wrote: > > > > On Tue, 17 Apr 2012, Gerd Hoffmann wrote: > > > > > > > > > Hi, > > > > > > > > > > This patch series switches the vgabios binaries shipped by qemu from > > > > > the > > > > > lgpl'ed vgabios to the seabios version. > > > > > > > > > > There should be no guest-visible changes (especially no regressions) > > > > > in > > > > > theory. The only known (and intentional) exception is the vesa 2.0 > > > > > protected mode interface which is not implemented by the seavgabios. > > > > > > > > What's the reason for it not being done? > > > > > > In summary: Nontrivial effort for questionable gains. > > > > It worked before, and it should continue to do so. Seabios not having a PM > > interface is a regression. > > > > > > > > First, the lgpl'ed vgabios provides the vesa pmi for the bochs interface > > > (-vga std) only, for the cirrus it is not available. > > > > Well aware, Revision 1.48 has some comments. > > > > > > > > => It can't be a critical feature if our default vga is not supported. > > > > Opinions are irrelevant, the feature was available before it should > > continue to be available. > > I don't think that's a reasonable position to take. Do you have a specific > workload that uses the pm interface? Yes, but i need to find time and energy to find out which demos use PM window setting. > > > > Second, the display panning via vesa pmi was broken in qemu for three > > > years(!) and nobody noticed. The linux kernel's vesafb can use the vesa > > > pmi, it is disabled by default though due to bioses tending to be buggy. > > > I'm not aware of other users. > > > > > > => Is this actually used by anyone? Seems not ... > > > > It's used by me, when i feel nostalgic and want to watch old DOS stuff. > > Do you have a specific workload that you know uses the pm interface that you > can share? > Do you have a specific reason for asking the same question twice (puzzled) > I'd like to confirm that the code actually works today before we try to make > it work in a new firmware. > Well, i wrote the patch on which code in LGPL vga bios is based, so yeah, it's a pretty safe bet it works.
On 04/17/2012 09:29 AM, malc wrote: > On Tue, 17 Apr 2012, Anthony Liguori wrote: > >> On 04/17/2012 07:33 AM, malc wrote: >>> On Tue, 17 Apr 2012, Gerd Hoffmann wrote: >>> >>>> On 04/17/12 13:40, malc wrote: >>>>> On Tue, 17 Apr 2012, Gerd Hoffmann wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> This patch series switches the vgabios binaries shipped by qemu from >>>>>> the >>>>>> lgpl'ed vgabios to the seabios version. >>>>>> >>>>>> There should be no guest-visible changes (especially no regressions) >>>>>> in >>>>>> theory. The only known (and intentional) exception is the vesa 2.0 >>>>>> protected mode interface which is not implemented by the seavgabios. >>>>> >>>>> What's the reason for it not being done? >>>> >>>> In summary: Nontrivial effort for questionable gains. >>> >>> It worked before, and it should continue to do so. Seabios not having a PM >>> interface is a regression. >>> >>>> >>>> First, the lgpl'ed vgabios provides the vesa pmi for the bochs interface >>>> (-vga std) only, for the cirrus it is not available. >>> >>> Well aware, Revision 1.48 has some comments. >>> >>>> >>>> => It can't be a critical feature if our default vga is not supported. >>> >>> Opinions are irrelevant, the feature was available before it should >>> continue to be available. >> >> I don't think that's a reasonable position to take. Do you have a specific >> workload that uses the pm interface? > > Yes, but i need to find time and energy to find out which demos use PM > window setting. Okay, it would be very helpful if you could. I think it's fine to hold off on SeaVGABIOS for 1.1 but it would be nice to get it in for 1.2. Having a specific example of something that needs to not break makes it a whole lot easier to deal with IMHO. > >> >>>> Second, the display panning via vesa pmi was broken in qemu for three >>>> years(!) and nobody noticed. The linux kernel's vesafb can use the vesa >>>> pmi, it is disabled by default though due to bioses tending to be buggy. >>>> I'm not aware of other users. >>>> >>>> => Is this actually used by anyone? Seems not ... >>> >>> It's used by me, when i feel nostalgic and want to watch old DOS stuff. >> >> Do you have a specific workload that you know uses the pm interface that you >> can share? >> > > Do you have a specific reason for asking the same question twice (puzzled) I don't think it's reasonable to claim something is a regression unless there's a real test case that breaks that others can reasonably reproduce. Hence my emphasize on talking about a specific workload over an abstract feature. Regards, Anthony Liguori >> I'd like to confirm that the code actually works today before we try to make >> it work in a new firmware. >> > > Well, i wrote the patch on which code in LGPL vga bios is based, so yeah, > it's a pretty safe bet it works.
Am 17.04.2012 16:39, schrieb Anthony Liguori: > On 04/17/2012 09:29 AM, malc wrote: >> On Tue, 17 Apr 2012, Anthony Liguori wrote: >> >>> On 04/17/2012 07:33 AM, malc wrote: >>>> On Tue, 17 Apr 2012, Gerd Hoffmann wrote: >>>> >>>>> On 04/17/12 13:40, malc wrote: >>>>>> On Tue, 17 Apr 2012, Gerd Hoffmann wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> This patch series switches the vgabios binaries shipped by qemu >>>>>>> from >>>>>>> the >>>>>>> lgpl'ed vgabios to the seabios version. >>>>>>> >>>>>>> There should be no guest-visible changes (especially no >>>>>>> regressions) >>>>>>> in >>>>>>> theory. The only known (and intentional) exception is the vesa 2.0 >>>>>>> protected mode interface which is not implemented by the >>>>>>> seavgabios. >>>>>> >>>>>> What's the reason for it not being done? >>>>> >>>>> In summary: Nontrivial effort for questionable gains. >>>> >>>> It worked before, and it should continue to do so. Seabios not >>>> having a PM >>>> interface is a regression. >>>> >>>>> >>>>> First, the lgpl'ed vgabios provides the vesa pmi for the bochs >>>>> interface >>>>> (-vga std) only, for the cirrus it is not available. >>>> >>>> Well aware, Revision 1.48 has some comments. >>>> >>>>> >>>>> => It can't be a critical feature if our default vga is not >>>>> supported. >>>> >>>> Opinions are irrelevant, the feature was available before it should >>>> continue to be available. >>> >>> I don't think that's a reasonable position to take. Do you have a >>> specific >>> workload that uses the pm interface? >> >> Yes, but i need to find time and energy to find out which demos use PM >> window setting. > > Okay, it would be very helpful if you could. I think it's fine to > hold off on SeaVGABIOS for 1.1 but it would be nice to get it in for 1.2. You could also add SeaVGABIOS using to 1.1 while still providing the current default vgabios. Just put the new files in a new subdirectory. Then it's easier for users to test the SeaVGABIOS without the need to pull from Gerd's git repository. Regards, Stefan W.
On 04/17/2012 11:20 AM, Stefan Weil wrote: > Am 17.04.2012 16:39, schrieb Anthony Liguori: > > You could also add SeaVGABIOS using to 1.1 while still providing the current > default vgabios. > Just put the new files in a new subdirectory. Then it's easier for users to test > the SeaVGABIOS > without the need to pull from Gerd's git repository. I'd prefer to just wait. Moving to a quarterly release cycle post-1.1 would mean that users don't need to wait very long to try new things out. Having transient options or dual firmwares just makes switching harder to do because it creates a temptation to leave both options available until every last little detail is resolved. Doing a one-time switch puts emphasis on resolving the details ASAP. Regards, Anthony Liguori > > Regards, > Stefan W. > > > >
Negative also here: Don't see anything on screen on startup... From log, latest qemu-kvm git version: Running option rom at c180:3d4e Running option rom at c180:3da2 Running option rom at c180:3df6 Running option rom at c580:0003 qemu-system-x86_64: /root/download/qemu/git/qemu-kvm/exec.c:2641: register_subpage: Assertion `existing.mr->subpage || existing.mr == &io_mem_unassigned' failed. Startup is done with the following command: /root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -drive file=1.img,media=disk,if=scsi,bus=0,unit=0 -drive file=2.img,media=disk,if=scsi,bus=0,unit=1 -drive file=3.img,media=disk,if=scsi,bus=0,unit=2 -boot order=cad,menu=on -m 2048 -k de -vga vmware -vnc :0 -bios /root/download/seabios/git/seabios/out/bios.bin -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios -option-rom BIOS/V4.19/8xx_64.rom -device rtl8139,mac=00:02:44:92:87:6a,vlan=0,romfile= -net tap,ifname=tap0,script=no,downscript=no,vlan=0 Backtrace isn't valid. Old integrated BIOS is valid and works well. Ciao, Gerhard On 17.04.2012 12:11, Gerd Hoffmann wrote: > Hi, > > This patch series switches the vgabios binaries shipped by qemu from the > lgpl'ed vgabios to the seabios version. > > There should be no guest-visible changes (especially no regressions) in > theory. The only known (and intentional) exception is the vesa 2.0 > protected mode interface which is not implemented by the seavgabios. > There are no known issues with linux and windows guests. Testing with > other, more exotic guests is very welcome. > > Note #1: Just pull from git to test, I've zapped the big binary patches > so you can't 'git am' them. > > Note #2: This goes on top of the seabios-1.7.0 pull request just sent, > so pulling this will pull the seabios update too. > > please give it a spin, > Gerd > > The following changes since commit 6b034aa138716a515c88f7894940d5d0aff2f3ed: > > seabios: update to 1.7.0 (2012-04-17 10:51:41 +0200) > > are available in the git repository at: > git://git.kraxel.org/qemu seavgabios-1.7.0 > > Gerd Hoffmann (3): > Add seavgabios build rules to roms/Makefile > Update vgabios binaries > Switch isa vga to seavgabios too. > > hw/vga-isa.c | 2 +- > hw/vga_int.h | 1 - > pc-bios/vgabios-cirrus.bin | Bin 35840 -> 37888 bytes > pc-bios/vgabios-isavga.bin | Bin 0 -> 37888 bytes > pc-bios/vgabios-qxl.bin | Bin 40448 -> 37888 bytes > pc-bios/vgabios-stdvga.bin | Bin 40448 -> 37888 bytes > pc-bios/vgabios-vmware.bin | Bin 40448 -> 37888 bytes > roms/Makefile | 13 +++++++++++++ > roms/config.vga.cirrus | 3 +++ > roms/config.vga.isavga | 3 +++ > roms/config.vga.qxl | 6 ++++++ > roms/config.vga.stdvga | 3 +++ > roms/config.vga.vmware | 6 ++++++ > 13 files changed, 35 insertions(+), 2 deletions(-) > create mode 100644 pc-bios/vgabios-isavga.bin > create mode 100644 roms/config.vga.cirrus > create mode 100644 roms/config.vga.isavga > create mode 100644 roms/config.vga.qxl > create mode 100644 roms/config.vga.stdvga > create mode 100644 roms/config.vga.vmware >
Hi, >> Second, the display panning via vesa pmi was broken in qemu for three >> years(!) and nobody noticed. The linux kernel's vesafb can use the vesa >> pmi, it is disabled by default though due to bioses tending to be buggy. >> I'm not aware of other users. >> >> => Is this actually used by anyone? Seems not ... > > It's used by me, when i feel nostalgic and want to watch old DOS stuff. Pointer? I'd like to have a test case which breaks with the new vgabios. thanks, Gerd
On 18.04.2012 14:31, Gerd Hoffmann wrote: > Hi, > >>> Second, the display panning via vesa pmi was broken in qemu for three >>> years(!) and nobody noticed. The linux kernel's vesafb can use the vesa >>> pmi, it is disabled by default though due to bioses tending to be buggy. >>> I'm not aware of other users. >>> >>> => Is this actually used by anyone? Seems not ... >> >> It's used by me, when i feel nostalgic and want to watch old DOS stuff. > > Pointer? > I'd like to have a test case which breaks with the new vgabios. We talked with malc briefly on irc yesterday, and this is what he gave me: http://cvs.savannah.gnu.org/viewvc/vgabios/vbe.c?root=vgabios&r1=1.47&r2=1.48 this is not the test case but the missing support he's referring to. It appears the patch implements just 2 functions which both just does int10, so should be easy to implement in seabios, but my knowlege isn's sufficient to do that (it needs some asm coding). Thanks, /mjt
Hi, [ adding seabios list to Cc:, topic is the missing vesa 2.0 protected mode interface in seavgabios ] >> Pointer? >> I'd like to have a test case which breaks with the new vgabios. > > We talked with malc briefly on irc yesterday, and this is what > he gave me: > > http://cvs.savannah.gnu.org/viewvc/vgabios/vbe.c?root=vgabios&r1=1.47&r2=1.48 > > this is not the test case but the missing support he's referring to. > > It appears the patch implements just 2 functions which both just does > int10, It isn't that simple. Just invoking int10 from protected mode isn't guaranteed to have the desired effect. It certainly wouldn't work for linux vesafb panning. It might work for dos extenders, they might have the idt entry for int10 and other bios interrupts setup accordingly to do a real-mode -> bios call -> protected mode transition to simplify porting dos code to the 32bit extender. But even for that use case it is IMHO pointless as the reason to have a 32bit interface is to avoid the expensive real mode switch in the first place ... The code has been changed later on, for good reasons, see http://git.qemu.org/?p=vgabios.git;a=commitdiff;h=72c270d8091fb0f09e8291cc0e7154b075b921a9 > so should be easy to implement in seabios, seavgabios has no 32bit code at all at the moment. vesa pmi didn't seem to be important enougth to change it. seabios is a 16/32bit hybrid with some code being compiled twice for both modes; dunno how reusable the seabios infrastructure is. Unlike seabios seavgabios has no fixed load address, which makes things a bit more complicated when it comes to global variables I think. At least for the bochs interface this wouldn't be a showstopper though. Instead of using global variables to figure stuff like the active video mode we can just read the bits we need from the bochs device registers. Costs some extra vmexits of course, and we wouldn't have code sharing for 16+32bit paths. cheers, Gerd
On Wed, 18 Apr 2012, Gerd Hoffmann wrote: > Hi, > > [ adding seabios list to Cc:, topic is the missing vesa 2.0 protected > mode interface in seavgabios ] > > >> Pointer? > >> I'd like to have a test case which breaks with the new vgabios. > > > > We talked with malc briefly on irc yesterday, and this is what > > he gave me: > > > > http://cvs.savannah.gnu.org/viewvc/vgabios/vbe.c?root=vgabios&r1=1.47&r2=1.48 > > > > this is not the test case but the missing support he's referring to. > > > > It appears the patch implements just 2 functions which both just does > > int10, > > It isn't that simple. Just invoking int10 from protected mode isn't > guaranteed to have the desired effect. It certainly wouldn't work for > linux vesafb panning. It might work for dos extenders, they might have > the idt entry for int10 and other bios interrupts setup accordingly to > do a real-mode -> bios call -> protected mode transition to simplify > porting dos code to the 32bit extender. But even for that use case it > is IMHO pointless as the reason to have a 32bit interface is to avoid > the expensive real mode switch in the first place ... I needed DOS to work and it did, for me, in turn, linux vesafb is pointless. > > The code has been changed later on, for good reasons, see > http://git.qemu.org/?p=vgabios.git;a=commitdiff;h=72c270d8091fb0f09e8291cc0e7154b075b921a9 > > > so should be easy to implement in seabios, > > seavgabios has no 32bit code at all at the moment. vesa pmi didn't seem > to be important enougth to change it. > > seabios is a 16/32bit hybrid with some code being compiled twice for > both modes; dunno how reusable the seabios infrastructure is. Unlike > seabios seavgabios has no fixed load address, which makes things a bit > more complicated when it comes to global variables I think. > > At least for the bochs interface this wouldn't be a showstopper though. > Instead of using global variables to figure stuff like the active video > mode we can just read the bits we need from the bochs device registers. > Costs some extra vmexits of course, and we wouldn't have code sharing > for 16+32bit paths. > > cheers, > Gerd >
On Wed, Apr 18, 2012 at 10:45:06PM +0400, malc wrote: > On Wed, 18 Apr 2012, Gerd Hoffmann wrote: > > > We talked with malc briefly on irc yesterday, and this is what > > > he gave me: > > > > > > http://cvs.savannah.gnu.org/viewvc/vgabios/vbe.c?root=vgabios&r1=1.47&r2=1.48 > > > > > > this is not the test case but the missing support he's referring to. > > > > > > It appears the patch implements just 2 functions which both just does > > > int10, > > > > It isn't that simple. Just invoking int10 from protected mode isn't > > guaranteed to have the desired effect. It certainly wouldn't work for > > linux vesafb panning. It might work for dos extenders, they might have > > the idt entry for int10 and other bios interrupts setup accordingly to > > do a real-mode -> bios call -> protected mode transition to simplify > > porting dos code to the 32bit extender. But even for that use case it > > is IMHO pointless as the reason to have a 32bit interface is to avoid > > the expensive real mode switch in the first place ... > > I needed DOS to work and it did, for me, in turn, linux vesafb is > pointless. One can't issue "int 0x10" in 32bit mode under DOS and expect it to do anything reasonable. It may have worked for your particular application, but it is just as likely to crash the machine with the next application. -Kevin
On Wed, Apr 18, 2012 at 03:07:35PM +0200, Gerd Hoffmann wrote: > seavgabios has no 32bit code at all at the moment. vesa pmi didn't seem > to be important enougth to change it. > > seabios is a 16/32bit hybrid with some code being compiled twice for > both modes; dunno how reusable the seabios infrastructure is. If 32bit calls are needed, then I expect the same would be done for the VGA BIOS. >Unlike > seabios seavgabios has no fixed load address, which makes things a bit > more complicated when it comes to global variables I think. That's not an issue as the "32 bit segmented" wrappers in SeaBIOS already handle code relocation. The complexity is in updating the build scripts to work for both SeaBIOS and SeaVGABIOS. It's not difficult, but it is a chore. As others have mentioned in this thread, I would like to get a hold of one of the applications that require the 32bit vga bios support. -Kevin
On 04/18/2012 08:07 AM, Gerhard Wiesinger wrote: > Negative also here: > Don't see anything on screen on startup... > > From log, latest qemu-kvm git version: > Running option rom at c180:3d4e > Running option rom at c180:3da2 > Running option rom at c180:3df6 > Running option rom at c580:0003 > qemu-system-x86_64: /root/download/qemu/git/qemu-kvm/exec.c:2641: > register_subpage: Assertion `existing.mr->subpage || existing.mr == > &io_mem_unassigned' failed. > <snip> > Backtrace isn't valid. Can you build with ./configure --disable-pie --enable-debug and retry?
On Wed, 18 Apr 2012, Kevin O'Connor wrote: > On Wed, Apr 18, 2012 at 10:45:06PM +0400, malc wrote: > > On Wed, 18 Apr 2012, Gerd Hoffmann wrote: > > > > We talked with malc briefly on irc yesterday, and this is what > > > > he gave me: > > > > > > > > http://cvs.savannah.gnu.org/viewvc/vgabios/vbe.c?root=vgabios&r1=1.47&r2=1.48 > > > > > > > > this is not the test case but the missing support he's referring to. > > > > > > > > It appears the patch implements just 2 functions which both just does > > > > int10, > > > > > > It isn't that simple. Just invoking int10 from protected mode isn't > > > guaranteed to have the desired effect. It certainly wouldn't work for > > > linux vesafb panning. It might work for dos extenders, they might have > > > the idt entry for int10 and other bios interrupts setup accordingly to > > > do a real-mode -> bios call -> protected mode transition to simplify > > > porting dos code to the 32bit extender. But even for that use case it > > > is IMHO pointless as the reason to have a 32bit interface is to avoid > > > the expensive real mode switch in the first place ... > > > > I needed DOS to work and it did, for me, in turn, linux vesafb is > > pointless. > > One can't issue "int 0x10" in 32bit mode under DOS and expect it to do > anything reasonable. It may have worked for your particular > application, but it is just as likely to crash the machine with the > next application. In theory - yes, in practice most DOS extenders do bounce those (DOS4G, DOS16M, Wext, pmode/w, whatever), the use case was old DOS demos and it's sufficient for it.
On Wed, 18 Apr 2012, Gerd Hoffmann wrote: > Hi, > > >> Second, the display panning via vesa pmi was broken in qemu for three > >> years(!) and nobody noticed. The linux kernel's vesafb can use the vesa > >> pmi, it is disabled by default though due to bioses tending to be buggy. > >> I'm not aware of other users. > >> > >> => Is this actually used by anyone? Seems not ... > > > > It's used by me, when i feel nostalgic and want to watch old DOS stuff. > > Pointer? > I'd like to have a test case which breaks with the new vgabios. http://pouet.net/prod.php?which=5334 uses 4f0a at least. > > thanks, > Gerd >
Hi, This patch series switches the vgabios binaries shipped by qemu from the lgpl'ed vgabios to the seabios version. There should be no guest-visible changes (especially no regressions) in theory. The only known (and intentional) exception is the vesa 2.0 protected mode interface which is not implemented by the seavgabios. There are no known issues with linux and windows guests. Testing with other, more exotic guests is very welcome. Note #1: Just pull from git to test, I've zapped the big binary patches so you can't 'git am' them. Note #2: This goes on top of the seabios-1.7.0 pull request just sent, so pulling this will pull the seabios update too. please give it a spin, Gerd The following changes since commit 6b034aa138716a515c88f7894940d5d0aff2f3ed: seabios: update to 1.7.0 (2012-04-17 10:51:41 +0200) are available in the git repository at: git://git.kraxel.org/qemu seavgabios-1.7.0 Gerd Hoffmann (3): Add seavgabios build rules to roms/Makefile Update vgabios binaries Switch isa vga to seavgabios too. hw/vga-isa.c | 2 +- hw/vga_int.h | 1 - pc-bios/vgabios-cirrus.bin | Bin 35840 -> 37888 bytes pc-bios/vgabios-isavga.bin | Bin 0 -> 37888 bytes pc-bios/vgabios-qxl.bin | Bin 40448 -> 37888 bytes pc-bios/vgabios-stdvga.bin | Bin 40448 -> 37888 bytes pc-bios/vgabios-vmware.bin | Bin 40448 -> 37888 bytes roms/Makefile | 13 +++++++++++++ roms/config.vga.cirrus | 3 +++ roms/config.vga.isavga | 3 +++ roms/config.vga.qxl | 6 ++++++ roms/config.vga.stdvga | 3 +++ roms/config.vga.vmware | 6 ++++++ 13 files changed, 35 insertions(+), 2 deletions(-) create mode 100644 pc-bios/vgabios-isavga.bin create mode 100644 roms/config.vga.cirrus create mode 100644 roms/config.vga.isavga create mode 100644 roms/config.vga.qxl create mode 100644 roms/config.vga.stdvga create mode 100644 roms/config.vga.vmware