[Qemu-devel] Seabios dislikes -M isapc

[Qemu-devel] Seabios dislikes -M isapc

[Jan Kiszka]

Hi,

Seabios seems to have some assumptions built in that break when -M isapc
is selected. Is this supposed to work or is isapc about to die?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: Seabios dislikes -M isapc

[Sebastian Herbszt]

Jan Kiszka wrote:
> Hi,
> 
> Seabios seems to have some assumptions built in that break when -M isapc
> is selected. Is this supposed to work or is isapc about to die?

SeaBIOS doesn't POST if the F-segment is not writeable [1]. A possible, but IMO
wrong fix was posted on the list [2].

[1] http://lists.gnu.org/archive/html/qemu-devel/2009-11/msg01188.html
[2] http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg00445.html

- Sebastian

[Qemu-devel] Re: Seabios dislikes -M isapc

[Jan Kiszka]

Sebastian Herbszt wrote:
> Jan Kiszka wrote:
>> Hi,
>>
>> Seabios seems to have some assumptions built in that break when -M isapc
>> is selected. Is this supposed to work or is isapc about to die?
> 
> SeaBIOS doesn't POST if the F-segment is not writeable [1]. A possible, but IMO
> wrong fix was posted on the list [2].
> 
> [1] http://lists.gnu.org/archive/html/qemu-devel/2009-11/msg01188.html
> [2] http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg00445.html
> 

Indeed, [2] makes it work again.

But taking away IO_MEM_ROM really looks like a lazy workaround. I don't
know how much Seabios needs to write - can't it use normal RAM for this?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: Seabios dislikes -M isapc

[Kevin O'Connor]

On Mon, Feb 08, 2010 at 08:09:17PM +0100, Jan Kiszka wrote:
> Sebastian Herbszt wrote:
> > Jan Kiszka wrote:
> >> Hi,
> >>
> >> Seabios seems to have some assumptions built in that break when -M isapc
> >> is selected. Is this supposed to work or is isapc about to die?
> > 
> > SeaBIOS doesn't POST if the F-segment is not writeable [1]. A possible, but IMO
> > wrong fix was posted on the list [2].
> > 
> > [1] http://lists.gnu.org/archive/html/qemu-devel/2009-11/msg01188.html
> > [2] http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg00445.html
> > 
> 
> Indeed, [2] makes it work again.
> 
> But taking away IO_MEM_ROM really looks like a lazy workaround. I don't
> know how much Seabios needs to write - can't it use normal RAM for this?

Handling a read-only f-segment in SeaBIOS would result in significant
code complexity, and some features (like smbios) couldn't be made to
work at all.

I believe it would be far simpler to add a mechanism for
locking/unlocking the f-segment in non-pci mode than it would be to
make seabios work with a read-only f-segment.

Finally, in the normal pci enabled case, both SeaBIOS and bochs bios
will lock the f-segment regardless of how it starts.  So, the patch at
[1] is pretty harmless and it leads to an overall simplification.

-Kevin

[Qemu-devel] Re: Seabios dislikes -M isapc

[Sebastian Herbszt]

Kevin O'Connor wrote:
> On Mon, Feb 08, 2010 at 08:09:17PM +0100, Jan Kiszka wrote:
>> Sebastian Herbszt wrote:
>> > Jan Kiszka wrote:
>> >> Hi,
>> >>
>> >> Seabios seems to have some assumptions built in that break when -M isapc
>> >> is selected. Is this supposed to work or is isapc about to die?
>> > 
>> > SeaBIOS doesn't POST if the F-segment is not writeable [1]. A possible, but IMO
>> > wrong fix was posted on the list [2].
>> > 
>> > [1] http://lists.gnu.org/archive/html/qemu-devel/2009-11/msg01188.html
>> > [2] http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg00445.html
>> > 
>> 
>> Indeed, [2] makes it work again.
>> 
>> But taking away IO_MEM_ROM really looks like a lazy workaround. I don't
>> know how much Seabios needs to write - can't it use normal RAM for this?
> 
> Handling a read-only f-segment in SeaBIOS would result in significant
> code complexity, and some features (like smbios) couldn't be made to
> work at all.
> 
> I believe it would be far simpler to add a mechanism for
> locking/unlocking the f-segment in non-pci mode than it would be to
> make seabios work with a read-only f-segment.
> 
> Finally, in the normal pci enabled case, both SeaBIOS and bochs bios
> will lock the f-segment regardless of how it starts.  So, the patch at
> [1] is pretty harmless and it leads to an overall simplification.

On the other hand the F-segment will stay unlocked on isapc.

Bochs BIOS comes in two flavours: BIOS-bochs-legacy (rombios) and
BIOS-bochs-latest (rombios + rombios32). None of both requires the
F-segment to be writeable. BIOS-bochs-legacy doesn't put anything there.
BIOS-bochs-latest puts some tables (e.g. mp, acpi) there unless
BX_USE_EBDA_TABLES is set.

- Sebastian

Re: [Qemu-devel] Seabios dislikes -M isapc

[Andreas Färber]

Am 08.02.2010 um 11:17 schrieb Jan Kiszka:

> is isapc about to die?

I would've thought that with qdev and configuration files, "unusual"  
configurations will become better suppported, not less.

Andreas

Re: [Qemu-devel] Seabios dislikes -M isapc

[Anthony Liguori]

On 02/08/2010 04:17 AM, Jan Kiszka wrote:
> Hi,
>
> Seabios seems to have some assumptions built in that break when -M isapc
> is selected. Is this supposed to work or is isapc about to die?
>    

Does anything actually require isapc?

pc has an ISA bridge, a PCI VGA device is still VGA/SVGA compliant.

Would anything break if we just dropped isapc?

Regards,

Anthony Liguori

> Jan
>
>    

Re: [Qemu-devel] Seabios dislikes -M isapc

[Natalia Portillo]

There are operating systems that simple conflict with some assumptions  
made by PCI architecture.

Rembember that the PC memory map changed to include the PCI  
configuration space and so on, space that can be expected to contain  
other data, or not at all, and could be used in ISA/EISA/VLB/MCA  
systems by PCI-unaware operating systems or applications.

El 09/02/2010, a las 19:50, Anthony Liguori escribió:

> On 02/08/2010 04:17 AM, Jan Kiszka wrote:
>> Hi,
>>
>> Seabios seems to have some assumptions built in that break when -M  
>> isapc
>> is selected. Is this supposed to work or is isapc about to die?
>>
>
> Does anything actually require isapc?
>
> pc has an ISA bridge, a PCI VGA device is still VGA/SVGA compliant.
>
> Would anything break if we just dropped isapc?
>
> Regards,
>
> Anthony Liguori
>
>> Jan
>>
>>
>
>
>

Re: [Qemu-devel] Seabios dislikes -M isapc

[Anthony Liguori]

On 02/09/2010 02:36 PM, Natalia Portillo wrote:
> There are operating systems that simple conflict with some assumptions 
> made by PCI architecture.
>
> Rembember that the PC memory map changed to include the PCI 
> configuration space and so on, space that can be expected to contain 
> other data, or not at all, and could be used in ISA/EISA/VLB/MCA 
> systems by PCI-unaware operating systems or applications.

But practically speaking, given the devices that we emulate, is there 
any workload that works with -M isapc but not -M pc?

Having to support an ISA and PCI system in the BIOS is a bit of a 
burden.  If we can eliminate that without regressing any guest 
workloads, I think it would be a net win.

Regards,

Anthony Liguori

Re: [Qemu-devel] Seabios dislikes -M isapc

[Natalia Portillo]

Xenix is currently working (when copied from real hardware).
As well Interactive UNIX and some other non-DOS from 8086 and 286 era.

I'm not really sure that operating systems (specially the 8086 ones  
that do mmu functions in software) will be happy with the PCI bus  
present.

Same for first 386 operating systems (OS/2 2, UNIX, Xenix, so on).

I don't think it is so bad forking the BIOS, letting the ISA one only  
for bug fixes, and the PCI one for new features.
Even the ISA BIOS can be code cleaned, there is no SMBIOS or ACPI in  
ISA hardware.

Or, use bochs bios, that we know is working (at least for now) for  
isapc, and seabios for pcipc.

There are a lot of ways to do that, but I think that simply forgetting  
about isapc and deleting it is not a bugfix, but a big big bug.

El 09/02/2010, a las 21:05, Anthony Liguori escribió:

> On 02/09/2010 02:36 PM, Natalia Portillo wrote:
>> There are operating systems that simple conflict with some  
>> assumptions made by PCI architecture.
>>
>> Rembember that the PC memory map changed to include the PCI  
>> configuration space and so on, space that can be expected to  
>> contain other data, or not at all, and could be used in ISA/EISA/ 
>> VLB/MCA systems by PCI-unaware operating systems or applications.
>
> But practically speaking, given the devices that we emulate, is  
> there any workload that works with -M isapc but not -M pc?
>
> Having to support an ISA and PCI system in the BIOS is a bit of a  
> burden.  If we can eliminate that without regressing any guest  
> workloads, I think it would be a net win.
>
> Regards,
>
> Anthony Liguori

