[Qemu-devel] POST failure (loop) with isapc and seabios

[Qemu-devel] POST failure (loop) with isapc and seabios

[Sebastian Herbszt]

i386-softmmu/qemu -M isapc -bios pc-bios/bios.bin

(qemu) info cpus
* CPU #0: pc=0x000f3852
(qemu) x/20i $pc
0x000f3852:  mov    0xfd408,%eax
0x000f3857:  cmp    %eax,%edx
0x000f3859:  jne    0xf3852
0x000f385b:  mov    %ecx,0x10000
0x000f3861:  mov    %ebx,0x10004
0x000f3867:  xor    %eax,%eax
0x000f3869:  cmpl   $0x0,0xf78ec
0x000f3870:  je     0xf3897
0x000f3872:  mov    $0x510,%edx
0x000f3877:  mov    $0xf,%eax
0x000f387c:  out    %ax,(%dx)
0x000f387e:  mov    $0x11,%dl
0x000f3880:  in     (%dx),%al
0x000f3881:  mov    %al,0xe4(%esp)
0x000f3888:  in     (%dx),%al
0x000f3889:  mov    %al,0xe5(%esp)
0x000f3890:  mov    0xe4(%esp),%eax
0x000f3897:  movzwl %ax,%eax
0x000f389a:  mov    %eax,0xfd40c
0x000f389f:  test   %eax,%eax

Could be smp_probe():

    // Wait for other CPUs to process the SIPI.
    if (CONFIG_COREBOOT) {
        msleep(10);
    } else {
        u8 cmos_smp_count = inb_cmos(CMOS_BIOS_SMP_COUNT);
        while (cmos_smp_count + 1 != readl(&CountCPUs))
             ;
    }

Works with pcbios.bin.

- Sebastian

[Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Kevin O'Connor]

On Thu, Nov 19, 2009 at 10:30:20PM +0100, Sebastian Herbszt wrote:
> i386-softmmu/qemu -M isapc -bios pc-bios/bios.bin

Thanks for reporting this.

After compiling seabios with CONFIG_DEBUG_SERIAL set in src/config.h
and running:

qemu -M isapc -serial file:foo

I see:

Unable to unlock ram - bridge not found

SeaBIOS stores global variables in the f-segment.  This greatly
simplifies the code, but it does require the ability to write to the
f-segment.  Since the f-segment can't be unlocked in "isapc" mode, the
boot fails.

I'm not really sure what to do about this.  Maybe some kind of non-pci
method of unlocking the f-segment could be implemented.

Anthony, what do you think?

-Kevin

[Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Sebastian Herbszt]

Kevin O'Connor wrote:
> On Thu, Nov 19, 2009 at 10:30:20PM +0100, Sebastian Herbszt wrote:
>> i386-softmmu/qemu -M isapc -bios pc-bios/bios.bin
> 
> Thanks for reporting this.
> 
> After compiling seabios with CONFIG_DEBUG_SERIAL set in src/config.h
> and running:
> 
> qemu -M isapc -serial file:foo
> 
> I see:
> 
> Unable to unlock ram - bridge not found
> 
> SeaBIOS stores global variables in the f-segment.  This greatly
> simplifies the code, but it does require the ability to write to the
> f-segment.  Since the f-segment can't be unlocked in "isapc" mode, the
> boot fails.
> 
> I'm not really sure what to do about this.  Maybe some kind of non-pci
> method of unlocking the f-segment could be implemented.

Could try to emulate the Intel 82359 DRAM Controller in qemu or keep
using the Bochs BIOS for isapc.

- Sebastian

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Fri, Nov 20, 2009 at 05:51:13PM -0500, Kevin O'Connor wrote:
> On Thu, Nov 19, 2009 at 10:30:20PM +0100, Sebastian Herbszt wrote:
> > i386-softmmu/qemu -M isapc -bios pc-bios/bios.bin
> 
> Thanks for reporting this.
> 
> After compiling seabios with CONFIG_DEBUG_SERIAL set in src/config.h
> and running:
> 
> qemu -M isapc -serial file:foo
> 
> I see:
> 
> Unable to unlock ram - bridge not found
> 
> SeaBIOS stores global variables in the f-segment.  This greatly
> simplifies the code, but it does require the ability to write to the
> f-segment.  Since the f-segment can't be unlocked in "isapc" mode, the
> boot fails.
> 
> I'm not really sure what to do about this.  Maybe some kind of non-pci
> method of unlocking the f-segment could be implemented.
> 
> Anthony, what do you think?
> 
May be make qemu to map it writable if isapc is specified.

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Sebastian Herbszt]

Gleb Natapov wrote:
> On Fri, Nov 20, 2009 at 05:51:13PM -0500, Kevin O'Connor wrote:
>> On Thu, Nov 19, 2009 at 10:30:20PM +0100, Sebastian Herbszt wrote:
>> > i386-softmmu/qemu -M isapc -bios pc-bios/bios.bin
>> 
>> Thanks for reporting this.
>> 
>> After compiling seabios with CONFIG_DEBUG_SERIAL set in src/config.h
>> and running:
>> 
>> qemu -M isapc -serial file:foo
>> 
>> I see:
>> 
>> Unable to unlock ram - bridge not found
>> 
>> SeaBIOS stores global variables in the f-segment.  This greatly
>> simplifies the code, but it does require the ability to write to the
>> f-segment.  Since the f-segment can't be unlocked in "isapc" mode, the
>> boot fails.
>> 
>> I'm not really sure what to do about this.  Maybe some kind of non-pci
>> method of unlocking the f-segment could be implemented.
>> 
>> Anthony, what do you think?
>> 
> May be make qemu to map it writable if isapc is specified.

I don't think keeping the segment writable after POST is a good idea.

- Sebastian

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Sun, Nov 22, 2009 at 04:07:56PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Fri, Nov 20, 2009 at 05:51:13PM -0500, Kevin O'Connor wrote:
> >>On Thu, Nov 19, 2009 at 10:30:20PM +0100, Sebastian Herbszt wrote:
> >>> i386-softmmu/qemu -M isapc -bios pc-bios/bios.bin
> >>
> >>Thanks for reporting this.
> >>
> >>After compiling seabios with CONFIG_DEBUG_SERIAL set in src/config.h
> >>and running:
> >>
> >>qemu -M isapc -serial file:foo
> >>
> >>I see:
> >>
> >>Unable to unlock ram - bridge not found
> >>
> >>SeaBIOS stores global variables in the f-segment.  This greatly
> >>simplifies the code, but it does require the ability to write to the
> >>f-segment.  Since the f-segment can't be unlocked in "isapc" mode, the
> >>boot fails.
> >>
> >>I'm not really sure what to do about this.  Maybe some kind of non-pci
> >>method of unlocking the f-segment could be implemented.
> >>
> >>Anthony, what do you think?
> >>
> >May be make qemu to map it writable if isapc is specified.
> 
> I don't think keeping the segment writable after POST is a good idea.
> 
Isn't it writable now after POST with pcipc? Why this is not a good
idea?

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Sebastian Herbszt]

Gleb Natapov wrote:
> On Sun, Nov 22, 2009 at 04:07:56PM +0100, Sebastian Herbszt wrote:
>> Gleb Natapov wrote:
>> >May be make qemu to map it writable if isapc is specified.
>> 
>> I don't think keeping the segment writable after POST is a good idea.
>> 
> Isn't it writable now after POST with pcipc? Why this is not a good
> idea?

seabios got this in src/post.c:
    // Allow writes to modify bios area (0xf0000)
    make_bios_writable();
    // Perform main setup code.
    post();
...
    // Write protect bios memory.
    make_bios_readonly();

The names and comments are kind of misleading since make_bios_writable()
and make_bios_readonly() both seem to also affect the option roms.

Bad things could happen if someone modifies the BIOS because it's unprotected
(e.g. VM crash).

- Sebastian

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Sun, Nov 22, 2009 at 04:07:56PM +0100, Sebastian Herbszt wrote:
> >>Gleb Natapov wrote:
> >>>May be make qemu to map it writable if isapc is specified.
> >>
> >>I don't think keeping the segment writable after POST is a good idea.
> >>
> >Isn't it writable now after POST with pcipc? Why this is not a good
> >idea?
> 
> seabios got this in src/post.c:
>    // Allow writes to modify bios area (0xf0000)
>    make_bios_writable();
>    // Perform main setup code.
>    post();
> ...
>    // Write protect bios memory.
>    make_bios_readonly();
Hmmm. How is tpr patching works then? It relies on ability of a guest to
write into BIOS memory region. Need to retest if it actually works I
guess.

> 
> The names and comments are kind of misleading since make_bios_writable()
> and make_bios_readonly() both seem to also affect the option roms.
> 
> Bad things could happen if someone modifies the BIOS because it's unprotected
> (e.g. VM crash).
> 
BIOS is reloaded during VM reset.

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Kevin O'Connor]

On Sun, Nov 22, 2009 at 05:10:53PM +0200, Gleb Natapov wrote:
> On Sun, Nov 22, 2009 at 04:07:56PM +0100, Sebastian Herbszt wrote:
> > Gleb Natapov wrote:
> > >May be make qemu to map it writable if isapc is specified.
> > 
> > I don't think keeping the segment writable after POST is a good idea.
> > 
> Isn't it writable now after POST with pcipc? Why this is not a good
> idea?

SeaBIOS and bochs bios will make the f-segment readonly at the end of
post.  See make_bios_readonly() in src/shadow.c.

SeaBIOS' ram locking requires the same pci access that the unlocking
needs, so if qemu made the f-segment writable on isa then it would
remain writable past POST.

-Kevin

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Kevin O'Connor]

On Sun, Nov 22, 2009 at 05:38:09PM +0200, Gleb Natapov wrote:
> On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
> >    // Write protect bios memory.
> >    make_bios_readonly();
> Hmmm. How is tpr patching works then? It relies on ability of a guest to
> write into BIOS memory region. Need to retest if it actually works I
> guess.

The last time I looked, the TPR patching backend forced the "vapic"
pages to be writable (effectively overriding the bios decision to make
it readonly).

> > Bad things could happen if someone modifies the BIOS because it's unprotected
> > (e.g. VM crash).

I'm not sure why modification of the BIOS would cause a VM crash.  If
this is true, then a malicious guest could unlock the ram and write to
it for the same effect.

-Kevin

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Sebastian Herbszt]

Gleb Natapov wrote:
> On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
>> 
>> Bad things could happen if someone modifies the BIOS because it's unprotected
>> (e.g. VM crash).
>> 
> BIOS is reloaded during VM reset.

The BIOS is not reloaded - tested with "reboot" on Linux and system_reset in monitor.

- Sebastian

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Sebastian Herbszt]

Kevin O'Connor wrote:
>> On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
>> > Bad things could happen if someone modifies the BIOS because it's unprotected
>> > (e.g. VM crash).
> 
> I'm not sure why modification of the BIOS would cause a VM crash.  If
> this is true, then a malicious guest could unlock the ram and write to
> it for the same effect.

On Linux only root can unlock the memory. If the memory is unlocked and
a user manages to overwrite the BIOS, the VM will crash on next "reboot"
or system_reset. If the OS is using the BIOS interfaces more often, e.g. INT 13h,
bad things could happen earlier.

- Sebastian

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Sebastian Herbszt]

Kevin O'Connor wrote:
> On Sun, Nov 22, 2009 at 05:38:09PM +0200, Gleb Natapov wrote:
>> On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
>> >    // Write protect bios memory.
>> >    make_bios_readonly();
>> Hmmm. How is tpr patching works then? It relies on ability of a guest to
>> write into BIOS memory region. Need to retest if it actually works I
>> guess.
> 
> The last time I looked, the TPR patching backend forced the "vapic"
> pages to be writable (effectively overriding the bios decision to make
> it readonly).

Does the TPR thing have to live in the optionrom/bios space or can it be moved
somewhere else like just below 4GB (some other kvm stuff is already there) ?

- Sebastian

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Sun, Nov 22, 2009 at 09:01:45PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
> >>
> >>Bad things could happen if someone modifies the BIOS because it's unprotected
> >>(e.g. VM crash).
> >>
> >BIOS is reloaded during VM reset.
> 
> The BIOS is not reloaded - tested with "reboot" on Linux and system_reset in monitor.
> 
Looks like a bug. Tested with latest QEMU version I assume?

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Sun, Nov 22, 2009 at 11:04:34PM +0100, Sebastian Herbszt wrote:
> Kevin O'Connor wrote:
> >On Sun, Nov 22, 2009 at 05:38:09PM +0200, Gleb Natapov wrote:
> >>On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
> >>>    // Write protect bios memory.
> >>>    make_bios_readonly();
> >>Hmmm. How is tpr patching works then? It relies on ability of a guest to
> >>write into BIOS memory region. Need to retest if it actually works I
> >>guess.
> >
> >The last time I looked, the TPR patching backend forced the "vapic"
> >pages to be writable (effectively overriding the bios decision to make
> >it readonly).
> 
> Does the TPR thing have to live in the optionrom/bios space or can it be moved
> somewhere else like just below 4GB (some other kvm stuff is already there) ?
> 
It needs to be in a memory that is mapped by WindowsXP kernel (but not
used by it). WindowsXP maps optionrom/bios memory, but AFAIK not e820 memory.

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Sun, Nov 22, 2009 at 10:38:42AM -0500, Kevin O'Connor wrote:
> On Sun, Nov 22, 2009 at 05:10:53PM +0200, Gleb Natapov wrote:
> > On Sun, Nov 22, 2009 at 04:07:56PM +0100, Sebastian Herbszt wrote:
> > > Gleb Natapov wrote:
> > > >May be make qemu to map it writable if isapc is specified.
> > > 
> > > I don't think keeping the segment writable after POST is a good idea.
> > > 
> > Isn't it writable now after POST with pcipc? Why this is not a good
> > idea?
> 
> SeaBIOS and bochs bios will make the f-segment readonly at the end of
> post.  See make_bios_readonly() in src/shadow.c.
> 
I see SeaBIOS does this, but I don't see where bochs bios does this.

> SeaBIOS' ram locking requires the same pci access that the unlocking
> needs, so if qemu made the f-segment writable on isa then it would
> remain writable past POST.
> 
> -Kevin

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Sun, Nov 22, 2009 at 12:40:24PM -0500, Kevin O'Connor wrote:
> On Sun, Nov 22, 2009 at 05:38:09PM +0200, Gleb Natapov wrote:
> > On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
> > >    // Write protect bios memory.
> > >    make_bios_readonly();
> > Hmmm. How is tpr patching works then? It relies on ability of a guest to
> > write into BIOS memory region. Need to retest if it actually works I
> > guess.
> 
> The last time I looked, the TPR patching backend forced the "vapic"
> pages to be writable (effectively overriding the bios decision to make
> it readonly).
> 
Don't see where it does this. But now I recall that KVM doesn't support
ROM slots, so BIOS area is always writable under KVM.

> > > Bad things could happen if someone modifies the BIOS because it's unprotected
> > > (e.g. VM crash).
> 
> I'm not sure why modification of the BIOS would cause a VM crash.  If
> this is true, then a malicious guest could unlock the ram and write to
> it for the same effect.
> 
> -Kevin

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Sebastian Herbszt]

Gleb Natapov wrote:
> On Sun, Nov 22, 2009 at 10:38:42AM -0500, Kevin O'Connor wrote:
>> On Sun, Nov 22, 2009 at 05:10:53PM +0200, Gleb Natapov wrote:
>> > On Sun, Nov 22, 2009 at 04:07:56PM +0100, Sebastian Herbszt wrote:
>> > > Gleb Natapov wrote:
>> > > >May be make qemu to map it writable if isapc is specified.
>> > > 
>> > > I don't think keeping the segment writable after POST is a good idea.
>> > > 
>> > Isn't it writable now after POST with pcipc? Why this is not a good
>> > idea?
>> 
>> SeaBIOS and bochs bios will make the f-segment readonly at the end of
>> post.  See make_bios_readonly() in src/shadow.c.
>> 
> I see SeaBIOS does this, but I don't see where bochs bios does this.

bios_lock_shadow_ram() in rombio32.c.

- Sebastian

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Mon, Nov 23, 2009 at 06:57:47PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Sun, Nov 22, 2009 at 10:38:42AM -0500, Kevin O'Connor wrote:
> >>On Sun, Nov 22, 2009 at 05:10:53PM +0200, Gleb Natapov wrote:
> >>> On Sun, Nov 22, 2009 at 04:07:56PM +0100, Sebastian Herbszt wrote:
> >>> > Gleb Natapov wrote:
> >>> > >May be make qemu to map it writable if isapc is specified.
> >>> > > > I don't think keeping the segment writable after POST is
> >>a good idea.
> >>> > > Isn't it writable now after POST with pcipc? Why this is
> >>not a good
> >>> idea?
> >>
> >>SeaBIOS and bochs bios will make the f-segment readonly at the end of
> >>post.  See make_bios_readonly() in src/shadow.c.
> >>
> >I see SeaBIOS does this, but I don't see where bochs bios does this.
> 
> bios_lock_shadow_ram() in rombio32.c.
> 
This functions is called far from end of the post and it doesn't change
mapping to be read only as far as I can see.

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Sebastian Herbszt]

Gleb Natapov wrote:
> On Mon, Nov 23, 2009 at 06:57:47PM +0100, Sebastian Herbszt wrote:
>> Gleb Natapov wrote:
>> >On Sun, Nov 22, 2009 at 10:38:42AM -0500, Kevin O'Connor wrote:
>> >>On Sun, Nov 22, 2009 at 05:10:53PM +0200, Gleb Natapov wrote:
>> >>> On Sun, Nov 22, 2009 at 04:07:56PM +0100, Sebastian Herbszt wrote:
>> >>> > Gleb Natapov wrote:
>> >>> > >May be make qemu to map it writable if isapc is specified.
>> >>> > > > I don't think keeping the segment writable after POST is
>> >>a good idea.
>> >>> > > Isn't it writable now after POST with pcipc? Why this is
>> >>not a good
>> >>> idea?
>> >>
>> >>SeaBIOS and bochs bios will make the f-segment readonly at the end of
>> >>post.  See make_bios_readonly() in src/shadow.c.
>> >>
>> >I see SeaBIOS does this, but I don't see where bochs bios does this.
>> 
>> bios_lock_shadow_ram() in rombio32.c.
>> 
> This functions is called far from end of the post and it doesn't change
> mapping to be read only as far as I can see.

Bochs bios only keeps the memory writable inside rombios32. bios_lock_shadow_ram()
clears the upper 4 bits (7:4) and then sets bit 4 to 1 making the value of the bit pair 5:4
(pci register 0x59) 01 being read only.

- Sebastian

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Mon, Nov 23, 2009 at 08:12:32PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Mon, Nov 23, 2009 at 06:57:47PM +0100, Sebastian Herbszt wrote:
> >>Gleb Natapov wrote:
> >>>On Sun, Nov 22, 2009 at 10:38:42AM -0500, Kevin O'Connor wrote:
> >>>>On Sun, Nov 22, 2009 at 05:10:53PM +0200, Gleb Natapov wrote:
> >>>>> On Sun, Nov 22, 2009 at 04:07:56PM +0100, Sebastian Herbszt wrote:
> >>>>> > Gleb Natapov wrote:
> >>>>> > >May be make qemu to map it writable if isapc is specified.
> >>>>> > > > I don't think keeping the segment writable after POST is
> >>>>a good idea.
> >>>>> > > Isn't it writable now after POST with pcipc? Why this is
> >>>>not a good
> >>>>> idea?
> >>>>
> >>>>SeaBIOS and bochs bios will make the f-segment readonly at the end of
> >>>>post.  See make_bios_readonly() in src/shadow.c.
> >>>>
> >>>I see SeaBIOS does this, but I don't see where bochs bios does this.
> >>
> >>bios_lock_shadow_ram() in rombio32.c.
> >>
> >This functions is called far from end of the post and it doesn't change
> >mapping to be read only as far as I can see.
> 
> Bochs bios only keeps the memory writable inside rombios32. bios_lock_shadow_ram()
> clears the upper 4 bits (7:4) and then sets bit 4 to 1 making the value of the bit pair 5:4
> (pci register 0x59) 01 being read only.
> 
Ah correct. I missed that read/write status is in bits 7:4 not 0:3.

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Sebastian Herbszt]

Gleb Natapov wrote:
> On Sun, Nov 22, 2009 at 09:01:45PM +0100, Sebastian Herbszt wrote:
>> Gleb Natapov wrote:
>> >On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
>> >>
>> >>Bad things could happen if someone modifies the BIOS because it's unprotected
>> >>(e.g. VM crash).
>> >>
>> >BIOS is reloaded during VM reset.
>> 
>> The BIOS is not reloaded - tested with "reboot" on Linux and system_reset in monitor.
>> 
> Looks like a bug. Tested with latest QEMU version I assume?

Tested with v0.11.0-rc0-1677-gf165b53. Where do you suspect a bug? In the behaviour
on "reboot" or system_reset? I think it depends wheter it's a software or hardware reset.

- Sebastian

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Mon, Nov 23, 2009 at 08:19:54PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Sun, Nov 22, 2009 at 09:01:45PM +0100, Sebastian Herbszt wrote:
> >>Gleb Natapov wrote:
> >>>On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
> >>>>
> >>>>Bad things could happen if someone modifies the BIOS because it's unprotected
> >>>>(e.g. VM crash).
> >>>>
> >>>BIOS is reloaded during VM reset.
> >>
> >>The BIOS is not reloaded - tested with "reboot" on Linux and system_reset in monitor.
> >>
> >Looks like a bug. Tested with latest QEMU version I assume?
> 
> Tested with v0.11.0-rc0-1677-gf165b53. Where do you suspect a bug? In the behaviour
> on "reboot" or system_reset? I think it depends wheter it's a software or hardware reset.
> 
The bug is that BIOS rom is not reloaded on hardware reset (what do you
call software reset?). Can you retest with latest git?

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Sebastian Herbszt]

Gleb Natapov wrote:
> On Mon, Nov 23, 2009 at 08:19:54PM +0100, Sebastian Herbszt wrote:
>> Gleb Natapov wrote:
>> >On Sun, Nov 22, 2009 at 09:01:45PM +0100, Sebastian Herbszt wrote:
>> >>Gleb Natapov wrote:
>> >>>On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
>> >>>>
>> >>>>Bad things could happen if someone modifies the BIOS because it's unprotected
>> >>>>(e.g. VM crash).
>> >>>>
>> >>>BIOS is reloaded during VM reset.
>> >>
>> >>The BIOS is not reloaded - tested with "reboot" on Linux and system_reset in monitor.
>> >>
>> >Looks like a bug. Tested with latest QEMU version I assume?
>> 
>> Tested with v0.11.0-rc0-1677-gf165b53. Where do you suspect a bug? In the behaviour
>> on "reboot" or system_reset? I think it depends wheter it's a software or hardware reset.
>> 
> The bug is that BIOS rom is not reloaded on hardware reset (what do you
> call software reset?). Can you retest with latest git?

