[Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Bei Guan]

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

Hi,

I have some questions about the qemu's bios. How does the QEMU load the
binary files bios.bin and vgabios-cirrus.bin? Which function or code file
need I to pay more attention to?

For the loading of vgabios-cirrus.bin and bios.bin, I just trace them into
the same funciton rom_add_file() in hw/loader.c. Is it the right function,
which loads the bioses?

And then another question, how qemu give the control to bios when the bios
file is loaded? Maybe this question is not in the scope of qemu, however,
can you give me some cue point.

Any reply are appreciated. Thanks.

Gavin

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

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Anthony Liguori]

On 04/07/2011 03:22 AM, Bei Guan wrote:
> Hi,
>
> I have some questions about the qemu's bios. How does the QEMU load 
> the binary files bios.bin and vgabios-cirrus.bin? Which function or 
> code file need I to pay more attention to?
>
> For the loading of vgabios-cirrus.bin and bios.bin, I just trace them 
> into the same funciton rom_add_file() in hw/loader.c. Is it the 
> right function, which loads the bioses?
>
> And then another question, how qemu give the control to bios when the 
> bios file is loaded? Maybe this question is not in the scope of qemu, 
> however, can you give me some cue point.

I had some stuff written up locally so I posted it to the wiki at 
http://wiki.qemu.org/Documentation/Platforms/PC

The x86 architecture defines the initial state of the chip to have the 
CS register have a base of 0xF000 and an IP of 0xFFF0.  The result is 
that the actual memory address of the first instruction falls at the end 
of the BIOS ROM segment.  This is the entry point to the BIOS.

The VGABIOS is treated like any other option ROM and is initialized 
during option ROM scanning.

Regards,

Anthony Liguori

> Any reply are appreciated. Thanks.
>
> Gavin
>
>
>
>

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Gleb Natapov]

On Thu, Apr 07, 2011 at 08:28:37AM -0500, Anthony Liguori wrote:
> On 04/07/2011 03:22 AM, Bei Guan wrote:
> >Hi,
> >
> >I have some questions about the qemu's bios. How does the QEMU
> >load the binary files bios.bin and vgabios-cirrus.bin? Which
> >function or code file need I to pay more attention to?
> >
> >For the loading of vgabios-cirrus.bin and bios.bin, I just trace
> >them into the same funciton rom_add_file() in hw/loader.c. Is it
> >the right function, which loads the bioses?
> >
> >And then another question, how qemu give the control to bios when
> >the bios file is loaded? Maybe this question is not in the scope
> >of qemu, however, can you give me some cue point.
> 
> I had some stuff written up locally so I posted it to the wiki at
> http://wiki.qemu.org/Documentation/Platforms/PC
> 
> The x86 architecture defines the initial state of the chip to have
> the CS register have a base of 0xF000 and an IP of 0xFFF0.  The
> result is that the actual memory address of the first instruction
> falls at the end of the BIOS ROM segment.  This is the entry point
> to the BIOS.
> 
Actually after reset on x86 IP=0x0000fff0, CS=0xf000, CS.BASE= 0xffff0000,
CS.LIMIT=0xffff. So the execution begins at 0xfffffff0 where ROM is
mapped initially.

> The VGABIOS is treated like any other option ROM and is initialized
> during option ROM scanning.
> 
> Regards,
> 
> Anthony Liguori
> 
> >Any reply are appreciated. Thanks.
> >
> >Gavin
> >
> >
> >
> >
> 

--
			Gleb.

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Anthony Liguori]

On 04/07/2011 10:31 AM, Gleb Natapov wrote:
> On Thu, Apr 07, 2011 at 08:28:37AM -0500, Anthony Liguori wrote:
>> On 04/07/2011 03:22 AM, Bei Guan wrote:
>>> Hi,
>>>
>>> I have some questions about the qemu's bios. How does the QEMU
>>> load the binary files bios.bin and vgabios-cirrus.bin? Which
>>> function or code file need I to pay more attention to?
>>>
>>> For the loading of vgabios-cirrus.bin and bios.bin, I just trace
>>> them into the same funciton rom_add_file() in hw/loader.c. Is it
>>> the right function, which loads the bioses?
>>>
>>> And then another question, how qemu give the control to bios when
>>> the bios file is loaded? Maybe this question is not in the scope
>>> of qemu, however, can you give me some cue point.
>> I had some stuff written up locally so I posted it to the wiki at
>> http://wiki.qemu.org/Documentation/Platforms/PC
>>
>> The x86 architecture defines the initial state of the chip to have
>> the CS register have a base of 0xF000 and an IP of 0xFFF0.  The
>> result is that the actual memory address of the first instruction
>> falls at the end of the BIOS ROM segment.  This is the entry point
>> to the BIOS.
>>
> Actually after reset on x86 IP=0x0000fff0, CS=0xf000, CS.BASE= 0xffff0000,
> CS.LIMIT=0xffff. So the execution begins at 0xfffffff0 where ROM is
> mapped initially.

That impossible because 1) the processor starts in 16 bit mode so such 
an address cannot be generated 2) the processor has a20 held to zero 
which makes that the processor cannot generate a load to an address with 
the 20th bit set to anything but zero.

The CS base starts out at 0xf0000 and IP is 0xfff0.  That gives a real 
address of 0xffff0.  This is usually a trampoline to somewhere else in 
the space.

The mapping of BIOS to the top of 4GB is just a convention that modern 
BIOSes use because the legacy space isn't big enough for most modern BIOSes.

Regards,

Anthony Liguori

>> The VGABIOS is treated like any other option ROM and is initialized
>> during option ROM scanning.
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>> Any reply are appreciated. Thanks.
>>>
>>> Gavin
>>>
>>>
>>>
>>>
> --
> 			Gleb.
>

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Gleb Natapov]

On Thu, Apr 07, 2011 at 10:42:56AM -0500, Anthony Liguori wrote:
> On 04/07/2011 10:31 AM, Gleb Natapov wrote:
> >On Thu, Apr 07, 2011 at 08:28:37AM -0500, Anthony Liguori wrote:
> >>On 04/07/2011 03:22 AM, Bei Guan wrote:
> >>>Hi,
> >>>
> >>>I have some questions about the qemu's bios. How does the QEMU
> >>>load the binary files bios.bin and vgabios-cirrus.bin? Which
> >>>function or code file need I to pay more attention to?
> >>>
> >>>For the loading of vgabios-cirrus.bin and bios.bin, I just trace
> >>>them into the same funciton rom_add_file() in hw/loader.c. Is it
> >>>the right function, which loads the bioses?
> >>>
> >>>And then another question, how qemu give the control to bios when
> >>>the bios file is loaded? Maybe this question is not in the scope
> >>>of qemu, however, can you give me some cue point.
> >>I had some stuff written up locally so I posted it to the wiki at
> >>http://wiki.qemu.org/Documentation/Platforms/PC
> >>
> >>The x86 architecture defines the initial state of the chip to have
> >>the CS register have a base of 0xF000 and an IP of 0xFFF0.  The
> >>result is that the actual memory address of the first instruction
> >>falls at the end of the BIOS ROM segment.  This is the entry point
> >>to the BIOS.
> >>
> >Actually after reset on x86 IP=0x0000fff0, CS=0xf000, CS.BASE= 0xffff0000,
> >CS.LIMIT=0xffff. So the execution begins at 0xfffffff0 where ROM is
> >mapped initially.
> 
> That impossible because 1) the processor starts in 16 bit mode so
> such an address cannot be generated 2) the processor has a20 held to
> zero which makes that the processor cannot generate a load to an
> address with the 20th bit set to anything but zero.
> 
That may seams to be impossible but it is how HW works. And this is how
QEMU emulates it. Look at target-i386/helper.c:cpu_reset()

    cpu_x86_load_seg_cache(env, R_CS, 0xf000, 0xffff0000, 0xffff,
                           DESC_P_MASK | DESC_S_MASK | DESC_CS_MASK |
                           DESC_R_MASK | DESC_A_MASK);

    env->eip = 0xfff0;

Don't know how a20 gate is handled btw.

> The CS base starts out at 0xf0000 and IP is 0xfff0.  That gives a
> real address of 0xffff0.  This is usually a trampoline to somewhere
> else in the space.
CS descriptor and CS selector don't have to be in sync (big real mode).

> 
> The mapping of BIOS to the top of 4GB is just a convention that
> modern BIOSes use because the legacy space isn't big enough for most
> modern BIOSes.
> 
> Regards,
> 
> Anthony Liguori
> 
> >>The VGABIOS is treated like any other option ROM and is initialized
> >>during option ROM scanning.
> >>
> >>Regards,
> >>
> >>Anthony Liguori
> >>
> >>>Any reply are appreciated. Thanks.
> >>>
> >>>Gavin
> >>>
> >>>
> >>>
> >>>
> >--
> >			Gleb.
> >

--
			Gleb.

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Anthony Liguori]