Re: [Qemu-devel] Seabios dislikes -M isapc

[Anthony Liguori]

On 02/09/2010 03:36 PM, Natalia Portillo wrote:
> Xenix is currently working (when copied from real hardware).
> As well Interactive UNIX and some other non-DOS from 8086 and 286 era.
>
> I'm not really sure that operating systems (specially the 8086 ones 
> that do mmu functions in software) will be happy with the PCI bus 
> present.
>
> Same for first 386 operating systems (OS/2 2, UNIX, Xenix, so on).
>
> I don't think it is so bad forking the BIOS, letting the ISA one only 
> for bug fixes, and the PCI one for new features.
> Even the ISA BIOS can be code cleaned, there is no SMBIOS or ACPI in 
> ISA hardware.

I doubt anyone is going to want to actually maintain an ISA BIOS solely 
to support these OSes.

But at any rate, I'd like to see someone actually confirm that something 
works with isapc and not with pc.

>
> Or, use bochs bios, that we know is working (at least for now) for 
> isapc, and seabios for pcipc.
>
> There are a lot of ways to do that, but I think that simply forgetting 
> about isapc and deleting it is not a bugfix, but a big big bug.

If nothing actually requires isapc, then I don't see how removing it is 
a bug.  Heck, if we just alias isapc to pc, then I doubt anyone would 
actually notice :-)

Regards,

ANthony Liguori

Re: [Qemu-devel] Seabios dislikes -M isapc

[malc]

On Tue, 9 Feb 2010, Natalia Portillo wrote:

> Xenix is currently working (when copied from real hardware).
> As well Interactive UNIX and some other non-DOS from 8086 and 286 era.
> 
> I'm not really sure that operating systems (specially the 8086 ones that do
> mmu functions in software) will be happy with the PCI bus present.
> 
> Same for first 386 operating systems (OS/2 2, UNIX, Xenix, so on).

News to me that OS/2 worked.. I don't quite remember which version
someone (you?) asked me to try on IRC a few years back, but it definitely
didn't work.

[..snip..]

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] Seabios dislikes -M isapc

[Aurelien Jarno]

On Wed, Feb 10, 2010 at 01:41:01AM +0300, malc wrote:
> On Tue, 9 Feb 2010, Natalia Portillo wrote:
> 
> > Xenix is currently working (when copied from real hardware).
> > As well Interactive UNIX and some other non-DOS from 8086 and 286 era.
> > 
> > I'm not really sure that operating systems (specially the 8086 ones that do
> > mmu functions in software) will be happy with the PCI bus present.
> > 
> > Same for first 386 operating systems (OS/2 2, UNIX, Xenix, so on).
> 
> News to me that OS/2 worked.. I don't quite remember which version
> someone (you?) asked me to try on IRC a few years back, but it definitely
> didn't work.
> 

I have got OS/2 warp working under QEMU a few years ago. I couldn't give
more details though, I just remember it was working nicely.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] Seabios dislikes -M isapc

[malc]

On Wed, 10 Feb 2010, Aurelien Jarno wrote:

> On Wed, Feb 10, 2010 at 01:41:01AM +0300, malc wrote:
> > On Tue, 9 Feb 2010, Natalia Portillo wrote:
> > 
> > > Xenix is currently working (when copied from real hardware).
> > > As well Interactive UNIX and some other non-DOS from 8086 and 286 era.
> > > 
> > > I'm not really sure that operating systems (specially the 8086 ones that do
> > > mmu functions in software) will be happy with the PCI bus present.
> > > 
> > > Same for first 386 operating systems (OS/2 2, UNIX, Xenix, so on).
> > 
> > News to me that OS/2 worked.. I don't quite remember which version
> > someone (you?) asked me to try on IRC a few years back, but it definitely
> > didn't work.
> > 
> 
> I have got OS/2 warp working under QEMU a few years ago. I couldn't give
> more details though, I just remember it was working nicely.

warp/merlin - sure, i was talking about version 1.x/2.x

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] Seabios dislikes -M isapc

[Anthony Liguori]

On 02/09/2010 05:25 PM, Aurelien Jarno wrote:
> On Wed, Feb 10, 2010 at 01:41:01AM +0300, malc wrote:
>    
>> On Tue, 9 Feb 2010, Natalia Portillo wrote:
>>
>>      
>>> Xenix is currently working (when copied from real hardware).
>>> As well Interactive UNIX and some other non-DOS from 8086 and 286 era.
>>>
>>> I'm not really sure that operating systems (specially the 8086 ones that do
>>> mmu functions in software) will be happy with the PCI bus present.
>>>
>>> Same for first 386 operating systems (OS/2 2, UNIX, Xenix, so on).
>>>        
>> News to me that OS/2 worked.. I don't quite remember which version
>> someone (you?) asked me to try on IRC a few years back, but it definitely
>> didn't work.
>>
>>      
> I have got OS/2 warp working under QEMU a few years ago. I couldn't give
> more details though, I just remember it was working nicely.
>    

The problem with isapc is that it uses a different chipset (or rather, 
doesn't use a PCI chipset).  I think the current thinking with 
target-i386 config files is that while you should be able to customize 
the system, some of the core bits would always be there.  For instance, 
the PCI chipset, the APIC, etc.  These things are very tied to a platform.

Firmware is really hard to implement if you have to deal with supporting 
multiple chipsets.

Also, if we don't have a workload that actually needs isapc, that 
suggests that there's no real way to test that isapc doesn't have 
non-ISA things creep into it.

Given that, I'm inclined to suggest that we mark isapc as deprecated, 
give people some time to comment on it, and then provided that we still 
don't think it's necessary, change isapc to simply use isa devices while 
still using a PCI chipset.

Regards,

Anthony Liguori

Re: [Qemu-devel] Seabios dislikes -M isapc

[malc]

On Tue, 9 Feb 2010, Anthony Liguori wrote:

> On 02/09/2010 05:25 PM, Aurelien Jarno wrote:
> > On Wed, Feb 10, 2010 at 01:41:01AM +0300, malc wrote:
> >    
> > > On Tue, 9 Feb 2010, Natalia Portillo wrote:
> > > 
> > >      
> > > > Xenix is currently working (when copied from real hardware).
> > > > As well Interactive UNIX and some other non-DOS from 8086 and 286 era.
> > > > 
> > > > I'm not really sure that operating systems (specially the 8086 ones that
> > > > do
> > > > mmu functions in software) will be happy with the PCI bus present.
> > > > 
> > > > Same for first 386 operating systems (OS/2 2, UNIX, Xenix, so on).
> > > >        
> > > News to me that OS/2 worked.. I don't quite remember which version
> > > someone (you?) asked me to try on IRC a few years back, but it definitely
> > > didn't work.
> > > 
> > >      
> > I have got OS/2 warp working under QEMU a few years ago. I couldn't give
> > more details though, I just remember it was working nicely.
> >    
> 
> The problem with isapc is that it uses a different chipset (or rather, doesn't
> use a PCI chipset).  I think the current thinking with target-i386 config
> files is that while you should be able to customize the system, some of the
> core bits would always be there.  For instance, the PCI chipset, the APIC,
> etc.  These things are very tied to a platform.

APIC is almost as good as useless without ACPI and we have a switch to
disable that.

> 
> Firmware is really hard to implement if you have to deal with supporting
> multiple chipsets.
> 
> Also, if we don't have a workload that actually needs isapc, that suggests
> that there's no real way to test that isapc doesn't have non-ISA things creep
> into it.
> 
> Given that, I'm inclined to suggest that we mark isapc as deprecated, give
> people some time to comment on it, and then provided that we still don't think
> it's necessary, change isapc to simply use isa devices while still using a PCI
> chipset.

Not to comment, to give hard evidence that something is working with isapc
and doesn't otherwise, in which case it must stay.

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] Seabios dislikes -M isapc

[Anthony Liguori]

On 02/09/2010 06:27 PM, malc wrote:
> APIC is almost as good as useless without ACPI and we have a switch to
> disable that.
>    

Which is another thing that I'm not sure it all that useful to have.

>> Firmware is really hard to implement if you have to deal with supporting
>> multiple chipsets.
>>
>> Also, if we don't have a workload that actually needs isapc, that suggests
>> that there's no real way to test that isapc doesn't have non-ISA things creep
>> into it.
>>
>> Given that, I'm inclined to suggest that we mark isapc as deprecated, give
>> people some time to comment on it, and then provided that we still don't think
>> it's necessary, change isapc to simply use isa devices while still using a PCI
>> chipset.
>>      
> Not to comment, to give hard evidence that something is working with isapc
> and doesn't otherwise, in which case it must stay.
>    

Yes.  If someone can produce a workload that requires isapc[1], I'm all 
for continuing to support it.

[1] Very specifically, I mean requires -M isapc to only emulate an ISA 
bus and not emulate an ISA bus via a bridge in the PIIX chipset.  We 
will always need an -M isapc that only uses ISA devices instead of PCI 
devices.  However, if we can use a PCI chipset in -M isapc, we can 
express the differences entirely via qdev.

Regards,

Anthony Liguori

Re: [Qemu-devel] Seabios dislikes -M isapc

[Jamie Lokier]

Anthony Liguori wrote:
> On 02/09/2010 06:27 PM, malc wrote:
> >APIC is almost as good as useless without ACPI and we have a switch to
> >disable that.
> >   
> 
> Which is another thing that I'm not sure it all that useful to have.
> 
> >>Firmware is really hard to implement if you have to deal with supporting
> >>multiple chipsets.
> >>
> >>Also, if we don't have a workload that actually needs isapc, that suggests
> >>that there's no real way to test that isapc doesn't have non-ISA things 
> >>creep
> >>into it.
> >>
> >>Given that, I'm inclined to suggest that we mark isapc as deprecated, give
> >>people some time to comment on it, and then provided that we still don't 
> >>think
> >>it's necessary, change isapc to simply use isa devices while still using 
> >>a PCI
> >>chipset.
> >>     
> >Not to comment, to give hard evidence that something is working with isapc
> >and doesn't otherwise, in which case it must stay.
> >   
> 
> Yes.  If someone can produce a workload that requires isapc[1], I'm all 
> for continuing to support it.
> 
> [1] Very specifically, I mean requires -M isapc to only emulate an ISA 
> bus and not emulate an ISA bus via a bridge in the PIIX chipset.  We 
> will always need an -M isapc that only uses ISA devices instead of PCI 
> devices.  However, if we can use a PCI chipset in -M isapc, we can 
> express the differences entirely via qdev.

If it emulated a PCI chipset _but_ ignored any access to the chipset
registers after the BIOS has initialised whatever it will (by
unmapping the registers but keeping the chipset device running), that
would look an awful lot like a real ISA PC at that point, wouldn't it?

-- Jamie

Re: [Qemu-devel] Seabios dislikes -M isapc

[Anthony Liguori]

On 02/11/2010 05:51 PM, Jamie Lokier wrote:
>
> If it emulated a PCI chipset _but_ ignored any access to the chipset
> registers after the BIOS has initialised whatever it will (by
> unmapping the registers but keeping the chipset device running), that
> would look an awful lot like a real ISA PC at that point, wouldn't it?
>    

If there's nothing that actually cares if there's a PCI chipset, then 
what's the point?

Regards,

Anthony Liguori

> -- Jamie
>    

Re: [Qemu-devel] Seabios dislikes -M isapc

[Natalia Portillo]

2.x was "working", 3.x simply does not install, the rest need to check.

1.x NEVER worked, ironically, it is working in VirtualPC, the one that  
was the most OS/2 incompatible emulator/simulator.

El 09/02/2010, a las 22:41, malc escribió:

> On Tue, 9 Feb 2010, Natalia Portillo wrote:
>
>> Xenix is currently working (when copied from real hardware).
>> As well Interactive UNIX and some other non-DOS from 8086 and 286  
>> era.
>>
>> I'm not really sure that operating systems (specially the 8086 ones  
>> that do
>> mmu functions in software) will be happy with the PCI bus present.
>>
>> Same for first 386 operating systems (OS/2 2, UNIX, Xenix, so on).
>
> News to me that OS/2 worked.. I don't quite remember which version
> someone (you?) asked me to try on IRC a few years back, but it  
> definitely
> didn't work.
>
> [..snip..]
>
> -- 
> mailto:av1474@comtv.ru

Re: [Qemu-devel] Seabios dislikes -M isapc

[malc]

On Tue, 9 Feb 2010, Natalia Portillo wrote:

> 2.x was "working", 3.x simply does not install, the rest need to check.
> 
> 1.x NEVER worked, ironically, it is working in VirtualPC, the one that was the
> most OS/2 incompatible emulator/simulator.

Is there someplace one can get those from (1.x, 2.x)?

[..snip..]

P.S. http://www.boblycat.org/~malc/qemu-shots/qemu-os2-vga-bug.png
     It's probably merlin's installation..

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] Seabios dislikes -M isapc

[malc]

On Tue, 9 Feb 2010, Anthony Liguori wrote:

> On 02/08/2010 04:17 AM, Jan Kiszka wrote:
> > Hi,
> > 
> > Seabios seems to have some assumptions built in that break when -M isapc
> > is selected. Is this supposed to work or is isapc about to die?
> >    
> 
> Does anything actually require isapc?
> 
> pc has an ISA bridge, a PCI VGA device is still VGA/SVGA compliant.
> 
> Would anything break if we just dropped isapc?
> 

I would have loved to say that all hell breaks loose when we disable
isapc, but, truth be told, i've never explicitly enabled it.

-- 
mailto:av1474@comtv.ru