Same with v0.11.0-rc0-1699-gb0293e5.
Bochs has the notion of BX_RESET_SOFTWARE and BX_RESET_HARDWARE. Those
two describe the source of the reset and the hardware, in most cases just the cpu, is reset
differently depending on the source (e.g. hardware reset / power on vs. INIT#). I think this
behaviour is also described in the 440fx spec (chapter "4.5.3 SYSTEM RESET").

If the monitor command "system_reset" is supposed to be the equivalent of pushing the reset
button of the box, then the bios should be reloaded (i think, not entirely sure what the pin is
wired to). But the bios should not be reloaded if the OS just jumps to the bios reset code.

- Sebastian

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Mon, Nov 23, 2009 at 10:30:56PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Mon, Nov 23, 2009 at 08:19:54PM +0100, Sebastian Herbszt wrote:
> >>Gleb Natapov wrote:
> >>>On Sun, Nov 22, 2009 at 09:01:45PM +0100, Sebastian Herbszt wrote:
> >>>>Gleb Natapov wrote:
> >>>>>On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
> >>>>>>
> >>>>>>Bad things could happen if someone modifies the BIOS because it's unprotected
> >>>>>>(e.g. VM crash).
> >>>>>>
> >>>>>BIOS is reloaded during VM reset.
> >>>>
> >>>>The BIOS is not reloaded - tested with "reboot" on Linux and system_reset in monitor.
> >>>>
> >>>Looks like a bug. Tested with latest QEMU version I assume?
> >>
> >>Tested with v0.11.0-rc0-1677-gf165b53. Where do you suspect a bug? In the behaviour
> >>on "reboot" or system_reset? I think it depends wheter it's a software or hardware reset.
> >>
> >The bug is that BIOS rom is not reloaded on hardware reset (what do you
> >call software reset?). Can you retest with latest git?
> 
> Same with v0.11.0-rc0-1699-gb0293e5.
> Bochs has the notion of BX_RESET_SOFTWARE and BX_RESET_HARDWARE. Those
> two describe the source of the reset and the hardware, in most cases just the cpu, is reset
> differently depending on the source (e.g. hardware reset / power on vs. INIT#). I think this
> behaviour is also described in the 440fx spec (chapter "4.5.3 SYSTEM RESET").
> 
> If the monitor command "system_reset" is supposed to be the equivalent of pushing the reset
> button of the box, then the bios should be reloaded (i think, not entirely sure what the pin is
> wired to). But the bios should not be reloaded if the OS just jumps to the bios reset code.
> 
Correct, but modern OSes never jump to the bios reset code. They use
ACPI reset, kbd reset or triple fault to do reset. All of those generate
exactly the same kind of reset as "system_reset" monitor command.

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Jamie Lokier]

Gleb Natapov wrote:
> On Mon, Nov 23, 2009 at 10:30:56PM +0100, Sebastian Herbszt wrote:
> > Gleb Natapov wrote:
> > >On Mon, Nov 23, 2009 at 08:19:54PM +0100, Sebastian Herbszt wrote:
> > >>Gleb Natapov wrote:
> > >>>On Sun, Nov 22, 2009 at 09:01:45PM +0100, Sebastian Herbszt wrote:
> > >>>>Gleb Natapov wrote:
> > >>>>>On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
> > >>>>>>
> > >>>>>>Bad things could happen if someone modifies the BIOS because it's unprotected
> > >>>>>>(e.g. VM crash).
> > >>>>>>
> > >>>>>BIOS is reloaded during VM reset.
> > >>>>
> > >>>>The BIOS is not reloaded - tested with "reboot" on Linux and system_reset in monitor.
> > >>>>
> > >>>Looks like a bug. Tested with latest QEMU version I assume?
> > >>
> > >>Tested with v0.11.0-rc0-1677-gf165b53. Where do you suspect a bug? In the behaviour
> > >>on "reboot" or system_reset? I think it depends wheter it's a software or hardware reset.
> > >>
> > >The bug is that BIOS rom is not reloaded on hardware reset (what do you
> > >call software reset?). Can you retest with latest git?
> > 
> > Same with v0.11.0-rc0-1699-gb0293e5.
> > Bochs has the notion of BX_RESET_SOFTWARE and BX_RESET_HARDWARE. Those
> > two describe the source of the reset and the hardware, in most cases just the cpu, is reset
> > differently depending on the source (e.g. hardware reset / power on vs. INIT#). I think this
> > behaviour is also described in the 440fx spec (chapter "4.5.3 SYSTEM RESET").
> > 
> > If the monitor command "system_reset" is supposed to be the equivalent of pushing the reset
> > button of the box, then the bios should be reloaded (i think, not entirely sure what the pin is
> > wired to). But the bios should not be reloaded if the OS just jumps to the bios reset code.
> > 
> Correct, but modern OSes never jump to the bios reset code. They use
> ACPI reset, kbd reset or triple fault to do reset. All of those generate
> exactly the same kind of reset as "system_reset" monitor command.

Modern OSes don't (though Linux still has the option reboot=bios which
jumps to the BIOS reset code, because that's needed on some PCs!).

But QEMU is used to run old OSes too.

-- Jamie

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Tue, Nov 24, 2009 at 02:38:12PM +0000, Jamie Lokier wrote:
> Gleb Natapov wrote:
> > On Mon, Nov 23, 2009 at 10:30:56PM +0100, Sebastian Herbszt wrote:
> > > Gleb Natapov wrote:
> > > >On Mon, Nov 23, 2009 at 08:19:54PM +0100, Sebastian Herbszt wrote:
> > > >>Gleb Natapov wrote:
> > > >>>On Sun, Nov 22, 2009 at 09:01:45PM +0100, Sebastian Herbszt wrote:
> > > >>>>Gleb Natapov wrote:
> > > >>>>>On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
> > > >>>>>>
> > > >>>>>>Bad things could happen if someone modifies the BIOS because it's unprotected
> > > >>>>>>(e.g. VM crash).
> > > >>>>>>
> > > >>>>>BIOS is reloaded during VM reset.
> > > >>>>
> > > >>>>The BIOS is not reloaded - tested with "reboot" on Linux and system_reset in monitor.
> > > >>>>
> > > >>>Looks like a bug. Tested with latest QEMU version I assume?
> > > >>
> > > >>Tested with v0.11.0-rc0-1677-gf165b53. Where do you suspect a bug? In the behaviour
> > > >>on "reboot" or system_reset? I think it depends wheter it's a software or hardware reset.
> > > >>
> > > >The bug is that BIOS rom is not reloaded on hardware reset (what do you
> > > >call software reset?). Can you retest with latest git?
> > > 
> > > Same with v0.11.0-rc0-1699-gb0293e5.
> > > Bochs has the notion of BX_RESET_SOFTWARE and BX_RESET_HARDWARE. Those
> > > two describe the source of the reset and the hardware, in most cases just the cpu, is reset
> > > differently depending on the source (e.g. hardware reset / power on vs. INIT#). I think this
> > > behaviour is also described in the 440fx spec (chapter "4.5.3 SYSTEM RESET").
> > > 
> > > If the monitor command "system_reset" is supposed to be the equivalent of pushing the reset
> > > button of the box, then the bios should be reloaded (i think, not entirely sure what the pin is
> > > wired to). But the bios should not be reloaded if the OS just jumps to the bios reset code.
> > > 
> > Correct, but modern OSes never jump to the bios reset code. They use
> > ACPI reset, kbd reset or triple fault to do reset. All of those generate
> > exactly the same kind of reset as "system_reset" monitor command.
> 
> Modern OSes don't (though Linux still has the option reboot=bios which
> jumps to the BIOS reset code, because that's needed on some PCs!).
> 
> But QEMU is used to run old OSes too.
> 
That's OK. I don't expect BIOS to be reloaded if OS restart by jumping
to BIOS reset code.

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Sebastian Herbszt]

Gleb Natapov wrote:
> On Mon, Nov 23, 2009 at 10:30:56PM +0100, Sebastian Herbszt wrote:
>> Gleb Natapov wrote:
>> >On Mon, Nov 23, 2009 at 08:19:54PM +0100, Sebastian Herbszt wrote:
>> >>Gleb Natapov wrote:
>> >>>On Sun, Nov 22, 2009 at 09:01:45PM +0100, Sebastian Herbszt wrote:
>> >>>>Gleb Natapov wrote:
>> >>>>>On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
>> >>>>>>
>> >>>>>>Bad things could happen if someone modifies the BIOS because it's unprotected
>> >>>>>>(e.g. VM crash).
>> >>>>>>
>> >>>>>BIOS is reloaded during VM reset.
>> >>>>
>> >>>>The BIOS is not reloaded - tested with "reboot" on Linux and system_reset in monitor.
>> >>>>
>> >>>Looks like a bug. Tested with latest QEMU version I assume?
>> >>
>> >>Tested with v0.11.0-rc0-1677-gf165b53. Where do you suspect a bug? In the behaviour
>> >>on "reboot" or system_reset? I think it depends wheter it's a software or hardware reset.
>> >>
>> >The bug is that BIOS rom is not reloaded on hardware reset (what do you
>> >call software reset?). Can you retest with latest git?
>> 
>> Same with v0.11.0-rc0-1699-gb0293e5.
>> Bochs has the notion of BX_RESET_SOFTWARE and BX_RESET_HARDWARE. Those
>> two describe the source of the reset and the hardware, in most cases just the cpu, is reset
>> differently depending on the source (e.g. hardware reset / power on vs. INIT#). I think this
>> behaviour is also described in the 440fx spec (chapter "4.5.3 SYSTEM RESET").
>> 
>> If the monitor command "system_reset" is supposed to be the equivalent of pushing the reset
>> button of the box, then the bios should be reloaded (i think, not entirely sure what the pin is
>> wired to). But the bios should not be reloaded if the OS just jumps to the bios reset code.
>> 
> Correct, but modern OSes never jump to the bios reset code. They use
> ACPI reset, kbd reset or triple fault to do reset. All of those generate
> exactly the same kind of reset as "system_reset" monitor command.

With the 440FX you get two sources of a hard reset - power on and i/o write to reset control register.
Tho the PMC should not be used to generate a hard reset if used with a PIIX3. You get a soft reset on
CPU shutdown bus cycle, i/o write to keyboard controller, i/o write to port 92h and i/o write to reset
control register. The latter can be used for hard and soft resets. During a hard reset the PMC sets its
configuration registers to default values. The PAM registers are set to 0 and the BIOS is accessed thru
rom and not shadow ram. On a triple fault the CPU generates the shutdown bus cycle and since the PMC
responds to it with a soft reset the BIOS is not reloaded (?). I might have missed something in some
specification tho.

- Sebastian

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Jamie Lokier]

Gleb Natapov wrote:
> > But QEMU is used to run old OSes too.
> > 
> That's OK. I don't expect BIOS to be reloaded if OS restart by jumping
> to BIOS reset code.

That's good then.

What about DOS and DOS-extender programs which do a soft reset by
triple-faulting the CPU (see Sebastian's notes on i440FX behaviour),
and asking the keyboard controller?

Both of those methods are used by DOS and DOS-extender programs to
switch from protected mode to real mode.  Keyboard controller was used
originally, but then someone figured out that triple fault can be used
(on most PCs) and is faster.

The switch to real mode is done by writing somewhere the BIOS checks,
so the BIOS just branches back to the application.

I think that may imply it has to be a "soft reset" as described by
Sebastian in the i440FX description, and I would think the BIOS must
not be reloaded.

But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard
controller method is used and the word asking for a branch back to the
application has not been set.  Because that's how a modern OS (if not
using ACPI) asks for a system reset.

Do you think the above is (a) correct, and (b) what's implemented?

Thanks,
-- Jamie

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Wed, Nov 25, 2009 at 12:27:06AM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Mon, Nov 23, 2009 at 10:30:56PM +0100, Sebastian Herbszt wrote:
> >>Gleb Natapov wrote:
> >>>On Mon, Nov 23, 2009 at 08:19:54PM +0100, Sebastian Herbszt wrote:
> >>>>Gleb Natapov wrote:
> >>>>>On Sun, Nov 22, 2009 at 09:01:45PM +0100, Sebastian Herbszt wrote:
> >>>>>>Gleb Natapov wrote:
> >>>>>>>On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
> >>>>>>>>
> >>>>>>>>Bad things could happen if someone modifies the BIOS because it's unprotected
> >>>>>>>>(e.g. VM crash).
> >>>>>>>>
> >>>>>>>BIOS is reloaded during VM reset.
> >>>>>>
> >>>>>>The BIOS is not reloaded - tested with "reboot" on Linux and system_reset in monitor.
> >>>>>>
> >>>>>Looks like a bug. Tested with latest QEMU version I assume?
> >>>>
> >>>>Tested with v0.11.0-rc0-1677-gf165b53. Where do you suspect a bug? In the behaviour
> >>>>on "reboot" or system_reset? I think it depends wheter it's a software or hardware reset.
> >>>>
> >>>The bug is that BIOS rom is not reloaded on hardware reset (what do you
> >>>call software reset?). Can you retest with latest git?
> >>
> >>Same with v0.11.0-rc0-1699-gb0293e5.
> >>Bochs has the notion of BX_RESET_SOFTWARE and BX_RESET_HARDWARE. Those
> >>two describe the source of the reset and the hardware, in most cases just the cpu, is reset
> >>differently depending on the source (e.g. hardware reset / power on vs. INIT#). I think this
> >>behaviour is also described in the 440fx spec (chapter "4.5.3 SYSTEM RESET").
> >>
> >>If the monitor command "system_reset" is supposed to be the equivalent of pushing the reset
> >>button of the box, then the bios should be reloaded (i think, not entirely sure what the pin is
> >>wired to). But the bios should not be reloaded if the OS just jumps to the bios reset code.
> >>
> >Correct, but modern OSes never jump to the bios reset code. They use
> >ACPI reset, kbd reset or triple fault to do reset. All of those generate
> >exactly the same kind of reset as "system_reset" monitor command.
> 
> With the 440FX you get two sources of a hard reset - power on and i/o write to reset control register.
> Tho the PMC should not be used to generate a hard reset if used with a PIIX3. You get a soft reset on
> CPU shutdown bus cycle, i/o write to keyboard controller, i/o write to port 92h and i/o write to reset
> control register. The latter can be used for hard and soft resets. During a hard reset the PMC sets its
> configuration registers to default values. The PAM registers are set to 0 and the BIOS is accessed thru
> rom and not shadow ram. On a triple fault the CPU generates the shutdown bus cycle and since the PMC
> responds to it with a soft reset the BIOS is not reloaded (?). I might have missed something in some
> specification tho.
> 
Nice sum up. Thanks. When I said "all of those generate exactly the same
kind of reset as "system_reset" monitor command" I meant in QEMU, not on
actual HW. QEMU has no notion of different type of resets, though it
should.

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Wed, Nov 25, 2009 at 06:09:51AM +0000, Jamie Lokier wrote:
> Gleb Natapov wrote:
> > > But QEMU is used to run old OSes too.
> > > 
> > That's OK. I don't expect BIOS to be reloaded if OS restart by jumping
> > to BIOS reset code.
> 
> That's good then.
> 
> What about DOS and DOS-extender programs which do a soft reset by
> triple-faulting the CPU (see Sebastian's notes on i440FX behaviour),
> and asking the keyboard controller?
> 
> Both of those methods are used by DOS and DOS-extender programs to
> switch from protected mode to real mode.  Keyboard controller was used
> originally, but then someone figured out that triple fault can be used
> (on most PCs) and is faster.
> 
> The switch to real mode is done by writing somewhere the BIOS checks,
> so the BIOS just branches back to the application.
> 
If offset 0x0f in CMOS contains 0x0a then BIOS jumps to address stored
in memory address 0x467.

> I think that may imply it has to be a "soft reset" as described by
> Sebastian in the i440FX description, and I would think the BIOS must
> not be reloaded.
Reading ich9 spec I see that on this chipset it is possible to configure
what kind of reset triple fault generates. Make it not very reliable. Was
this triple fault trick only needed on 286 anyway?

> 
> But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard
> controller method is used and the word asking for a branch back to the
> application has not been set.  Because that's how a modern OS (if not
> using ACPI) asks for a system reset.
> 
> Do you think the above is (a) correct, and (b) what's implemented?
> 
Do different things during reset depending on CMOS values doesn't sound
right to me. I don't know what is implemented right now. I thought that
we reload BIOS on reset.

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Kevin O'Connor]

On Wed, Nov 25, 2009 at 02:20:39PM +0200, Gleb Natapov wrote:
> On Wed, Nov 25, 2009 at 06:09:51AM +0000, Jamie Lokier wrote:
> > But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard
> > controller method is used and the word asking for a branch back to the
> > application has not been set.  Because that's how a modern OS (if not
> > using ACPI) asks for a system reset.
> > 
> > Do you think the above is (a) correct, and (b) what's implemented?
> > 
> Do different things during reset depending on CMOS values doesn't sound
> right to me. I don't know what is implemented right now. I thought that
> we reload BIOS on reset.

We could have qemu do a soft reset (not reload rom) on a triple fault
or keyboard controller reset, and then have SeaBIOS request a hard
reset (have qemu reload rom) if it detects a soft reset that is not a
"resume" request.

I'm also not sure what qemu does today.

-Kevin

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Wed, Nov 25, 2009 at 10:31:16AM -0500, Kevin O'Connor wrote:
> On Wed, Nov 25, 2009 at 02:20:39PM +0200, Gleb Natapov wrote:
> > On Wed, Nov 25, 2009 at 06:09:51AM +0000, Jamie Lokier wrote:
> > > But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard
> > > controller method is used and the word asking for a branch back to the
> > > application has not been set.  Because that's how a modern OS (if not
> > > using ACPI) asks for a system reset.
> > > 
> > > Do you think the above is (a) correct, and (b) what's implemented?
> > > 
> > Do different things during reset depending on CMOS values doesn't sound
> > right to me. I don't know what is implemented right now. I thought that
> > we reload BIOS on reset.
> 
> We could have qemu do a soft reset (not reload rom) on a triple fault
> or keyboard controller reset, and then have SeaBIOS request a hard
> reset (have qemu reload rom) if it detects a soft reset that is not a
> "resume" request.
> 
> I'm also not sure what qemu does today.
> 
There is not notion of "soft" reset or "hard" reset in QEMU today. On
real modern HW the things are even more complex. There are power planes
that can be powered off independently. Think about computer in S3 sleep
state. Almost everything is powered of ("hard" reset) except of the memory
and RTC.

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Sebastian Herbszt]

Jamie Lokier wrote:
> What about DOS and DOS-extender programs which do a soft reset by
> triple-faulting the CPU (see Sebastian's notes on i440FX behaviour),
> and asking the keyboard controller?
> 
> Both of those methods are used by DOS and DOS-extender programs to
> switch from protected mode to real mode.  Keyboard controller was used
> originally, but then someone figured out that triple fault can be used
> (on most PCs) and is faster.
> 
> The switch to real mode is done by writing somewhere the BIOS checks,
> so the BIOS just branches back to the application.
> 
> I think that may imply it has to be a "soft reset" as described by
> Sebastian in the i440FX description, and I would think the BIOS must
> not be reloaded.
> 
> But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard
> controller method is used and the word asking for a branch back to the
> application has not been set.  Because that's how a modern OS (if not
> using ACPI) asks for a system reset.
> 
> Do you think the above is (a) correct, and (b) what's implemented?

The 440fx spec says "External logic is required to combine the PMC soft
reset with the keyboard controller and I/O port 92 soft reset generation."
I conclude from this, that the keyboard controller generates a soft reset too.

The ACPI spec says "The optional ACPI reset mechanism specifies a standard
mechanism that provides a complete system reset. When implemented, this
mechanism must reset the entire system. This includes processors, core logic,
all buses, and all peripherals. From an OSPM perspective, asserting the reset
mechanism is the logical equivalent to power cycling the machine. Upon gaining
control after a reset, OSPM will perform actions in like manner to a cold boot."
I think this power cycle behaviour is what "system_reset" should implement.

- Sebastian

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Sebastian Herbszt]

Gleb Natapov wrote:
> On Wed, Nov 25, 2009 at 06:09:51AM +0000, Jamie Lokier wrote:
>> Gleb Natapov wrote:
>> > > But QEMU is used to run old OSes too.
>> > > 
>> > That's OK. I don't expect BIOS to be reloaded if OS restart by jumping
>> > to BIOS reset code.
>> 
>> That's good then.
>> 
>> What about DOS and DOS-extender programs which do a soft reset by
>> triple-faulting the CPU (see Sebastian's notes on i440FX behaviour),
>> and asking the keyboard controller?
>> 
>> Both of those methods are used by DOS and DOS-extender programs to
>> switch from protected mode to real mode.  Keyboard controller was used
>> originally, but then someone figured out that triple fault can be used
>> (on most PCs) and is faster.
>> 
>> The switch to real mode is done by writing somewhere the BIOS checks,
>> so the BIOS just branches back to the application.
>> 
> If offset 0x0f in CMOS contains 0x0a then BIOS jumps to address stored
> in memory address 0x467.
> 
>> I think that may imply it has to be a "soft reset" as described by
>> Sebastian in the i440FX description, and I would think the BIOS must
>> not be reloaded.
> Reading ich9 spec I see that on this chipset it is possible to configure
> what kind of reset triple fault generates. Make it not very reliable. Was
> this triple fault trick only needed on 286 anyway?

It seems to be INIT# vs. PLTRST# (Platform Reset). On the latter all devices
are reset. Table 5-40 is pretty descriptive and there seem to be way too many
ways to trigger a reset. I think PLTRST# is used when a reset is triggered by
the ACPI method. Fortunatelly we don't have to implement this (yet) since
it's not available on  the 440fx.

Using triple fault to reset is used on 286+.

>> 
>> But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard
>> controller method is used and the word asking for a branch back to the
>> application has not been set.  Because that's how a modern OS (if not
>> using ACPI) asks for a system reset.
>> 
>> Do you think the above is (a) correct, and (b) what's implemented?
>> 
> Do different things during reset depending on CMOS values doesn't sound
> right to me. I don't know what is implemented right now. I thought that
> we reload BIOS on reset.

Currently the BIOS seems to be only loaded once and not reloaded during the life
time of a VM.
I don't think there is a notion of BIOS reload on real hardware. CPU access to it is
either directed to the rom (power-up configuration, all those fancy reset conditions)
or to ram.
How is shadowing currently implemented in qemu? Is the only BIOS copy overwritten
or is the rom copy separate from the ram copy?

- Sebastian

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Sebastian Herbszt]

Kevin O'Connor wrote:
> On Wed, Nov 25, 2009 at 02:20:39PM +0200, Gleb Natapov wrote:
>> On Wed, Nov 25, 2009 at 06:09:51AM +0000, Jamie Lokier wrote:
>> > But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard
>> > controller method is used and the word asking for a branch back to the
>> > application has not been set.  Because that's how a modern OS (if not
>> > using ACPI) asks for a system reset.
>> > 
>> > Do you think the above is (a) correct, and (b) what's implemented?
>> > 
>> Do different things during reset depending on CMOS values doesn't sound
>> right to me. I don't know what is implemented right now. I thought that
>> we reload BIOS on reset.
> 
> We could have qemu do a soft reset (not reload rom) on a triple fault
> or keyboard controller reset, and then have SeaBIOS request a hard
> reset (have qemu reload rom) if it detects a soft reset that is not a
> "resume" request.
> 
> I'm also not sure what qemu does today.

I don't think such an interface would add a long time benefit and would prefer
a proper solution which will not tie seabios even more to qemu. One day it might
be possible to run a commercial BIOS on qemu, just like it is possible on Bochs.
Adding this interface might prevent that.

- Sebastian

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Kevin O'Connor]

On Wed, Nov 25, 2009 at 11:04:20PM +0100, Sebastian Herbszt wrote:
>> Do different things during reset depending on CMOS values doesn't sound
>> right to me. I don't know what is implemented right now. I thought that
>> we reload BIOS on reset.
>
> Currently the BIOS seems to be only loaded once and not reloaded
> during the life time of a VM.
> I don't think there is a notion of BIOS reload on real hardware. CPU
> access to it is either directed to the rom (power-up configuration,
> all those fancy reset conditions) or to ram.

I see a "BIOS reload" as equivalent to directing access to rom.

> How is shadowing currently implemented in qemu? Is the only BIOS
> copy overwritten or is the rom copy separate from the ram copy?

My understanding is that both the ram and rom are kept.  (Though, on a
"BIOS reload" I don't know if the ram is preserved.)


To summarize the discussion so far, there seems to be a potential
issue with reset:

* If qemu doesn't reload the bios (a soft-reset) then there is a
  potential issue with the bios and option roms not running properly
  after a system reset invoked by Linux or other modern OSs.

* If qemu does reload the bios (a hard-reset) then there is a good
  chance that old DOS programs will break when they invoke a reset in
  an attempt to switch from protected mode to real mode.

Is that correct?

-Kevin

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Wed, Nov 25, 2009 at 11:04:20PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Wed, Nov 25, 2009 at 06:09:51AM +0000, Jamie Lokier wrote:
> >>Gleb Natapov wrote:
> >>> > But QEMU is used to run old OSes too.
> >>> > > That's OK. I don't expect BIOS to be reloaded if OS
> >>restart by jumping
> >>> to BIOS reset code.
> >>
> >>That's good then.
> >>
> >>What about DOS and DOS-extender programs which do a soft reset by
> >>triple-faulting the CPU (see Sebastian's notes on i440FX behaviour),
> >>and asking the keyboard controller?
> >>
> >>Both of those methods are used by DOS and DOS-extender programs to
> >>switch from protected mode to real mode.  Keyboard controller was used
> >>originally, but then someone figured out that triple fault can be used
> >>(on most PCs) and is faster.
> >>
> >>The switch to real mode is done by writing somewhere the BIOS checks,
> >>so the BIOS just branches back to the application.
> >>
> >If offset 0x0f in CMOS contains 0x0a then BIOS jumps to address stored
> >in memory address 0x467.
> >
> >>I think that may imply it has to be a "soft reset" as described by
> >>Sebastian in the i440FX description, and I would think the BIOS must
> >>not be reloaded.
> >Reading ich9 spec I see that on this chipset it is possible to configure
> >what kind of reset triple fault generates. Make it not very reliable. Was
> >this triple fault trick only needed on 286 anyway?
> 
> It seems to be INIT# vs. PLTRST# (Platform Reset). On the latter all devices
> are reset. Table 5-40 is pretty descriptive and there seem to be way too many
> ways to trigger a reset. I think PLTRST# is used when a reset is triggered by
> the ACPI method. Fortunatelly we don't have to implement this (yet) since
> it's not available on  the 440fx.
> 
> Using triple fault to reset is used on 286+.
> 
Triple fault use as a reset is widely used today. Use of triple fault to
switch from protected mode to real mode was specific for 286.

> >>
> >>But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard
> >>controller method is used and the word asking for a branch back to the
> >>application has not been set.  Because that's how a modern OS (if not
> >>using ACPI) asks for a system reset.
> >>
> >>Do you think the above is (a) correct, and (b) what's implemented?
> >>
> >Do different things during reset depending on CMOS values doesn't sound
> >right to me. I don't know what is implemented right now. I thought that
> >we reload BIOS on reset.
> 
> Currently the BIOS seems to be only loaded once and not reloaded during the life
> time of a VM.
> I don't think there is a notion of BIOS reload on real hardware. CPU access to it is
> either directed to the rom (power-up configuration, all those fancy reset conditions)
> or to ram.
Reloading BIOS in QEMU is needed for a reason not present on real HW. Think
about migration from old QEMU to new QEMU. Suppose old BIOS can't
properly initialize new QEMU. Then next reboot after migration will fail
since old BIOS will be used.

> How is shadowing currently implemented in qemu? Is the only BIOS copy overwritten
> or is the rom copy separate from the ram copy?
> 

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Wed, Nov 25, 2009 at 05:53:49PM -0500, Kevin O'Connor wrote:
> On Wed, Nov 25, 2009 at 11:04:20PM +0100, Sebastian Herbszt wrote:
> >> Do different things during reset depending on CMOS values doesn't sound
> >> right to me. I don't know what is implemented right now. I thought that
> >> we reload BIOS on reset.
> >
> > Currently the BIOS seems to be only loaded once and not reloaded
> > during the life time of a VM.
> > I don't think there is a notion of BIOS reload on real hardware. CPU
> > access to it is either directed to the rom (power-up configuration,
> > all those fancy reset conditions) or to ram.
> 
> I see a "BIOS reload" as equivalent to directing access to rom.
> 
> > How is shadowing currently implemented in qemu? Is the only BIOS
> > copy overwritten or is the rom copy separate from the ram copy?
> 
> My understanding is that both the ram and rom are kept.  (Though, on a
> "BIOS reload" I don't know if the ram is preserved.)
> 
> 
> To summarize the discussion so far, there seems to be a potential
> issue with reset:
> 
> * If qemu doesn't reload the bios (a soft-reset) then there is a
>   potential issue with the bios and option roms not running properly
>   after a system reset invoked by Linux or other modern OSs.
> 
> * If qemu does reload the bios (a hard-reset) then there is a good
>   chance that old DOS programs will break when they invoke a reset in
>   an attempt to switch from protected mode to real mode.
> 
> Is that correct?
> 
Reloading of a BIOS will not prevent old DOS program from working.
It will slow switch to real mode, but otherwise I see no harm. What may
prevent them from working is the fact that too much devices are reset on
triple fault, but this has nothing to do with reloading of a BIOS.

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Kevin O'Connor]

On Thu, Nov 26, 2009 at 08:49:25AM +0200, Gleb Natapov wrote:
> On Wed, Nov 25, 2009 at 05:53:49PM -0500, Kevin O'Connor wrote:
> > * If qemu does reload the bios (a hard-reset) then there is a good
> >   chance that old DOS programs will break when they invoke a reset in
> >   an attempt to switch from protected mode to real mode.
> > 
> > Is that correct?
> > 
> Reloading of a BIOS will not prevent old DOS program from working.
> It will slow switch to real mode, but otherwise I see no harm. What may
> prevent them from working is the fact that too much devices are reset on
> triple fault, but this has nothing to do with reloading of a BIOS.

On a switch to real mode, seabios will detect the code in cmos and
jump directly to the resume vector.  Seabios will not reinitialize
itself in this case.

Now, if the bios is reloaded, the jump to the resume vector will skip
ide, bios table, and other internal state setup.  So, later calls to
the bios will likely fail.

-Kevin

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Thu, Nov 26, 2009 at 02:15:27AM -0500, Kevin O'Connor wrote:
> On Thu, Nov 26, 2009 at 08:49:25AM +0200, Gleb Natapov wrote:
> > On Wed, Nov 25, 2009 at 05:53:49PM -0500, Kevin O'Connor wrote:
> > > * If qemu does reload the bios (a hard-reset) then there is a good
> > >   chance that old DOS programs will break when they invoke a reset in
> > >   an attempt to switch from protected mode to real mode.
> > > 
> > > Is that correct?
> > > 
> > Reloading of a BIOS will not prevent old DOS program from working.
> > It will slow switch to real mode, but otherwise I see no harm. What may
> > prevent them from working is the fact that too much devices are reset on
> > triple fault, but this has nothing to do with reloading of a BIOS.
> 
> On a switch to real mode, seabios will detect the code in cmos and
> jump directly to the resume vector.  Seabios will not reinitialize
> itself in this case.
> 
> Now, if the bios is reloaded, the jump to the resume vector will skip
> ide, bios table, and other internal state setup.  So, later calls to
> the bios will likely fail.
> 
Seabios stores .bss and .data section in BIOS segments? If this is the
case that you are right. Can we move them somewhere else and add it to
e820 map? Although event then switching to real mode using triple fault
after migration to newer BIOS will not work properly.

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Kevin O'Connor]

On Thu, Nov 26, 2009 at 09:20:34AM +0200, Gleb Natapov wrote:
> On Thu, Nov 26, 2009 at 02:15:27AM -0500, Kevin O'Connor wrote:
> > Now, if the bios is reloaded, the jump to the resume vector will skip
> > ide, bios table, and other internal state setup.  So, later calls to
> > the bios will likely fail.
> > 
> Seabios stores .bss and .data section in BIOS segments?

Yes.

>If this is the
> case that you are right. Can we move them somewhere else and add it to
> e820 map?

That would significantly complicate the code, and it wouldn't truly
solve the issue as some data needs to be stored in the f-segment (eg,
smbios anchor).

>Although event then switching to real mode using triple fault
> after migration to newer BIOS will not work properly.

IMO, migrating to a new bios doesn't make sense - the bios is an
application with state - one can't just replace the code.

-Kevin

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Thu, Nov 26, 2009 at 02:48:46AM -0500, Kevin O'Connor wrote:
> On Thu, Nov 26, 2009 at 09:20:34AM +0200, Gleb Natapov wrote:
> > On Thu, Nov 26, 2009 at 02:15:27AM -0500, Kevin O'Connor wrote:
> > > Now, if the bios is reloaded, the jump to the resume vector will skip
> > > ide, bios table, and other internal state setup.  So, later calls to
> > > the bios will likely fail.
> > > 
> > Seabios stores .bss and .data section in BIOS segments?
> 
> Yes.
> 
> >If this is the
> > case that you are right. Can we move them somewhere else and add it to
> > e820 map?
> 
> That would significantly complicate the code, and it wouldn't truly
> solve the issue as some data needs to be stored in the f-segment (eg,
> smbios anchor).
And I don't think support of switching to rm with triple fault worth
complication at all. BTW is seams QEMU doesn't event support 286 where
this is needed.

> 
> >Although event then switching to real mode using triple fault
> > after migration to newer BIOS will not work properly.
> 
> IMO, migrating to a new bios doesn't make sense - the bios is an
> application with state - one can't just replace the code.
> 
You don't migrate to a new BIOS. You migrate to a new QEMU that happens
to have a new BIOS. And ability to migrate to a newer QEMU is a must.

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Kevin O'Connor]

On Thu, Nov 26, 2009 at 09:56:42AM +0200, Gleb Natapov wrote:
> On Thu, Nov 26, 2009 at 02:48:46AM -0500, Kevin O'Connor wrote:
> > That would significantly complicate the code, and it wouldn't truly
> > solve the issue as some data needs to be stored in the f-segment (eg,
> > smbios anchor).
> And I don't think support of switching to rm with triple fault worth
> complication at all.

I agree.

> > IMO, migrating to a new bios doesn't make sense - the bios is an
> > application with state - one can't just replace the code.
> > 
> You don't migrate to a new BIOS. You migrate to a new QEMU that happens
> to have a new BIOS. And ability to migrate to a newer QEMU is a must.

IMO, the ram at 0xf0000 needs to get migrated just like the rest of
the ram.

Silly example - Linux and APM.  On Linux init, it finds the APM
vectors from bios and periodically calls them to sleep machine.  On
migration, a new bios could have a different code location for apm -
if Linux calls sleep after migration it jumps into random code and
blows up.

-Kevin

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Thu, Nov 26, 2009 at 03:12:53AM -0500, Kevin O'Connor wrote:
> > > IMO, migrating to a new bios doesn't make sense - the bios is an
> > > application with state - one can't just replace the code.
> > > 
> > You don't migrate to a new BIOS. You migrate to a new QEMU that happens
> > to have a new BIOS. And ability to migrate to a newer QEMU is a must.
> 
> IMO, the ram at 0xf0000 needs to get migrated just like the rest of
> the ram.
And it is! The old BIOS is running after migration. But on the first reset
after migration new BIOS should be loaded since old one can't initialize
new QEMU any more.

> 
> Silly example - Linux and APM.  On Linux init, it finds the APM
> vectors from bios and periodically calls them to sleep machine.  On
> migration, a new bios could have a different code location for apm -
> if Linux calls sleep after migration it jumps into random code and
> blows up.
> 
That is not silly example. Another example is TPR patching. This examples
shows why old BIOS has to be migrated and used till reboot.

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Kevin O'Connor]

On Thu, Nov 26, 2009 at 10:19:57AM +0200, Gleb Natapov wrote:
> On Thu, Nov 26, 2009 at 03:12:53AM -0500, Kevin O'Connor wrote:
> > IMO, the ram at 0xf0000 needs to get migrated just like the rest of
> > the ram.
> And it is! The old BIOS is running after migration. But on the first reset
> after migration new BIOS should be loaded since old one can't initialize
> new QEMU any more.

Sorry for the confusion then.  The above behavior sounds fine.

-Kevin

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Sebastian Herbszt]

Gleb Natapov wrote:
> On Wed, Nov 25, 2009 at 11:04:20PM +0100, Sebastian Herbszt wrote:
>> Gleb Natapov wrote:
>> >On Wed, Nov 25, 2009 at 06:09:51AM +0000, Jamie Lokier wrote:
>> >>Gleb Natapov wrote:
>> >>> > But QEMU is used to run old OSes too.
>> >>> > > That's OK. I don't expect BIOS to be reloaded if OS
>> >>restart by jumping
>> >>> to BIOS reset code.
>> >>
>> >>That's good then.
>> >>
>> >>What about DOS and DOS-extender programs which do a soft reset by
>> >>triple-faulting the CPU (see Sebastian's notes on i440FX behaviour),
>> >>and asking the keyboard controller?
>> >>
>> >>Both of those methods are used by DOS and DOS-extender programs to
>> >>switch from protected mode to real mode.  Keyboard controller was used
>> >>originally, but then someone figured out that triple fault can be used
>> >>(on most PCs) and is faster.
>> >>
>> >>The switch to real mode is done by writing somewhere the BIOS checks,
>> >>so the BIOS just branches back to the application.
>> >>
>> >If offset 0x0f in CMOS contains 0x0a then BIOS jumps to address stored
>> >in memory address 0x467.
>> >
>> >>I think that may imply it has to be a "soft reset" as described by
>> >>Sebastian in the i440FX description, and I would think the BIOS must
>> >>not be reloaded.
>> >Reading ich9 spec I see that on this chipset it is possible to configure
>> >what kind of reset triple fault generates. Make it not very reliable. Was
>> >this triple fault trick only needed on 286 anyway?
>> 
>> It seems to be INIT# vs. PLTRST# (Platform Reset). On the latter all devices
>> are reset. Table 5-40 is pretty descriptive and there seem to be way too many
>> ways to trigger a reset. I think PLTRST# is used when a reset is triggered by
>> the ACPI method. Fortunatelly we don't have to implement this (yet) since
>> it's not available on  the 440fx.
>> 
>> Using triple fault to reset is used on 286+.
>> 
> Triple fault use as a reset is widely used today. Use of triple fault to
> switch from protected mode to real mode was specific for 286.

Whether triple fault is used just for a reset or to switch from protected mode to real
mode is irrelevant, because from the hardware point of view this is exactly the same
reset. And old applications can still use this method on new CPUs.

>> >>
>> >>But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard
>> >>controller method is used and the word asking for a branch back to the
>> >>application has not been set.  Because that's how a modern OS (if not
>> >>using ACPI) asks for a system reset.
>> >>
>> >>Do you think the above is (a) correct, and (b) what's implemented?
>> >>
>> >Do different things during reset depending on CMOS values doesn't sound
>> >right to me. I don't know what is implemented right now. I thought that
>> >we reload BIOS on reset.
>> 
>> Currently the BIOS seems to be only loaded once and not reloaded during the life
>> time of a VM.
>> I don't think there is a notion of BIOS reload on real hardware. CPU access to it is
>> either directed to the rom (power-up configuration, all those fancy reset conditions)
>> or to ram.
> Reloading BIOS in QEMU is needed for a reason not present on real HW. Think
> about migration from old QEMU to new QEMU. Suppose old BIOS can't
> properly initialize new QEMU. Then next reboot after migration will fail
> since old BIOS will be used.

Do you mean live migration between different QEMU versions? That doesn't sound safe,
especially if the hardware changes on reboot. Does the competition support this?

- Sebastian

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Sebastian Herbszt]

Kevin O'Connor wrote:
> On Wed, Nov 25, 2009 at 11:04:20PM +0100, Sebastian Herbszt wrote:
>>> Do different things during reset depending on CMOS values doesn't sound
>>> right to me. I don't know what is implemented right now. I thought that
>>> we reload BIOS on reset.
>>
>> Currently the BIOS seems to be only loaded once and not reloaded
>> during the life time of a VM.
>> I don't think there is a notion of BIOS reload on real hardware. CPU
>> access to it is either directed to the rom (power-up configuration,
>> all those fancy reset conditions) or to ram.
> 
> I see a "BIOS reload" as equivalent to directing access to rom.
> 
>> How is shadowing currently implemented in qemu? Is the only BIOS
>> copy overwritten or is the rom copy separate from the ram copy?
> 
> My understanding is that both the ram and rom are kept.  (Though, on a
> "BIOS reload" I don't know if the ram is preserved.)

The BIOS is mapped read only in hw/pc.c
    bios_offset = qemu_ram_alloc(bios_size)
...
    cpu_register_physical_memory(0x100000 - isa_bios_size,
                                 isa_bios_size,
                                 (bios_offset + bios_size - isa_bios_size) | IO_MEM_ROM);

Then it is remapped by update_pam() in hw/piix_pci.c

        cpu_register_physical_memory(start, end - start,
                                     start);

Since the memory is only allocated once i assume when the content gets overwritten
because of shadowing the original data is gone.

> To summarize the discussion so far, there seems to be a potential
> issue with reset:
> 
> * If qemu doesn't reload the bios (a soft-reset) then there is a
>  potential issue with the bios and option roms not running properly
>  after a system reset invoked by Linux or other modern OSs.

If a system reset (hard, power cycle) is requested and the hardware is reset to
the default power up state and it does require an option rom to initialize, but the
option rom is not reloaded and was shrunk and now only contains the runtime part,
there will likely be a problem.

Maybe the expansion rom bar can be used for pci devices like on real hardware. The bios
will check it and load the rom itself instead of relying on qemu to do the job.

> * If qemu does reload the bios (a hard-reset) then there is a good
>  chance that old DOS programs will break when they invoke a reset in
>  an attempt to switch from protected mode to real mode.

If a soft reset is requested with the goal of a transition from protected to real mode and the bios
is reloaded, it should not do any harm because the internal device states are kept and the cmos
still has the correct shutdown status code for the transition. Bochs bios doesn't rely on shadowing
so none of its internal state is lost either, but the created tables (smbios, mp table, etc.) will be gone.

- Sebastian

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Jamie Lokier]

Sebastian Herbszt wrote:
> >We could have qemu do a soft reset (not reload rom) on a triple fault
> >or keyboard controller reset, and then have SeaBIOS request a hard
> >reset (have qemu reload rom) if it detects a soft reset that is not a
> >"resume" request.
> >
> >I'm also not sure what qemu does today.
> 
> I don't think such an interface would add a long time benefit and
> would prefer a proper solution which will not tie seabios even more
> to qemu. One day it might be possible to run a commercial BIOS on
> qemu, just like it is possible on Bochs.  Adding this interface
> might prevent that.

What does a real BIOS on real hardware do?

Do real BIOSes make a decision as described above, and we're just
assuming they don't?

One way to answer may be: On a real PC with i440FX, what kind of reset
are the different reset methods (triple fault, keyboard etc.) normally
configured to do?

IIRC, HIMEM.SYS in DOS must use at least one of the
switch-to-real-mode methods to work, and that driver is needed by
Windows 3/3.11/95/98/ME, but I'm a bit vague on the details.

-- Jamie

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Kevin O'Connor]

On Thu, Nov 26, 2009 at 11:35:52PM +0100, Sebastian Herbszt wrote:
> Maybe the expansion rom bar can be used for pci devices like on real
> hardware. The bios will check it and load the rom itself instead of
> relying on qemu to do the job.

SeaBIOS can pull roms from pci space today.  Long term, I would prefer
to see qemu use this.

> If a soft reset is requested with the goal of a transition from
> protected to real mode and the bios is reloaded, it should not do
> any harm because the internal device states are kept and the cmos
> still has the correct shutdown status code for the transition.

SeaBIOS stores internal state in the f-segment - it wont function
properly if that state is cleared.  (For example, disk read requests
will fail, e820 requests will fail, etc.)

>Bochs
> bios doesn't rely on shadowing so none of its internal state is lost
> either, but the created tables (smbios, mp table, etc.) will be
> gone.

Clearing the tables is also broken (though less likely to be noticed).
In a nutshell, qemu can't reset the f-segment and expect a resume
operation to work.  As Gleb pointed out though, it seems this use case
is more theoretical than practical, so worrying about this may not be
productive.

-Kevin

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Thu, Nov 26, 2009 at 09:55:28PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Wed, Nov 25, 2009 at 11:04:20PM +0100, Sebastian Herbszt wrote:
> >>Gleb Natapov wrote:
> >>>On Wed, Nov 25, 2009 at 06:09:51AM +0000, Jamie Lokier wrote:
> >>>>Gleb Natapov wrote:
> >>>>> > But QEMU is used to run old OSes too.
> >>>>> > > That's OK. I don't expect BIOS to be reloaded if OS
> >>>>restart by jumping
> >>>>> to BIOS reset code.
> >>>>
> >>>>That's good then.
> >>>>
> >>>>What about DOS and DOS-extender programs which do a soft reset by
> >>>>triple-faulting the CPU (see Sebastian's notes on i440FX behaviour),
> >>>>and asking the keyboard controller?
> >>>>
> >>>>Both of those methods are used by DOS and DOS-extender programs to
> >>>>switch from protected mode to real mode.  Keyboard controller was used
> >>>>originally, but then someone figured out that triple fault can be used
> >>>>(on most PCs) and is faster.
> >>>>
> >>>>The switch to real mode is done by writing somewhere the BIOS checks,
> >>>>so the BIOS just branches back to the application.
> >>>>
> >>>If offset 0x0f in CMOS contains 0x0a then BIOS jumps to address stored
> >>>in memory address 0x467.
> >>>
> >>>>I think that may imply it has to be a "soft reset" as described by
> >>>>Sebastian in the i440FX description, and I would think the BIOS must
> >>>>not be reloaded.
> >>>Reading ich9 spec I see that on this chipset it is possible to configure
> >>>what kind of reset triple fault generates. Make it not very reliable. Was
> >>>this triple fault trick only needed on 286 anyway?
> >>
> >>It seems to be INIT# vs. PLTRST# (Platform Reset). On the latter all devices
> >>are reset. Table 5-40 is pretty descriptive and there seem to be way too many
> >>ways to trigger a reset. I think PLTRST# is used when a reset is triggered by
> >>the ACPI method. Fortunatelly we don't have to implement this (yet) since
> >>it's not available on  the 440fx.
> >>
> >>Using triple fault to reset is used on 286+.
> >>
> >Triple fault use as a reset is widely used today. Use of triple fault to
> >switch from protected mode to real mode was specific for 286.
> 
> Whether triple fault is used just for a reset or to switch from protected mode to real
> mode is irrelevant, because from the hardware point of view this is exactly the same
> reset. And old applications can still use this method on new CPUs.
> 
If triple fault is used just for a reset we can do hard reset like we do
now. It may violate HW spec but it works.

> >>>>
> >>>>But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard
> >>>>controller method is used and the word asking for a branch back to the
> >>>>application has not been set.  Because that's how a modern OS (if not
> >>>>using ACPI) asks for a system reset.
> >>>>
> >>>>Do you think the above is (a) correct, and (b) what's implemented?
> >>>>
> >>>Do different things during reset depending on CMOS values doesn't sound
> >>>right to me. I don't know what is implemented right now. I thought that
> >>>we reload BIOS on reset.
> >>
> >>Currently the BIOS seems to be only loaded once and not reloaded during the life
> >>time of a VM.
> >>I don't think there is a notion of BIOS reload on real hardware. CPU access to it is
> >>either directed to the rom (power-up configuration, all those fancy reset conditions)
> >>or to ram.
> >Reloading BIOS in QEMU is needed for a reason not present on real HW. Think
> >about migration from old QEMU to new QEMU. Suppose old BIOS can't
> >properly initialize new QEMU. Then next reboot after migration will fail
> >since old BIOS will be used.
> 
> Do you mean live migration between different QEMU versions? That doesn't sound safe,
> especially if the hardware changes on reboot. Does the competition support this?
> 
Of course. The ability to upgrade cluster transparently is a major
feature. So migration from older version to newer one is must to have.

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Sebastian Herbszt]

Jamie Lokier wrote:
> Sebastian Herbszt wrote:
>> >We could have qemu do a soft reset (not reload rom) on a triple fault
>> >or keyboard controller reset, and then have SeaBIOS request a hard
>> >reset (have qemu reload rom) if it detects a soft reset that is not a
>> >"resume" request.
>> >
>> >I'm also not sure what qemu does today.
>> 
>> I don't think such an interface would add a long time benefit and
>> would prefer a proper solution which will not tie seabios even more
>> to qemu. One day it might be possible to run a commercial BIOS on
>> qemu, just like it is possible on Bochs.  Adding this interface
>> might prevent that.
> 
> What does a real BIOS on real hardware do?
> 
> Do real BIOSes make a decision as described above, and we're just
> assuming they don't?

A real BIOS gets started, checks CMOS shutdown status byte and decides
whether to POST or resume execution somewhere else.

> One way to answer may be: On a real PC with i440FX, what kind of reset
> are the different reset methods (triple fault, keyboard etc.) normally
> configured to do?

Should be those

power on -> hard reset
CPU shutdown bus cycle -> soft reset
TRC register (BISTE=0, SHRE=0, RCPU=1) -> soft reset
TRC register (BISTE=0, SHRE=1, RCPU=1) -> hard reset
keyboard controller -> soft reset
I/O port 92h -> soft reset
RC register (SRST=0, RCPU=1) -> soft reset
RC register (SRST=1, RCPU=1) -> hard reset

> IIRC, HIMEM.SYS in DOS must use at least one of the
> switch-to-real-mode methods to work, and that driver is needed by
> Windows 3/3.11/95/98/ME, but I'm a bit vague on the details.

The highmem.sys version i got here seems to use CR0 to switch between real and
protected mode. I can't find where/if it loads a hosed IDT.

- Sebastian

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Sebastian Herbszt]

Gleb Natapov wrote:
> On Thu, Nov 26, 2009 at 09:55:28PM +0100, Sebastian Herbszt wrote:
>> Gleb Natapov wrote:
>> >On Wed, Nov 25, 2009 at 11:04:20PM +0100, Sebastian Herbszt wrote:
>> >>Gleb Natapov wrote:
>> >>>On Wed, Nov 25, 2009 at 06:09:51AM +0000, Jamie Lokier wrote:
>> >>>>Gleb Natapov wrote:
>> >>>>> > But QEMU is used to run old OSes too.
>> >>>>> > > That's OK. I don't expect BIOS to be reloaded if OS
>> >>>>restart by jumping
>> >>>>> to BIOS reset code.
>> >>>>
>> >>>>That's good then.
>> >>>>
>> >>>>What about DOS and DOS-extender programs which do a soft reset by
>> >>>>triple-faulting the CPU (see Sebastian's notes on i440FX behaviour),
>> >>>>and asking the keyboard controller?
>> >>>>
>> >>>>Both of those methods are used by DOS and DOS-extender programs to
>> >>>>switch from protected mode to real mode.  Keyboard controller was used
>> >>>>originally, but then someone figured out that triple fault can be used
>> >>>>(on most PCs) and is faster.
>> >>>>
>> >>>>The switch to real mode is done by writing somewhere the BIOS checks,
>> >>>>so the BIOS just branches back to the application.
>> >>>>
>> >>>If offset 0x0f in CMOS contains 0x0a then BIOS jumps to address stored
>> >>>in memory address 0x467.
>> >>>
>> >>>>I think that may imply it has to be a "soft reset" as described by
>> >>>>Sebastian in the i440FX description, and I would think the BIOS must
>> >>>>not be reloaded.
>> >>>Reading ich9 spec I see that on this chipset it is possible to configure
>> >>>what kind of reset triple fault generates. Make it not very reliable. Was
>> >>>this triple fault trick only needed on 286 anyway?
>> >>
>> >>It seems to be INIT# vs. PLTRST# (Platform Reset). On the latter all devices
>> >>are reset. Table 5-40 is pretty descriptive and there seem to be way too many
>> >>ways to trigger a reset. I think PLTRST# is used when a reset is triggered by
>> >>the ACPI method. Fortunatelly we don't have to implement this (yet) since
>> >>it's not available on  the 440fx.
>> >>
>> >>Using triple fault to reset is used on 286+.
>> >>
>> >Triple fault use as a reset is widely used today. Use of triple fault to
>> >switch from protected mode to real mode was specific for 286.
>> 
>> Whether triple fault is used just for a reset or to switch from protected mode to real
>> mode is irrelevant, because from the hardware point of view this is exactly the same
>> reset. And old applications can still use this method on new CPUs.
>> 
> If triple fault is used just for a reset we can do hard reset like we do
> now. It may violate HW spec but it works.

Bad things might happen tho, because some of the hardware state is reset even if it should
not be. If some OS does program the PIIX3 PIRQx route control registers and then uses
triple fault to return from protected mode and qemu does reset those registers back to
default values, the OS might not like it when the BIOS resumes it.

>> >>>>
>> >>>>But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard
>> >>>>controller method is used and the word asking for a branch back to the
>> >>>>application has not been set.  Because that's how a modern OS (if not
>> >>>>using ACPI) asks for a system reset.
>> >>>>
>> >>>>Do you think the above is (a) correct, and (b) what's implemented?
>> >>>>
>> >>>Do different things during reset depending on CMOS values doesn't sound
>> >>>right to me. I don't know what is implemented right now. I thought that
>> >>>we reload BIOS on reset.
>> >>
>> >>Currently the BIOS seems to be only loaded once and not reloaded during the life
>> >>time of a VM.
>> >>I don't think there is a notion of BIOS reload on real hardware. CPU access to it is
>> >>either directed to the rom (power-up configuration, all those fancy reset conditions)
>> >>or to ram.
>> >Reloading BIOS in QEMU is needed for a reason not present on real HW. Think
>> >about migration from old QEMU to new QEMU. Suppose old BIOS can't
>> >properly initialize new QEMU. Then next reboot after migration will fail
>> >since old BIOS will be used.
>> 
>> Do you mean live migration between different QEMU versions? That doesn't sound safe,
>> especially if the hardware changes on reboot. Does the competition support this?
>> 
> Of course. The ability to upgrade cluster transparently is a major
> feature. So migration from older version to newer one is must to have.

I am wondering how this works on VMware. A VM has a virtualHW.version assigned, so the
hardware doesn't automagically change on software upgrades. You have to power off the VM
and request an upgrade for it to change. They also likely have a fairly stable BIOS version.
If a VM is created on ESX 3.5 with virtualHW.version 4 and live migrated to ESX 4.0, which also
supports virtualHW.version 7, i would assume it still has the same hardware on a hard reset and even
if you shutdown and restart it, since no hardware upgrade was requested by the user. If the hardware
has been upgraded it can't be migrated back to the ESX 3.5 host. The BIOS might be special tho. It does
likely support both hardware versions. If the VM got migrated, the old BIOS should be run and reloaded
as long as the VM has not been destroyed / stopped. This should happen even if the VM has been hard reset.
Now if the VM is shutdown and recreated on the new host it might be ok to load the new BIOS even if the
hardware version was not upgraded. But it is more (?) reasonable to keep loading the old BIOS until the
hardware is upgraded and leave the choice to the user.

- Sebastian

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Fri, Nov 27, 2009 at 09:42:19PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Thu, Nov 26, 2009 at 09:55:28PM +0100, Sebastian Herbszt wrote:
> >>Gleb Natapov wrote:
> >>>On Wed, Nov 25, 2009 at 11:04:20PM +0100, Sebastian Herbszt wrote:
> >>>>Gleb Natapov wrote:
> >>>>>On Wed, Nov 25, 2009 at 06:09:51AM +0000, Jamie Lokier wrote:
> >>>>>>Gleb Natapov wrote:
> >>>>>>> > But QEMU is used to run old OSes too.
> >>>>>>> > > That's OK. I don't expect BIOS to be reloaded if OS
> >>>>>>restart by jumping
> >>>>>>> to BIOS reset code.
> >>>>>>
> >>>>>>That's good then.
> >>>>>>
> >>>>>>What about DOS and DOS-extender programs which do a soft reset by
> >>>>>>triple-faulting the CPU (see Sebastian's notes on i440FX behaviour),
> >>>>>>and asking the keyboard controller?
> >>>>>>
> >>>>>>Both of those methods are used by DOS and DOS-extender programs to
> >>>>>>switch from protected mode to real mode.  Keyboard controller was used
> >>>>>>originally, but then someone figured out that triple fault can be used
> >>>>>>(on most PCs) and is faster.
> >>>>>>
> >>>>>>The switch to real mode is done by writing somewhere the BIOS checks,
> >>>>>>so the BIOS just branches back to the application.
> >>>>>>
> >>>>>If offset 0x0f in CMOS contains 0x0a then BIOS jumps to address stored
> >>>>>in memory address 0x467.
> >>>>>
> >>>>>>I think that may imply it has to be a "soft reset" as described by
> >>>>>>Sebastian in the i440FX description, and I would think the BIOS must
> >>>>>>not be reloaded.
> >>>>>Reading ich9 spec I see that on this chipset it is possible to configure
> >>>>>what kind of reset triple fault generates. Make it not very reliable. Was
> >>>>>this triple fault trick only needed on 286 anyway?
> >>>>
> >>>>It seems to be INIT# vs. PLTRST# (Platform Reset). On the latter all devices
> >>>>are reset. Table 5-40 is pretty descriptive and there seem to be way too many
> >>>>ways to trigger a reset. I think PLTRST# is used when a reset is triggered by
> >>>>the ACPI method. Fortunatelly we don't have to implement this (yet) since
> >>>>it's not available on  the 440fx.
> >>>>
> >>>>Using triple fault to reset is used on 286+.
> >>>>
> >>>Triple fault use as a reset is widely used today. Use of triple fault to
> >>>switch from protected mode to real mode was specific for 286.
> >>
> >>Whether triple fault is used just for a reset or to switch from protected mode to real
> >>mode is irrelevant, because from the hardware point of view this is exactly the same
> >>reset. And old applications can still use this method on new CPUs.
> >>
> >If triple fault is used just for a reset we can do hard reset like we do
> >now. It may violate HW spec but it works.
> 
> Bad things might happen tho, because some of the hardware state is reset even if it should
> not be. If some OS does program the PIIX3 PIRQx route control registers and then uses
> triple fault to return from protected mode and qemu does reset those registers back to
> default values, the OS might not like it when the BIOS resumes it.
> 
We already concluded that "return to PM by triple fault" is not something
we want to support. It was needed only on 286 and QEMU doesn't even
support 286 cpu emulation.
 
> >>>>>>
> >>>>>>But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard
> >>>>>>controller method is used and the word asking for a branch back to the
> >>>>>>application has not been set.  Because that's how a modern OS (if not
> >>>>>>using ACPI) asks for a system reset.
> >>>>>>
> >>>>>>Do you think the above is (a) correct, and (b) what's implemented?
> >>>>>>
> >>>>>Do different things during reset depending on CMOS values doesn't sound
> >>>>>right to me. I don't know what is implemented right now. I thought that
> >>>>>we reload BIOS on reset.
> >>>>
> >>>>Currently the BIOS seems to be only loaded once and not reloaded during the life
> >>>>time of a VM.
> >>>>I don't think there is a notion of BIOS reload on real hardware. CPU access to it is
> >>>>either directed to the rom (power-up configuration, all those fancy reset conditions)
> >>>>or to ram.
> >>>Reloading BIOS in QEMU is needed for a reason not present on real HW. Think
> >>>about migration from old QEMU to new QEMU. Suppose old BIOS can't
> >>>properly initialize new QEMU. Then next reboot after migration will fail
> >>>since old BIOS will be used.
> >>
> >>Do you mean live migration between different QEMU versions? That doesn't sound safe,
> >>especially if the hardware changes on reboot. Does the competition support this?
> >>
> >Of course. The ability to upgrade cluster transparently is a major
> >feature. So migration from older version to newer one is must to have.
> 
> I am wondering how this works on VMware. A VM has a virtualHW.version assigned, so the
> hardware doesn't automagically change on software upgrades. You have to power off the VM
> and request an upgrade for it to change. They also likely have a fairly stable BIOS version.
> If a VM is created on ESX 3.5 with virtualHW.version 4 and live migrated to ESX 4.0, which also
> supports virtualHW.version 7, i would assume it still has the same hardware on a hard reset and even
> if you shutdown and restart it, since no hardware upgrade was requested by the user. If the hardware
> has been upgraded it can't be migrated back to the ESX 3.5 host. The BIOS might be special tho. It does
> likely support both hardware versions. If the VM got migrated, the old BIOS should be run and reloaded
> as long as the VM has not been destroyed / stopped. This should happen even if the VM has been hard reset.
> Now if the VM is shutdown and recreated on the new host it might be ok to load the new BIOS even if the
> hardware version was not upgraded. But it is more (?) reasonable to keep loading the old BIOS until the
> hardware is upgraded and leave the choice to the user.
> 
You are talking about major HW upgrades and I am not talking about that
at all. You can't migrate from i440FX to ich9 obviously. I am talking
about bug fixes in existing HW. For instance currently LINT0 is
configured to virtual wire mode by KVM itself, but it should be done by
a BIOS. Suppose new version of KVM fixes this bug, code that did this is
removed from KVM module and LINT0 configuration is added to a BIOS. Now
you migrate old guest to the new QEMU/KVM and do reboot. If old BIOS
will be executed it will not put LINT0 to virtual wire mode and new KVM
will not do that too. OS boot will fail as a result. That is only one
example from real life and I have more.

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Natalia Portillo]

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

>>
> We already concluded that "return to PM by triple fault" is not  
> something
> we want to support. It was needed only on 286 and QEMU doesn't even
> support 286 cpu emulation.

It is used by a whole kind of operating systems (all the 16-bit OS/2  
tree) and who knows by how many DOS extenders.
It is supported by Pentium processors, so it should be by QEMU, no  
matter it does not emulate the 286 but a later CPU.

[-- Attachment #2: Type: text/html, Size: 727 bytes --]

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Sun, Nov 29, 2009 at 10:53:40PM +0000, Natalia Portillo wrote:
> >>
> >We already concluded that "return to PM by triple fault" is not
> >something
> >we want to support. It was needed only on 286 and QEMU doesn't even
> >support 286 cpu emulation.
> 
> It is used by a whole kind of operating systems (all the 16-bit OS/2
> tree) and who knows by how many DOS extenders.
I suppose none. But if you know any please mansion it by name here. Note
that is should support i386 CPU since QMEU does not emulate i286.

I386 has native way to switch to PM, no need triple fault trick and it
was introduced by Intel in 1985. For those who wanted to be compatible
with 286 there was a trick invented back then to switch to PM in a
portable way between i386 and i286:
http://www.rcollins.org/ftp/source/3fault/reset.asm

I doubt that OS/2 was not updated to use something like this.

> It is supported by Pentium processors, so it should be by QEMU, no
> matter it does not emulate the 286 but a later CPU.
Most chipsets can be configured to do full reset on CPU shutdown cycle.
You simple can't rely on certain behaviour of triple fault. 

BTW QEMU today does full reset on triple fault and I haven't noticed any
complains.

--
			Gleb.

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Sebastian Herbszt]

Gleb Natapov wrote:
> On Fri, Nov 27, 2009 at 09:42:19PM +0100, Sebastian Herbszt wrote:
>> Gleb Natapov wrote:
>> >On Thu, Nov 26, 2009 at 09:55:28PM +0100, Sebastian Herbszt wrote:
>> >>Gleb Natapov wrote:
>> >>>On Wed, Nov 25, 2009 at 11:04:20PM +0100, Sebastian Herbszt wrote:
>> >>>>Gleb Natapov wrote:
>> >>>>>On Wed, Nov 25, 2009 at 06:09:51AM +0000, Jamie Lokier wrote:
>> >>>>>>Gleb Natapov wrote:
>> >>>>>>> > But QEMU is used to run old OSes too.
>> >>>>>>> > > That's OK. I don't expect BIOS to be reloaded if OS
>> >>>>>>restart by jumping
>> >>>>>>> to BIOS reset code.
>> >>>>>>
>> >>>>>>That's good then.
>> >>>>>>
>> >>>>>>What about DOS and DOS-extender programs which do a soft reset by
>> >>>>>>triple-faulting the CPU (see Sebastian's notes on i440FX behaviour),
>> >>>>>>and asking the keyboard controller?
>> >>>>>>
>> >>>>>>Both of those methods are used by DOS and DOS-extender programs to
>> >>>>>>switch from protected mode to real mode.  Keyboard controller was used
>> >>>>>>originally, but then someone figured out that triple fault can be used
>> >>>>>>(on most PCs) and is faster.
>> >>>>>>
>> >>>>>>The switch to real mode is done by writing somewhere the BIOS checks,
>> >>>>>>so the BIOS just branches back to the application.
>> >>>>>>
>> >>>>>If offset 0x0f in CMOS contains 0x0a then BIOS jumps to address stored
>> >>>>>in memory address 0x467.
>> >>>>>
>> >>>>>>I think that may imply it has to be a "soft reset" as described by
>> >>>>>>Sebastian in the i440FX description, and I would think the BIOS must
>> >>>>>>not be reloaded.
>> >>>>>Reading ich9 spec I see that on this chipset it is possible to configure
>> >>>>>what kind of reset triple fault generates. Make it not very reliable. Was
>> >>>>>this triple fault trick only needed on 286 anyway?
>> >>>>
>> >>>>It seems to be INIT# vs. PLTRST# (Platform Reset). On the latter all devices
>> >>>>are reset. Table 5-40 is pretty descriptive and there seem to be way too many
>> >>>>ways to trigger a reset. I think PLTRST# is used when a reset is triggered by
>> >>>>the ACPI method. Fortunatelly we don't have to implement this (yet) since
>> >>>>it's not available on  the 440fx.
>> >>>>
>> >>>>Using triple fault to reset is used on 286+.
>> >>>>
>> >>>Triple fault use as a reset is widely used today. Use of triple fault to
>> >>>switch from protected mode to real mode was specific for 286.
>> >>
>> >>Whether triple fault is used just for a reset or to switch from protected mode to real
>> >>mode is irrelevant, because from the hardware point of view this is exactly the same
>> >>reset. And old applications can still use this method on new CPUs.
>> >>
>> >If triple fault is used just for a reset we can do hard reset like we do
>> >now. It may violate HW spec but it works.
>> 
>> Bad things might happen tho, because some of the hardware state is reset even if it should
>> not be. If some OS does program the PIIX3 PIRQx route control registers and then uses
>> triple fault to return from protected mode and qemu does reset those registers back to
>> default values, the OS might not like it when the BIOS resumes it.
>> 
> We already concluded that "return to PM by triple fault" is not something
> we want to support. It was needed only on 286 and QEMU doesn't even
> support 286 cpu emulation.

I don't think you can conclude this because it's not an optional feature. Whether qemu
emulates a 286 cpu is irrelevant in this case because the hardware qemu emulates has
to be backward compatible.

>> >>>>>>
>> >>>>>>But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard
>> >>>>>>controller method is used and the word asking for a branch back to the
>> >>>>>>application has not been set.  Because that's how a modern OS (if not
>> >>>>>>using ACPI) asks for a system reset.
>> >>>>>>
>> >>>>>>Do you think the above is (a) correct, and (b) what's implemented?
>> >>>>>>
>> >>>>>Do different things during reset depending on CMOS values doesn't sound
>> >>>>>right to me. I don't know what is implemented right now. I thought that
>> >>>>>we reload BIOS on reset.
>> >>>>
>> >>>>Currently the BIOS seems to be only loaded once and not reloaded during the life
>> >>>>time of a VM.
>> >>>>I don't think there is a notion of BIOS reload on real hardware. CPU access to it is
>> >>>>either directed to the rom (power-up configuration, all those fancy reset conditions)
>> >>>>or to ram.
>> >>>Reloading BIOS in QEMU is needed for a reason not present on real HW. Think
>> >>>about migration from old QEMU to new QEMU. Suppose old BIOS can't
>> >>>properly initialize new QEMU. Then next reboot after migration will fail
>> >>>since old BIOS will be used.
>> >>
>> >>Do you mean live migration between different QEMU versions? That doesn't sound safe,
>> >>especially if the hardware changes on reboot. Does the competition support this?
>> >>
>> >Of course. The ability to upgrade cluster transparently is a major
>> >feature. So migration from older version to newer one is must to have.
>> 
>> I am wondering how this works on VMware. A VM has a virtualHW.version assigned, so the
>> hardware doesn't automagically change on software upgrades. You have to power off the VM
>> and request an upgrade for it to change. They also likely have a fairly stable BIOS version.
>> If a VM is created on ESX 3.5 with virtualHW.version 4 and live migrated to ESX 4.0, which also
>> supports virtualHW.version 7, i would assume it still has the same hardware on a hard reset and even
>> if you shutdown and restart it, since no hardware upgrade was requested by the user. If the hardware
>> has been upgraded it can't be migrated back to the ESX 3.5 host. The BIOS might be special tho. It does
>> likely support both hardware versions. If the VM got migrated, the old BIOS should be run and reloaded
>> as long as the VM has not been destroyed / stopped. This should happen even if the VM has been hard reset.
>> Now if the VM is shutdown and recreated on the new host it might be ok to load the new BIOS even if the
>> hardware version was not upgraded. But it is more (?) reasonable to keep loading the old BIOS until the
>> hardware is upgraded and leave the choice to the user.
>> 
> You are talking about major HW upgrades and I am not talking about that
> at all. You can't migrate from i440FX to ich9 obviously. I am talking
> about bug fixes in existing HW. For instance currently LINT0 is
> configured to virtual wire mode by KVM itself, but it should be done by
> a BIOS. Suppose new version of KVM fixes this bug, code that did this is
> removed from KVM module and LINT0 configuration is added to a BIOS. Now
> you migrate old guest to the new QEMU/KVM and do reboot. If old BIOS
> will be executed it will not put LINT0 to virtual wire mode and new KVM
> will not do that too. OS boot will fail as a result. That is only one
> example from real life and I have more.

This is unfortunate. Updating the BIOS of a running VM might not be the best idea; tho i don't have a better one.
An unfriendly solution would be to disallow live migration between broken and fixed versions.

- Sebastian

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Jamie Lokier]

Gleb Natapov wrote:
> On Sun, Nov 29, 2009 at 10:53:40PM +0000, Natalia Portillo wrote:
> > >>
> > >We already concluded that "return to PM by triple fault" is not
> > >something
> > >we want to support. It was needed only on 286 and QEMU doesn't even
> > >support 286 cpu emulation.
> > 
> > It is used by a whole kind of operating systems (all the 16-bit OS/2
> > tree) and who knows by how many DOS extenders.
> I suppose none. But if you know any please mansion it by name here. Note
> that is should support i386 CPU since QMEU does not emulate i286.
> 
> I386 has native way to switch to PM, no need triple fault trick and it
> was introduced by Intel in 1985. For those who wanted to be compatible
> with 286 there was a trick invented back then to switch to PM in a
> portable way between i386 and i286:
> http://www.rcollins.org/ftp/source/3fault/reset.asm
> 
> I doubt that OS/2 was not updated to use something like this.

I can't test 16-bit OS/2, so if someone would like to give it a try
that'd be great.  It'd be interesting to see what method it uses.

I will try 16-bit Windows 3, and MS-DOS with HIMEM.SYS and Turbo C++ to
see if (a) they still work and (b) what method they use.

> > It is supported by Pentium processors, so it should be by QEMU, no
> > matter it does not emulate the 286 but a later CPU.
> Most chipsets can be configured to do full reset on CPU shutdown cycle.
> You simple can't rely on certain behaviour of triple fault. 

I wouldn't be surprised if, for ancient 286 app compatibility, real
BIOSes always set the chipset to do a soft reset, but I've no idea
really what they do.

286 era PCs didn't do much on soft reset :-)

The triple fault and keyboard reset methods, when BIOS is told it's
for PM->RM switch, don't disturb the video output, lose keyboard input
or have to do a slow reinitialisation of hard disk or memory, because
those things all carry on working.

The PM->RM switch is used as a slow context switch or method for
calling the BIOS in multitasking environments.  Even though it's slow
(especially when done through a keyboard controller request), it's
fast enough to use for context switching.

> BTW QEMU today does full reset on triple fault and I haven't noticed any
> complains.

Those OSes we've just talked about don't care about the ACPI (etc)
tables getting wiped in the BIOS, do they? :-)

I'm getting the impression all the BIOS self-modification is in areas
which aren't used by ancient OSes using the triple fault or keyboard
methods for PM->RM switch.  Is that right?

It would still be unfortunate if you could boot DOS, run a few things
that use the old PM->RM methods, then run LOADLIN to boot a modern
Linux (from DOS) and find Linux needs something that's messed up in
the BIOS.

-- Jamie

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Natalia Portillo]

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

>>
>> I386 has native way to switch to PM, no need triple fault trick and  
>> it
>> was introduced by Intel in 1985. For those who wanted to be  
>> compatible
>> with 286 there was a trick invented back then to switch to PM in a
>> portable way between i386 and i286:
>> http://www.rcollins.org/ftp/source/3fault/reset.asm
>>
>> I doubt that OS/2 was not updated to use something like this.
>
> I can't test 16-bit OS/2, so if someone would like to give it a try
> that'd be great.  It'd be interesting to see what method it uses.
>
> I will try 16-bit Windows 3, and MS-DOS with HIMEM.SYS and Turbo C++  
> to
> see if (a) they still work and (b) what method they use.

16-bit OS/2 is not working at all, it stops in booting the  
installation floppies because of unknown CMOS error.
That was last time I checked in about 0.7.0.

I know that between 0.9 and 0.10 still crashed on same "STDIO line",  
however I don't know if it is the same CMOS error, so I don't know  
what will happen when it triple faults because the kernel still did  
not tried to (apparently).


[-- Attachment #2: Type: text/html, Size: 1736 bytes --]

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Kevin O'Connor]

On Mon, Nov 30, 2009 at 08:53:35PM +0000, Jamie Lokier wrote:
> Gleb Natapov wrote:
> > I doubt that OS/2 was not updated to use something like this.
> 
> I can't test 16-bit OS/2, so if someone would like to give it a try
> that'd be great.  It'd be interesting to see what method it uses.

I've tested OS/2 warp here - it boots fine on qemu with seabios.  I
no longer have a copy of OS/2 version 1.x.

-Kevin

Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios

[Gleb Natapov]

On Mon, Nov 30, 2009 at 09:34:58PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Fri, Nov 27, 2009 at 09:42:19PM +0100, Sebastian Herbszt wrote:
> >>Gleb Natapov wrote:
> >>>On Thu, Nov 26, 2009 at 09:55:28PM +0100, Sebastian Herbszt wrote:
> >>>>Gleb Natapov wrote:
> >>>>>On Wed, Nov 25, 2009 at 11:04:20PM +0100, Sebastian Herbszt wrote:
> >>>>>>Gleb Natapov wrote:
> >>>>>>>On Wed, Nov 25, 2009 at 06:09:51AM +0000, Jamie Lokier wrote:
> >>>>>>>>Gleb Natapov wrote:
> >>>>>>>>> > But QEMU is used to run old OSes too.
> >>>>>>>>> > > That's OK. I don't expect BIOS to be reloaded if OS
> >>>>>>>>restart by jumping
> >>>>>>>>> to BIOS reset code.
> >>>>>>>>
> >>>>>>>>That's good then.
> >>>>>>>>
> >>>>>>>>What about DOS and DOS-extender programs which do a soft reset by
> >>>>>>>>triple-faulting the CPU (see Sebastian's notes on i440FX behaviour),
> >>>>>>>>and asking the keyboard controller?
> >>>>>>>>
> >>>>>>>>Both of those methods are used by DOS and DOS-extender programs to
> >>>>>>>>switch from protected mode to real mode.  Keyboard controller was used
> >>>>>>>>originally, but then someone figured out that triple fault can be used
> >>>>>>>>(on most PCs) and is faster.
> >>>>>>>>
> >>>>>>>>The switch to real mode is done by writing somewhere the BIOS checks,
> >>>>>>>>so the BIOS just branches back to the application.
> >>>>>>>>
> >>>>>>>If offset 0x0f in CMOS contains 0x0a then BIOS jumps to address stored
> >>>>>>>in memory address 0x467.
> >>>>>>>
> >>>>>>>>I think that may imply it has to be a "soft reset" as described by
> >>>>>>>>Sebastian in the i440FX description, and I would think the BIOS must
> >>>>>>>>not be reloaded.
> >>>>>>>Reading ich9 spec I see that on this chipset it is possible to configure
> >>>>>>>what kind of reset triple fault generates. Make it not very reliable. Was
> >>>>>>>this triple fault trick only needed on 286 anyway?
> >>>>>>
> >>>>>>It seems to be INIT# vs. PLTRST# (Platform Reset). On the latter all devices
> >>>>>>are reset. Table 5-40 is pretty descriptive and there seem to be way too many
> >>>>>>ways to trigger a reset. I think PLTRST# is used when a reset is triggered by
> >>>>>>the ACPI method. Fortunatelly we don't have to implement this (yet) since
> >>>>>>it's not available on  the 440fx.
> >>>>>>
> >>>>>>Using triple fault to reset is used on 286+.
> >>>>>>
> >>>>>Triple fault use as a reset is widely used today. Use of triple fault to
> >>>>>switch from protected mode to real mode was specific for 286.
> >>>>
> >>>>Whether triple fault is used just for a reset or to switch from protected mode to real
> >>>>mode is irrelevant, because from the hardware point of view this is exactly the same
> >>>>reset. And old applications can still use this method on new CPUs.
> >>>>
> >>>If triple fault is used just for a reset we can do hard reset like we do
> >>>now. It may violate HW spec but it works.
> >>
> >>Bad things might happen tho, because some of the hardware state is reset even if it should
> >>not be. If some OS does program the PIIX3 PIRQx route control registers and then uses
> >>triple fault to return from protected mode and qemu does reset those registers back to
> >>default values, the OS might not like it when the BIOS resumes it.
> >>
> >We already concluded that "return to PM by triple fault" is not something
> >we want to support. It was needed only on 286 and QEMU doesn't even
> >support 286 cpu emulation.
> 
> I don't think you can conclude this because it's not an optional feature. Whether qemu
> emulates a 286 cpu is irrelevant in this case because the hardware qemu emulates has
> to be backward compatible.
> 
Qemu does not emulate many things. Even some CPU instructions. This is
not an issue if nobody uses them. And this future is clearly optional
since chipsets can be configured to not support it.

I still haven seen a name of the application that needs this BTW.

> >>>>>>>>
> >>>>>>>>But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard
> >>>>>>>>controller method is used and the word asking for a branch back to the
> >>>>>>>>application has not been set.  Because that's how a modern OS (if not
> >>>>>>>>using ACPI) asks for a system reset.
> >>>>>>>>
> >>>>>>>>Do you think the above is (a) correct, and (b) what's implemented?
> >>>>>>>>
> >>>>>>>Do different things during reset depending on CMOS values doesn't sound
> >>>>>>>right to me. I don't know what is implemented right now. I thought that
> >>>>>>>we reload BIOS on reset.
> >>>>>>
> >>>>>>Currently the BIOS seems to be only loaded once and not reloaded during the life
> >>>>>>time of a VM.
> >>>>>>I don't think there is a notion of BIOS reload on real hardware. CPU access to it is
> >>>>>>either directed to the rom (power-up configuration, all those fancy reset conditions)
> >>>>>>or to ram.
> >>>>>Reloading BIOS in QEMU is needed for a reason not present on real HW. Think
> >>>>>about migration from old QEMU to new QEMU. Suppose old BIOS can't
> >>>>>properly initialize new QEMU. Then next reboot after migration will fail
> >>>>>since old BIOS will be used.
> >>>>
> >>>>Do you mean live migration between different QEMU versions? That doesn't sound safe,
> >>>>especially if the hardware changes on reboot. Does the competition support this?
> >>>>
> >>>Of course. The ability to upgrade cluster transparently is a major
> >>>feature. So migration from older version to newer one is must to have.
> >>
> >>I am wondering how this works on VMware. A VM has a virtualHW.version assigned, so the
> >>hardware doesn't automagically change on software upgrades. You have to power off the VM
> >>and request an upgrade for it to change. They also likely have a fairly stable BIOS version.
> >>If a VM is created on ESX 3.5 with virtualHW.version 4 and live migrated to ESX 4.0, which also
> >>supports virtualHW.version 7, i would assume it still has the same hardware on a hard reset and even
> >>if you shutdown and restart it, since no hardware upgrade was requested by the user. If the hardware
> >>has been upgraded it can't be migrated back to the ESX 3.5 host. The BIOS might be special tho. It does
> >>likely support both hardware versions. If the VM got migrated, the old BIOS should be run and reloaded
> >>as long as the VM has not been destroyed / stopped. This should happen even if the VM has been hard reset.
> >>Now if the VM is shutdown and recreated on the new host it might be ok to load the new BIOS even if the
> >>hardware version was not upgraded. But it is more (?) reasonable to keep loading the old BIOS until the
> >>hardware is upgraded and leave the choice to the user.
> >>
> >You are talking about major HW upgrades and I am not talking about that
> >at all. You can't migrate from i440FX to ich9 obviously. I am talking
> >about bug fixes in existing HW. For instance currently LINT0 is
> >configured to virtual wire mode by KVM itself, but it should be done by
> >a BIOS. Suppose new version of KVM fixes this bug, code that did this is
> >removed from KVM module and LINT0 configuration is added to a BIOS. Now
> >you migrate old guest to the new QEMU/KVM and do reboot. If old BIOS
> >will be executed it will not put LINT0 to virtual wire mode and new KVM
> >will not do that too. OS boot will fail as a result. That is only one
> >example from real life and I have more.
> 
> This is unfortunate. Updating the BIOS of a running VM might not be the best idea; tho i don't have a better one.
Nobody is going to update the BIOS of the running VM. We are going
circles here. After migration old BIOS is used till reboot. During reboot
new BIOS is loaded.

> An unfriendly solution would be to disallow live migration between broken and fixed versions.

--
			Gleb.