On 04/07/2011 10:51 AM, Gleb Natapov wrote:
> On Thu, Apr 07, 2011 at 10:42:56AM -0500, Anthony Liguori wrote:
>> On 04/07/2011 10:31 AM, Gleb Natapov wrote:
>>> On Thu, Apr 07, 2011 at 08:28:37AM -0500, Anthony Liguori wrote:
>>>> On 04/07/2011 03:22 AM, Bei Guan wrote:
>>>>> Hi,
>>>>>
>>>>> I have some questions about the qemu's bios. How does the QEMU
>>>>> load the binary files bios.bin and vgabios-cirrus.bin? Which
>>>>> function or code file need I to pay more attention to?
>>>>>
>>>>> For the loading of vgabios-cirrus.bin and bios.bin, I just trace
>>>>> them into the same funciton rom_add_file() in hw/loader.c. Is it
>>>>> the right function, which loads the bioses?
>>>>>
>>>>> And then another question, how qemu give the control to bios when
>>>>> the bios file is loaded? Maybe this question is not in the scope
>>>>> of qemu, however, can you give me some cue point.
>>>> I had some stuff written up locally so I posted it to the wiki at
>>>> http://wiki.qemu.org/Documentation/Platforms/PC
>>>>
>>>> The x86 architecture defines the initial state of the chip to have
>>>> the CS register have a base of 0xF000 and an IP of 0xFFF0.  The
>>>> result is that the actual memory address of the first instruction
>>>> falls at the end of the BIOS ROM segment.  This is the entry point
>>>> to the BIOS.
>>>>
>>> Actually after reset on x86 IP=0x0000fff0, CS=0xf000, CS.BASE= 0xffff0000,
>>> CS.LIMIT=0xffff. So the execution begins at 0xfffffff0 where ROM is
>>> mapped initially.
>> That impossible because 1) the processor starts in 16 bit mode so
>> such an address cannot be generated 2) the processor has a20 held to
>> zero which makes that the processor cannot generate a load to an
>> address with the 20th bit set to anything but zero.
>>
> That may seams to be impossible but it is how HW works. And this is how
> QEMU emulates it. Look at target-i386/helper.c:cpu_reset()
>
>      cpu_x86_load_seg_cache(env, R_CS, 0xf000, 0xffff0000, 0xffff,
>                             DESC_P_MASK | DESC_S_MASK | DESC_CS_MASK |
>                             DESC_R_MASK | DESC_A_MASK);
>
>      env->eip = 0xfff0;
>
> Don't know how a20 gate is handled btw.

I see that we use 0xf0000 in the kernel but this is because of a 
limitation of VMX.

I guess when 32-bit was introduced, this behavior was added.

>> The CS base starts out at 0xf0000 and IP is 0xfff0.  That gives a
>> real address of 0xffff0.  This is usually a trampoline to somewhere
>> else in the space.
> CS descriptor and CS selector don't have to be in sync (big real mode).

Indeed.

Regards,

Anthony Liguori

>> The mapping of BIOS to the top of 4GB is just a convention that
>> modern BIOSes use because the legacy space isn't big enough for most
>> modern BIOSes.
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>>> The VGABIOS is treated like any other option ROM and is initialized
>>>> during option ROM scanning.
>>>>
>>>> Regards,
>>>>
>>>> Anthony Liguori
>>>>
>>>>> Any reply are appreciated. Thanks.
>>>>>
>>>>> Gavin
>>>>>
>>>>>
>>>>>
>>>>>
>>> --
>>> 			Gleb.
>>>
> --
> 			Gleb.
>

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Jordan Justen]

On Thu, Apr 7, 2011 at 09:08, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 04/07/2011 10:51 AM, Gleb Natapov wrote:
>> That may seams to be impossible but it is how HW works. And this is how
>> QEMU emulates it. Look at target-i386/helper.c:cpu_reset()
>>
>>     cpu_x86_load_seg_cache(env, R_CS, 0xf000, 0xffff0000, 0xffff,
>>                            DESC_P_MASK | DESC_S_MASK | DESC_CS_MASK |
>>                            DESC_R_MASK | DESC_A_MASK);
>>
>>     env->eip = 0xfff0;
>>
>> Don't know how a20 gate is handled btw.
>
> I see that we use 0xf0000 in the kernel but this is because of a limitation
> of VMX.

I recently noticed that kvm does this.  It does not seem to be a big
deal as firmware can easily deal with it, but I did find it odd that
kvm had the csbase of 0xf0000 as processors generally use a csbase of
0xffff0000 initially.  (At least, this is what I've seen with Intel
processors for the past 12 years.)

How can this limitation exist with VMX if mode transitions are
supported, in which case this type of csbase vs. real-mode segment
mismatch can easily occur?

> I guess when 32-bit was introduced, this behavior was added.
>
>>> The CS base starts out at 0xf0000 and IP is 0xfff0.  That gives a
>>> real address of 0xffff0.  This is usually a trampoline to somewhere
>>> else in the space.
>>
>> CS descriptor and CS selector don't have to be in sync (big real mode).
>
> Indeed.

