Re: [PATCH 1/3] Update BIOS INT15-E820 to allow a larger BIOS image

[Marcelo Tosatti <mtosatti@redhat.com>]

On Tue, Jul 28, 2009 at 09:51:26AM -0700, Jordan Justen wrote:
> On Tue, Jul 28, 2009 at 7:40 AM, Marcelo Tosatti<mtosatti@redhat.com> wrote:
> > On Sun, Jul 26, 2009 at 05:23:51PM -0700, Jordan Justen wrote:
> >> The bios will now reserve more memory via the E820 functions.
> >>
> >> Note that the standard KVM BIOS will most likely not make use of
> >> this expanded BIOS region.  This change will synchronize
> >> the BIOS INT15-E820 reservations to match other changes that
> >> will allow alternate BIOS images to be larger in size.
> >>
> >> Previously the BIOS reserved:
> >>   0xfffbc000-0xfffbcfff -   4KB - EPT identity mapping pages
> >>   0xfffbd000-0xfffbffff -  12KB - TSS pages
> >>   0xfffc0000-0xffffffff - 256KB - Max bios.bin (usually top 128KB is used)
> >>
> >> Now the BIOS will reserve:
> >>   0xfeffc000-0xfeffcfff -   4KB - EPT identity mapping pages
> >>   0xfeffd000-0xfeffffff -  12KB - TSS Pages
> >>   0xff000000-0xffffffff -  16MB - Max bios.bin
> >>
> >> Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
> >> ---
> >>  kvm/bios/rombios.c |    8 ++++----
> >>  1 files changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/kvm/bios/rombios.c b/kvm/bios/rombios.c
> >> index 6186199..2d0c153 100644
> >> --- a/kvm/bios/rombios.c
> >> +++ b/kvm/bios/rombios.c
> >> @@ -4596,14 +4596,14 @@ ASM_END
> >>                      case 5:
> >>                          /* 4 pages before the bios, 3 pages for vmx tss pages,
> >>                        * the other page for EPT real mode pagetable */
> >> -                        set_e820_range(ES, regs.u.r16.di, 0xfffbc000L,
> >> -                                       0xfffc0000L, 0, 0, 2);
> >> +                        set_e820_range(ES, regs.u.r16.di, 0xfeffc000L,
> >> +                                       0xff000000L, 0, 0, 2);
> >>                          regs.u.r32.ebx = 6;
> >
> > So if you use an older kernel, and the kvm_set_identity_map_addr fails,
> > you get the e820 entry wrong right? Perhaps you should use the hw/fw_cfg.c
> > interface to communicate with the BIOS.
> >
> 
> If you use this newer BIOS code with the older kernel code, the
> expanded E820 BIOS region of the will cover the older region where the
> EPT page tables are at.  So, the OS will still know to keep away from
> this region.
> 
> There should be no impact if someone uses a newer qemu-kvm with and
> older kvm module.  Since the normal legacy kvm BIOS is only 128KB, it
> will be able to boot fine.  (There will be no conflict with reserving
> the memory region for the small BIOS.)  If a bios.bin is used that is
> larger than 256KB, then it will fail in the same way as today, since
> there will be a conflict while trying to reserve the 0xfffbc000 -
> 0xfffbcfff region.
> 
> The only difference in this case would be that E820 reserves a larger
> chunk of memory space, but I can't see how this could cause a problem.
>  (Previously kvm-bios would reserve 256KB while the BIOS was normally
> only 128KB in size.)

Indeed. Looks good to me.

> 
> >
> >>                          break;
> >>                      case 6:
> >> -                        /* 256KB BIOS area at the end of 4 GB */
> >> +                        /* 16MB BIOS area at the end of 4 GB */
> >>                          set_e820_range(ES, regs.u.r16.di,
> >> -                                       0xfffc0000L, 0x00000000L ,0, 0, 2);
> >> +                                       0xff000000L, 0x00000000L ,0, 0, 2);
> >>                          if (extra_highbits_memory_size || extra_lowbits_memory_size)
> >>                              regs.u.r32.ebx = 7;
> >>                          else
> >> --
> >> 1.6.0.4
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe kvm" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >