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
On Mon, Nov 30, 2009 at 08:53:35PM +, 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 te
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
Gleb Natapov wrote:
> On Sun, Nov 29, 2009 at 10:53:40PM +, 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
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 Sun, Nov 29, 2009 at 10:53:40PM +, 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 sy
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
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
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 +, Jamie Lokier wrote:
Gleb Natapov wrote:
> > Bu
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 w
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 +, Jamie Lokier wrote:
> Gleb Natapov wrote:
> > > But QEMU is u
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
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 do
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
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 +, 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
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 0xf 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 m
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
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
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
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
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 pr
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
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 relo
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 +, 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 b
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 an
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 +, 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
> app
Gleb Natapov wrote:
On Wed, Nov 25, 2009 at 06:09:51AM +, 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
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 mod
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 +, Jamie Lokier wrote:
> > > But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard
> > > controller method is us
On Wed, Nov 25, 2009 at 02:20:39PM +0200, Gleb Natapov wrote:
> On Wed, Nov 25, 2009 at 06:09:51AM +, 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
On Wed, Nov 25, 2009 at 06:09:51AM +, 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 progr
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
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 i
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 Tue, Nov 24, 2009 at 02:38:12PM +, 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,
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 N
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
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 hap
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 some
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 reloade
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 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 Herb
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:
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 spec
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
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.
> > >
>
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();
>
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 du
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
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
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 i
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 re
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.
>
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
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
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
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/conf
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
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:
Unab
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 - bridg
60 matches
Mail list logo