Another place this will often be seen is SMM, as the SMBASE can easily
be > 1MB, but the SMM entry is in 16 bit mode.

-Jordan

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Gleb Natapov]

On Thu, Apr 07, 2011 at 11:18:54AM -0700, Jordan Justen wrote:
> On Thu, Apr 7, 2011 at 09:08, Anthony Liguori <anthony@codemonkey.ws> wrote:
> > On 04/07/2011 10:51 AM, Gleb Natapov wrote:
> >> That may seams to be impossible but it is how HW works. And this is how
> >> QEMU emulates it. Look at target-i386/helper.c:cpu_reset()
> >>
> >>     cpu_x86_load_seg_cache(env, R_CS, 0xf000, 0xffff0000, 0xffff,
> >>                            DESC_P_MASK | DESC_S_MASK | DESC_CS_MASK |
> >>                            DESC_R_MASK | DESC_A_MASK);
> >>
> >>     env->eip = 0xfff0;
> >>
> >> Don't know how a20 gate is handled btw.
> >
> > I see that we use 0xf0000 in the kernel but this is because of a limitation
> > of VMX.
> 
> I recently noticed that kvm does this.  It does not seem to be a big
> deal as firmware can easily deal with it, but I did find it odd that
> kvm had the csbase of 0xf0000 as processors generally use a csbase of
> 0xffff0000 initially.  (At least, this is what I've seen with Intel
> processors for the past 12 years.)
> 
> How can this limitation exist with VMX if mode transitions are
> supported, in which case this type of csbase vs. real-mode segment
> mismatch can easily occur?
> 
VMX does not support real mode, so KVM uses vm86 to emulate real mode.
Vm86 does not support case when CS != CS.BASE >> 4, so KVM needs to
fall back to emulation if it occur. During mode transitions such
situation usually exist for only a couple of instructions. This is one
of the reasons why KVM does not support SMM.

Newest Intel CPUs support real mode in VMX BTW. It is called
"unrestricted guest" IIRC.

> > I guess when 32-bit was introduced, this behavior was added.
> >
> >>> The CS base starts out at 0xf0000 and IP is 0xfff0.  That gives a
> >>> real address of 0xffff0.  This is usually a trampoline to somewhere
> >>> else in the space.
> >>
> >> CS descriptor and CS selector don't have to be in sync (big real mode).
> >
> > Indeed.
> 
> Another place this will often be seen is SMM, as the SMBASE can easily
> be > 1MB, but the SMM entry is in 16 bit mode.
> 
> -Jordan

--
			Gleb.

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Anthony Liguori]

On 04/07/2011 01:18 PM, Jordan Justen wrote:
> On Thu, Apr 7, 2011 at 09:08, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>> On 04/07/2011 10:51 AM, Gleb Natapov wrote:
>>> That may seams to be impossible but it is how HW works. And this is how
>>> QEMU emulates it. Look at target-i386/helper.c:cpu_reset()
>>>
>>>      cpu_x86_load_seg_cache(env, R_CS, 0xf000, 0xffff0000, 0xffff,
>>>                             DESC_P_MASK | DESC_S_MASK | DESC_CS_MASK |
>>>                             DESC_R_MASK | DESC_A_MASK);
>>>
>>>      env->eip = 0xfff0;
>>>
>>> Don't know how a20 gate is handled btw.
>> I see that we use 0xf0000 in the kernel but this is because of a limitation
>> of VMX.
> I recently noticed that kvm does this.  It does not seem to be a big
> deal as firmware can easily deal with it, but I did find it odd that
> kvm had the csbase of 0xf0000 as processors generally use a csbase of
> 0xffff0000 initially.  (At least, this is what I've seen with Intel
> processors for the past 12 years.)
>
> How can this limitation exist with VMX if mode transitions are
> supported, in which case this type of csbase vs. real-mode segment
> mismatch can easily occur?

Mismatches between cached segment descriptors and the segment registers 
are not problematic in KVM per say.

The issue is that vm8086 mode doesn't allow for this and since KVM uses 
vm8086 to emulate real mode on processors that don't support whatever it 
is that Intel is calling it these days, we can't effectively support this.

>> I guess when 32-bit was introduced, this behavior was added.
>>
>>>> The CS base starts out at 0xf0000 and IP is 0xfff0.  That gives a
>>>> real address of 0xffff0.  This is usually a trampoline to somewhere
>>>> else in the space.
>>> CS descriptor and CS selector don't have to be in sync (big real mode).
>> Indeed.
> Another place this will often be seen is SMM, as the SMBASE can easily
> be>  1MB, but the SMM entry is in 16 bit mode.

KVM doesn't support SMM although that's not because of this.  KVM 
doesn't allow execution of ROM memory which makes it difficult to 
implement PAM in the way it's intended to be implemented.  This makes 
SMM a bit tricky to make work.  Since there's never really been a 
pressing need to support SMM, to my knowledge, noone has even tried.

Regards,

Anthony Liguori

> -Jordan
>

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Gleb Natapov]

On Thu, Apr 07, 2011 at 01:37:14PM -0500, Anthony Liguori wrote:
> >>>>The CS base starts out at 0xf0000 and IP is 0xfff0.  That gives a
> >>>>real address of 0xffff0.  This is usually a trampoline to somewhere
> >>>>else in the space.
> >>>CS descriptor and CS selector don't have to be in sync (big real mode).
> >>Indeed.
> >Another place this will often be seen is SMM, as the SMBASE can easily
> >be>  1MB, but the SMM entry is in 16 bit mode.
> 
> KVM doesn't support SMM although that's not because of this.  KVM
> doesn't allow execution of ROM memory which makes it difficult to
> implement PAM in the way it's intended to be implemented.  This
> makes SMM a bit tricky to make work.  Since there's never really
> been a pressing need to support SMM, to my knowledge, noone has even
> tried.
> 
KVM allows to execute ROM memory (BIOS and option roms run this way). It
just makes it indistinguishable from RAM, but read only memory slot
support shouldn't be too hard. Why ability to execute ROM memory is
needed to support SMM though?

--
			Gleb.

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Jordan Justen]

On Thu, Apr 7, 2011 at 11:44, Gleb Natapov <gleb@redhat.com> wrote:
> On Thu, Apr 07, 2011 at 01:37:14PM -0500, Anthony Liguori wrote:
>> >>>>The CS base starts out at 0xf0000 and IP is 0xfff0.  That gives a
>> >>>>real address of 0xffff0.  This is usually a trampoline to somewhere
>> >>>>else in the space.
>> >>>CS descriptor and CS selector don't have to be in sync (big real mode).
>> >>Indeed.
>> >Another place this will often be seen is SMM, as the SMBASE can easily
>> >be>  1MB, but the SMM entry is in 16 bit mode.
>>
>> KVM doesn't support SMM although that's not because of this.  KVM
>> doesn't allow execution of ROM memory which makes it difficult to
>> implement PAM in the way it's intended to be implemented.  This
>> makes SMM a bit tricky to make work.  Since there's never really
>> been a pressing need to support SMM, to my knowledge, noone has even
>> tried.
>>
> KVM allows to execute ROM memory (BIOS and option roms run this way). It
> just makes it indistinguishable from RAM, but read only memory slot
> support shouldn't be too hard. Why ability to execute ROM memory is
> needed to support SMM though?

True.

The only possible requirement is to 'hide SMRAM' when not in SMM mode.
 Even this is chipset specific, and arguable depending on the goals of
SMM support in that system.  (Although, generally, hiding SMRAM is a
requirement. :)

But, Anthony's point ('there's never really been a pressing need to
support SMM') is probably the most important here, as I can't see a
compelling use for SMM in QEMU.

-Jordan

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Gleb Natapov]

On Thu, Apr 07, 2011 at 12:03:41PM -0700, Jordan Justen wrote:
> On Thu, Apr 7, 2011 at 11:44, Gleb Natapov <gleb@redhat.com> wrote:
> > On Thu, Apr 07, 2011 at 01:37:14PM -0500, Anthony Liguori wrote:
> >> >>>>The CS base starts out at 0xf0000 and IP is 0xfff0.  That gives a
> >> >>>>real address of 0xffff0.  This is usually a trampoline to somewhere
> >> >>>>else in the space.
> >> >>>CS descriptor and CS selector don't have to be in sync (big real mode).
> >> >>Indeed.
> >> >Another place this will often be seen is SMM, as the SMBASE can easily
> >> >be>  1MB, but the SMM entry is in 16 bit mode.
> >>
> >> KVM doesn't support SMM although that's not because of this.  KVM
> >> doesn't allow execution of ROM memory which makes it difficult to
> >> implement PAM in the way it's intended to be implemented.  This
> >> makes SMM a bit tricky to make work.  Since there's never really
> >> been a pressing need to support SMM, to my knowledge, noone has even
> >> tried.
> >>
> > KVM allows to execute ROM memory (BIOS and option roms run this way). It
> > just makes it indistinguishable from RAM, but read only memory slot
> > support shouldn't be too hard. Why ability to execute ROM memory is
> > needed to support SMM though?
> 
> True.
> 
> The only possible requirement is to 'hide SMRAM' when not in SMM mode.
>  Even this is chipset specific, and arguable depending on the goals of
> SMM support in that system.  (Although, generally, hiding SMRAM is a
> requirement. :)
> 
> But, Anthony's point ('there's never really been a pressing need to
> support SMM') is probably the most important here, as I can't see a
> compelling use for SMM in QEMU.
> 
Yeah, that is probably the main reason. Although lately there was a
proposition to use SMM in seabios to access MMIO bar of USB device from
16bit mode. Do not remember details exactly. But I, personally, will be
very glad to not implement SMM support for KVM ;)

--
			Gleb.

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Olivier Galibert]

On Thu, Apr 07, 2011 at 12:03:41PM -0700, Jordan Justen wrote:
> But, Anthony's point ('there's never really been a pressing need to
> support SMM') is probably the most important here, as I can't see a
> compelling use for SMM in QEMU.

Running real biosen instead of seabios?  Of course that's mostly
useful when reverse-engineering devices, which is a borderline use of
kvm.

  OG.

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Jordan Justen]

On Thu, Apr 7, 2011 at 12:24, Olivier Galibert <galibert@pobox.com> wrote:
> On Thu, Apr 07, 2011 at 12:03:41PM -0700, Jordan Justen wrote:
>> But, Anthony's point ('there's never really been a pressing need to
>> support SMM') is probably the most important here, as I can't see a
>> compelling use for SMM in QEMU.
>
> Running real biosen instead of seabios?  Of course that's mostly
> useful when reverse-engineering devices, which is a borderline use of
> kvm.

:)

Regarding QEMU, the only thing I can thing of (and this is a stretch)
is USB legacy support.  In other words, being able to drop PS2
keyboard/mouse for USB, but still supporting legacy software via SMM.
This doesn't seem worth the effort by a long shot.

Another take on removing PS2 sounds more interesting to me: a
legacy-free PC qemu hardware skew, with a legacy-free firmware (OVMF
:) and only supporting legacy-free compatible OS's.

-Jordan

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Anthony Liguori]

On 04/07/2011 01:44 PM, Gleb Natapov wrote:
>> KVM doesn't support SMM although that's not because of this.  KVM
>> doesn't allow execution of ROM memory which makes it difficult to
>> implement PAM in the way it's intended to be implemented.  This
>> makes SMM a bit tricky to make work.  Since there's never really
>> been a pressing need to support SMM, to my knowledge, noone has even
>> tried.
>>
> KVM allows to execute ROM memory (BIOS and option roms run this way). It
> just makes it indistinguishable from RAM, but read only memory slot
> support shouldn't be too hard. Why ability to execute ROM memory is
> needed to support SMM though?

QEMU does the leg work already to support SMM.  It doesn't work with KVM 
because we treat SMM as ROM memory and trap read/write access.

To make it work with KVM, you'd have to hack things around to switch the 
VGA space to RAM in order to the let the SMM code run.  It's not 
impossible, but that's the main reason it doesn't Just Work.

Regards,

Anthony Liguori

> --
> 			Gleb.
>

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Gleb Natapov]

On Thu, Apr 07, 2011 at 02:21:16PM -0500, Anthony Liguori wrote:
> On 04/07/2011 01:44 PM, Gleb Natapov wrote:
> >>KVM doesn't support SMM although that's not because of this.  KVM
> >>doesn't allow execution of ROM memory which makes it difficult to
> >>implement PAM in the way it's intended to be implemented.  This
> >>makes SMM a bit tricky to make work.  Since there's never really
> >>been a pressing need to support SMM, to my knowledge, noone has even
> >>tried.
> >>
> >KVM allows to execute ROM memory (BIOS and option roms run this way). It
> >just makes it indistinguishable from RAM, but read only memory slot
> >support shouldn't be too hard. Why ability to execute ROM memory is
> >needed to support SMM though?
> 
> QEMU does the leg work already to support SMM.  It doesn't work with
> KVM because we treat SMM as ROM memory and trap read/write access.
> 
> To make it work with KVM, you'd have to hack things around to switch
> the VGA space to RAM in order to the let the SMM code run.  It's not
> impossible, but that's the main reason it doesn't Just Work.
> 
Remapping part is easy. As you are saying QEMU already does remapping,
the only thing missing is creating/destroying/remapping KVM memory slot
(with SMP it is slightly more complicated, but doable). But after doing
this SMM will not Just Work in KVM on Intel because VMX does not support
SMM mode and it can't be approximated by vm86, so KVM will have to emulate
every single instruction while in SMM mode and this like will not work.

--
			Gleb.

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Anthony Liguori]

On 04/07/2011 02:31 PM, Gleb Natapov wrote:
>
> Remapping part is easy. As you are saying QEMU already does remapping,

Yes.

> the only thing missing is creating/destroying/remapping KVM memory slot
> (with SMP it is slightly more complicated, but doable).

Yup.  It's not impossible but not free.

>   But after doing
> this SMM will not Just Work in KVM on Intel because VMX does not support
> SMM mode and it can't be approximated by vm86, so KVM will have to emulate
> every single instruction while in SMM mode and this like will not work.

Isn't everyone using Westmere's at this point with unrestricted guest 
mode :-)

BTW, I assume that there's some kernel logic needed to enable SMM 
intercepts but I'm not entirely sure what's involved there.

Regards,

Anthony Liguori

> --
> 			Gleb.
>

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Gleb Natapov]

On Thu, Apr 07, 2011 at 04:34:38PM -0500, Anthony Liguori wrote:
> On 04/07/2011 02:31 PM, Gleb Natapov wrote:
> >
> >Remapping part is easy. As you are saying QEMU already does remapping,
> 
> Yes.
> 
> >the only thing missing is creating/destroying/remapping KVM memory slot
> >(with SMP it is slightly more complicated, but doable).
> 
> Yup.  It's not impossible but not free.
> 
> >  But after doing
> >this SMM will not Just Work in KVM on Intel because VMX does not support
> >SMM mode and it can't be approximated by vm86, so KVM will have to emulate
> >every single instruction while in SMM mode and this like will not work.
> 
> Isn't everyone using Westmere's at this point with unrestricted
> guest mode :-)
> 
> BTW, I assume that there's some kernel logic needed to enable SMM
> intercepts but I'm not entirely sure what's involved there.
> 
Vcpu needs to know that it is in SMM mode and memory slot logic should
be changed to lookup slots according to vcpu mode. This is needed
because the same physical address can be treated as frame buffer by one
cpu and as a regular memory by other simultaneously in SMP system.

--
			Gleb.

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Jordan Justen]

On Thu, Apr 7, 2011 at 12:21, Anthony Liguori <anthony@codemonkey.ws> wrote:
> QEMU does the leg work already to support SMM.  It doesn't work with KVM
> because we treat SMM as ROM memory and trap read/write access.
>
> To make it work with KVM, you'd have to hack things around to switch the VGA
> space to RAM in order to the let the SMM code run.  It's not impossible, but
> that's the main reason it doesn't Just Work.

Ah, SMM ASEG/BSEG?  I think most recent firmware ignore that, use TSEG
(some higher up memory) and run in protected mode.

But, based on Gleb's other response, there are other, bigger issues as well...

-Jordan

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[malc]

On Thu, 7 Apr 2011, Anthony Liguori wrote:

> On 04/07/2011 10:31 AM, Gleb Natapov wrote:
> > On Thu, Apr 07, 2011 at 08:28:37AM -0500, Anthony Liguori wrote:
> > > On 04/07/2011 03:22 AM, Bei Guan wrote:
> > > > Hi,
> > > > 
> > > > I have some questions about the qemu's bios. How does the QEMU
> > > > load the binary files bios.bin and vgabios-cirrus.bin? Which
> > > > function or code file need I to pay more attention to?
> > > > 
> > > > For the loading of vgabios-cirrus.bin and bios.bin, I just trace
> > > > them into the same funciton rom_add_file() in hw/loader.c. Is it
> > > > the right function, which loads the bioses?
> > > > 
> > > > And then another question, how qemu give the control to bios when
> > > > the bios file is loaded? Maybe this question is not in the scope
> > > > of qemu, however, can you give me some cue point.
> > > I had some stuff written up locally so I posted it to the wiki at
> > > http://wiki.qemu.org/Documentation/Platforms/PC
> > > 
> > > The x86 architecture defines the initial state of the chip to have
> > > the CS register have a base of 0xF000 and an IP of 0xFFF0.  The
> > > result is that the actual memory address of the first instruction
> > > falls at the end of the BIOS ROM segment.  This is the entry point
> > > to the BIOS.
> > > 
> > Actually after reset on x86 IP=0x0000fff0, CS=0xf000, CS.BASE= 0xffff0000,
> > CS.LIMIT=0xffff. So the execution begins at 0xfffffff0 where ROM is
> > mapped initially.
> 
> That impossible because 1) the processor starts in 16 bit mode so such an
> address cannot be generated 2) the processor has a20 held to zero which makes
> that the processor cannot generate a load to an address with the 20th bit set
> to anything but zero.

It starts in big-real mode so only a20 can be a limiting factor..

> 
> The CS base starts out at 0xf0000 and IP is 0xfff0.  That gives a real address
> of 0xffff0.  This is usually a trampoline to somewhere else in the space.
> 
> The mapping of BIOS to the top of 4GB is just a convention that modern BIOSes
> use because the legacy space isn't big enough for most modern BIOSes.
> 
> Regards,
> 
> Anthony Liguori
> 
> > > The VGABIOS is treated like any other option ROM and is initialized
> > > during option ROM scanning.
> > > 
> > > Regards,
> > > 
> > > Anthony Liguori
> > > 
> > > > Any reply are appreciated. Thanks.
> > > > 
> > > > Gavin
> > > > 
> > > > 
> > > > 
> > > > 
> > --
> > 			Gleb.
> > 
> 
> 

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Bei Guan]

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

2011/4/7 Anthony Liguori <anthony@codemonkey.ws>

> On 04/07/2011 03:22 AM, Bei Guan wrote:
>
>> Hi,
>>
>> I have some questions about the qemu's bios. How does the QEMU load the
>> binary files bios.bin and vgabios-cirrus.bin? Which function or code file
>> need I to pay more attention to?
>>
>> For the loading of vgabios-cirrus.bin and bios.bin, I just trace them into
>> the same funciton rom_add_file() in hw/loader.c. Is it the right function,
>> which loads the bioses?
>>
>> And then another question, how qemu give the control to bios when the bios
>> file is loaded? Maybe this question is not in the scope of qemu, however,
>> can you give me some cue point.
>>
>
> I had some stuff written up locally so I posted it to the wiki at
> http://wiki.qemu.org/Documentation/Platforms/PC


Thanks for this detailed description. Is it to say that if we want to boot a
BIOS (such as SeaBIOS), we must need to initialize the Memory ranged from
0x00000 to 0xF0000, which includes DOS Memory Area, Video Memory, ISA
Extension ROM and BIOS Extension ROM, with the information needed by BIOS?

Another question is that in the QEMU, does all the information of the
emulated hardware have to be filled in the memory layout before the SeaBIOS
boot? And after it booting, the BIOS can do everything to boot the Operating
System. This phase (BIOS runing) doesn't need any interaction with QEMU. Is
it?

Thanks.
Gavin



>
>
> The x86 architecture defines the initial state of the chip to have the CS
> register have a base of 0xF000 and an IP of 0xFFF0.  The result is that the
> actual memory address of the first instruction falls at the end of the BIOS
> ROM segment.  This is the entry point to the BIOS.
>
> The VGABIOS is treated like any other option ROM and is initialized during
> option ROM scanning.
>
> Regards,
>
> Anthony Liguori
>
>
>  Any reply are appreciated. Thanks.
>>
>> Gavin
>>
>>
>>
>>
>>
>

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

Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?

[Bei Guan]

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

2011/4/8 Bei Guan <gbtju85@gmail.com>

>
>
> 2011/4/7 Anthony Liguori <anthony@codemonkey.ws>
>
>> On 04/07/2011 03:22 AM, Bei Guan wrote:
>>
>>> Hi,
>>>
>>> I have some questions about the qemu's bios. How does the QEMU load the
>>> binary files bios.bin and vgabios-cirrus.bin? Which function or code file
>>> need I to pay more attention to?
>>>
>>> For the loading of vgabios-cirrus.bin and bios.bin, I just trace them
>>> into the same funciton rom_add_file() in hw/loader.c. Is it the right
>>> function, which loads the bioses?
>>>
>>> And then another question, how qemu give the control to bios when the
>>> bios file is loaded? Maybe this question is not in the scope of qemu,
>>> however, can you give me some cue point.
>>>
>>
>> I had some stuff written up locally so I posted it to the wiki at
>> http://wiki.qemu.org/Documentation/Platforms/PC
>
>
> Thanks for this detailed description. Is it to say that if we want to boot
> a BIOS (such as SeaBIOS), we must need to initialize the Memory ranged from
> 0x00000 to 0xF0000, which includes DOS Memory Area, Video Memory, ISA
> Extension ROM and BIOS Extension ROM, with the information needed by BIOS?
>
Is this Memory Layout all the same for all the BIOS booting? I mean that if
we port another BIOS, do will need to modify the the codes of filling
information into this Memory Layout?

Thanks,
Gavin



>
> Another question is that in the QEMU, does all the information of the
> emulated hardware have to be filled in the memory layout before the SeaBIOS
> boot? And after it booting, the BIOS can do everything to boot the Operating
> System. This phase (BIOS runing) doesn't need any interaction with QEMU. Is
> it?
>
> Thanks.
> Gavin
>
>
>
>>
>>
>> The x86 architecture defines the initial state of the chip to have the CS
>> register have a base of 0xF000 and an IP of 0xFFF0.  The result is that the
>> actual memory address of the first instruction falls at the end of the BIOS
>> ROM segment.  This is the entry point to the BIOS.
>>
>> The VGABIOS is treated like any other option ROM and is initialized during
>> option ROM scanning.
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>
>>  Any reply are appreciated. Thanks.
>>>
>>> Gavin
>>>
>>>
>>>
>>>
>>>
>>
>

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