[PATCH 0/5] bios: >4G updates

[PATCH 0/5] bios: >4G updates

[Alex Williamson]

As requested, here's the follow-on to the >4G MTRR changes split into
functional bits.

[1/5] Rename variables to reflect what they're really reporting
[2/5] Reformat ram_probe() to match the rest of the code
[3/5] Add SMBIOS info for memory above 4G
[4/5] Fix the SMBIOS type 19 & 20 range end address
[5/5] Optional - switch default MTRR type to WB and only cover MMIO

I've taken some liberties renaming and reformatting, if we'd rather not
introduce too many extraneous changes, I can drop those.  The SMBIOS
changes seem to work up to 32767MB, then we hit a limitation in the type
17 table only providing 15bits for the size.  We might need to describe
multiple virtual DIMMs to get around that, but it's a separate issue.

The final patch is optional and switches over to make the variable MTRRs
only describe the MMIO hole, leaving the rest of the address space
default to WB.  I can't say I fully understand the implications of
hotplug memory for this scenario.  Let me know if there are comments.
Thanks,

Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.

Re: [PATCH 0/5] bios: >4G updates

[Avi Kivity]

Alex Williamson wrote:
> As requested, here's the follow-on to the >4G MTRR changes split into
> functional bits.
>
> [1/5] Rename variables to reflect what they're really reporting
> [2/5] Reformat ram_probe() to match the rest of the code
> [3/5] Add SMBIOS info for memory above 4G
> [4/5] Fix the SMBIOS type 19 & 20 range end address
> [5/5] Optional - switch default MTRR type to WB and only cover MMIO
>
> I've taken some liberties renaming and reformatting, if we'd rather not
> introduce too many extraneous changes, I can drop those.  The SMBIOS
> changes seem to work up to 32767MB, then we hit a limitation in the type
> 17 table only providing 15bits for the size.  We might need to describe
> multiple virtual DIMMs to get around that, but it's a separate issue.
>
> The final patch is optional and switches over to make the variable MTRRs
> only describe the MMIO hole, leaving the rest of the address space
> default to WB.  I can't say I fully understand the implications of
> hotplug memory for this scenario.  Let me know if there are comments.
>   

The patches all look good, however renaming and reformatting will lead 
to merge headaches later on.  We haven't been good at working with bochs 
bios upstream.

Can you peek in bochs upstream and see if it's worth merging?  If not, 
I'll just merge these patches.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH 0/5] bios: >4G updates

[Alex Williamson]

On Wed, 2008-09-24 at 14:07 +0300, Avi Kivity wrote:
> 
> The patches all look good, however renaming and reformatting will lead 
> to merge headaches later on.  We haven't been good at working with bochs 
> bios upstream.
> 
> Can you peek in bochs upstream and see if it's worth merging?  If not, 
> I'll just merge these patches.

I'll take a look.  It seemed like they added support for putting the
ACPI processor objects in an SSDT last I checked, but the AML for their
processors is fairly trivial.  I'll see if there's anything else
worthwhile.  Thanks,

Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.

Re: Re: [PATCH 0/5] bios: >4G updates

[Alex Williamson]

On Wed, 2008-09-24 at 10:17 -0600, Alex Williamson wrote:
> On Wed, 2008-09-24 at 14:07 +0300, Avi Kivity wrote:
> > 
> > The patches all look good, however renaming and reformatting will lead 
> > to merge headaches later on.  We haven't been good at working with bochs 
> > bios upstream.
> > 
> > Can you peek in bochs upstream and see if it's worth merging?  If not, 
> > I'll just merge these patches.
> 
> I'll take a look.  It seemed like they added support for putting the
> ACPI processor objects in an SSDT last I checked, but the AML for their
> processors is fairly trivial.  I'll see if there's anything else
> worthwhile.  Thanks,

I guess the SSDT support was prior to the last merge, and appropriately
dropped.  The most interesting new feature is a boot menu to allow the
user to override the boot device.  That seems pretty useful.  Other
things like better printing of the devices and support for PIIX4 could
come in handy too.  So yeah, it looks worth merging.  I can drop my
first two patches and rework the others so we don't cause unnecessary
merge problems.

Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.

Re: Re: [PATCH 0/5] bios: >4G updates

[Avi Kivity]

Alex Williamson wrote:
> I guess the SSDT support was prior to the last merge, and appropriately
> dropped.  The most interesting new feature is a boot menu to allow the
> user to override the boot device.  That seems pretty useful.  Other
> things like better printing of the devices and support for PIIX4 could
> come in handy too.  So yeah, it looks worth merging.  I can drop my
> first two patches and rework the others so we don't cause unnecessary
> merge problems.
>   

I tried to merge it, but it the new bios won't boot.  I traced this to 
ata_reset: it toggles the soft reset bit in the command register and 
expects to see the busy bit set, but the ide device model returns zero 
status if the selected device has no drive.

No idea if the device model or the bios is wrong.

If anyone (hi Gleb) wants to take a look, it's in the branch bios-merge 
on git.kernel.org.

btw, commenting this out leads to boot failure as well, but that may be 
related.

-- 
error compiling committee.c: too many arguments to function

Re: Re: [PATCH 0/5] bios: >4G updates

[Avi Kivity]

Avi Kivity wrote:
>
> I tried to merge it, but it the new bios won't boot.  I traced this to 
> ata_reset: it toggles the soft reset bit in the command register and 
> expects to see the busy bit set, but the ide device model returns zero 
> status if the selected device has no drive.
>
> No idea if the device model or the bios is wrong.
>
> If anyone (hi Gleb) wants to take a look, it's in the branch 
> bios-merge on git.kernel.org.
>
> btw, commenting this out leads to boot failure as well, but that may 
> be related.
>

Okay, I think I have it -- the bios code was using .org to set certain 
entry points to well known addresses, and one code section overflowed 
due to enabling the cache, which is a kvm addition.  Moving that bit 
out-of-line allows the bios to boot.


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: Re: [PATCH 0/5] bios: >4G updates

[Avi Kivity]

Avi Kivity wrote:
> Avi Kivity wrote:
>>
>> I tried to merge it, but it the new bios won't boot.  I traced this 
>> to ata_reset: it toggles the soft reset bit in the command register 
>> and expects to see the busy bit set, but the ide device model returns 
>> zero status if the selected device has no drive.
>>
>> No idea if the device model or the bios is wrong.
>>
>> If anyone (hi Gleb) wants to take a look, it's in the branch 
>> bios-merge on git.kernel.org.
>>
>> btw, commenting this out leads to boot failure as well, but that may 
>> be related.
>>
>
> Okay, I think I have it -- the bios code was using .org to set certain 
> entry points to well known addresses, and one code section overflowed 
> due to enabling the cache, which is a kvm addition.  Moving that bit 
> out-of-line allows the bios to boot.
>

It works, so I pushed it out.  Alex, can you rebase your bios patches on 
top of current HEAD?

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: Re: [PATCH 0/5] bios: >4G updates

[Alex Williamson]

On Tue, 2008-09-30 at 19:46 +0300, Avi Kivity wrote:
> Avi Kivity wrote:
> > Okay, I think I have it -- the bios code was using .org to set
> certain 
> > entry points to well known addresses, and one code section
> overflowed 
> > due to enabling the cache, which is a kvm addition.  Moving that
> bit 
> > out-of-line allows the bios to boot.
> >
> 
> It works, so I pushed it out.  Alex, can you rebase your bios patches
> on 
> top of current HEAD?

I updated and resent the first patch in the 4 patch follow-on to this
one.  The remaining 3 patches still apply cleanly.  I think Sheng was
going to send out a patch to better follow the SDM when changing the
MTRRs, but the first 3 patches are independent of that.  Thanks,

Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.

Re: Re: [PATCH 0/5] bios: >4G updates

[Avi Kivity]

Alex Williamson wrote:
>> It works, so I pushed it out.  Alex, can you rebase your bios patches
>> on 
>> top of current HEAD?
>>     
>
> I updated and resent the first patch in the 4 patch follow-on to this
> one.  The remaining 3 patches still apply cleanly.  I think Sheng was
> going to send out a patch to better follow the SDM when changing the
> MTRRs, but the first 3 patches are independent of that.  Thanks,
>
>   

Applied all, thanks.

-- 
error compiling committee.c: too many arguments to function

Re: Re: [PATCH 0/5] bios: >4G updates

[Kevin O'Connor]

Hi,

On Thu, Oct 02, 2008 at 03:33:58PM +0300, Avi Kivity wrote:
> Alex Williamson wrote:
>>> It works, so I pushed it out.  Alex, can you rebase your bios patches
>>> on top of current HEAD?
>>>     
>>
>> I updated and resent the first patch in the 4 patch follow-on to this
>> one.  The remaining 3 patches still apply cleanly.  I think Sheng was
>> going to send out a patch to better follow the SDM when changing the
>> MTRRs, but the first 3 patches are independent of that.  Thanks,
>>
>>   
>
> Applied all, thanks.

As an aside, is there any interest in using SeaBIOS with kvm?

SeaBIOS is a port of bochs bios to gcc.  I've been using SeaBIOS
(along with coreboot) to boot and provide bios functions on real
hardware.  It works fine under qemu also.

I looked at the changes that kvm has in its local bochs bios repo.
Most of the code is the same, however I noticed a number of msr
settings which I didn't fully understand.

If there is interest, the source code repository can be pulled by
running:

git clone git://git.linuxtogo.org/home/seabios.git

There is a git browser at:

http://git.linuxtogo.org/?p=kevin/seabios.git;a=summary

And some precompiled binaries at:

http://linuxtogo.org/~kevin/SeaBIOS/

Thoughts?
-Kevin

Re: Re: [PATCH 0/5] bios: >4G updates

[Gleb Natapov]

On Sun, Oct 12, 2008 at 06:50:06PM -0400, Kevin O'Connor wrote:
> Hi,
> 
> On Thu, Oct 02, 2008 at 03:33:58PM +0300, Avi Kivity wrote:
> > Alex Williamson wrote:
> >>> It works, so I pushed it out.  Alex, can you rebase your bios patches
> >>> on top of current HEAD?
> >>>     
> >>
> >> I updated and resent the first patch in the 4 patch follow-on to this
> >> one.  The remaining 3 patches still apply cleanly.  I think Sheng was
> >> going to send out a patch to better follow the SDM when changing the
> >> MTRRs, but the first 3 patches are independent of that.  Thanks,
> >>
> >>   
> >
> > Applied all, thanks.
> 
> As an aside, is there any interest in using SeaBIOS with kvm?
> 
There is a great interest. I just don't know time frame for this. Avi?

--
			Gleb.

Re: Re: [PATCH 0/5] bios: >4G updates

[Avi Kivity]

>> As an aside, is there any interest in using SeaBIOS with kvm?
>>
>>     
> There is a great interest. I just don't know time frame for this. Avi?
>   

I'd like the seabios repository to be a git submodule, so we don't have
to rewrite stuff.  So I'll experiment a bit with git submodules and pull
it in soon.

Kevin, will you accept qemu-specific and kvm-specific patches to
SeaBIOS?  I'd like to avoid permanent deltas.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: Re: [PATCH 0/5] bios: >4G updates

[Anthony Liguori]

Avi Kivity wrote:
>>> As an aside, is there any interest in using SeaBIOS with kvm?
>>>
>>>     
>>>       
>> There is a great interest. I just don't know time frame for this. Avi?
>>   
>>     
>
> I'd like the seabios repository to be a git submodule, so we don't have
> to rewrite stuff.  So I'll experiment a bit with git submodules and pull
> it in soon.
>
> Kevin, will you accept qemu-specific and kvm-specific patches to
> SeaBIOS?  I'd like to avoid permanent deltas.
>   

Are you willing to do a flag day and switch from the Bochs BIOS to 
seabios and deal with the regressions?  If so, we should coordinate this 
and do the same thing in QEMU.

Regards,

Anthony Liguori

Re: Re: [PATCH 0/5] bios: >4G updates

[Avi Kivity]

Anthony Liguori wrote:
>>
>> I'd like the seabios repository to be a git submodule, so we don't have
>> to rewrite stuff.  So I'll experiment a bit with git submodules and pull
>> it in soon.
>>
>
> Are you willing to do a flag day and switch from the Bochs BIOS to
> seabios and deal with the regressions?  If so, we should coordinate
> this and do the same thing in QEMU.

I was thinking, side-by-side for a couple of weeks to let issues be
worked out, then switch the default to SeaBIOS until the remaining bugs
are killed, then remove the bochs bios.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: Re: [PATCH 0/5] bios: >4G updates

[Glauber Costa]

On Tue, Oct 14, 2008 at 2:17 PM, Avi Kivity <avi@redhat.com> wrote:
> Anthony Liguori wrote:
>>>
>>> I'd like the seabios repository to be a git submodule, so we don't have
>>> to rewrite stuff.  So I'll experiment a bit with git submodules and pull
>>> it in soon.
>>>
>>
>> Are you willing to do a flag day and switch from the Bochs BIOS to
>> seabios and deal with the regressions?  If so, we should coordinate
>> this and do the same thing in QEMU.
>
> I was thinking, side-by-side for a couple of weeks to let issues be
> worked out, then switch the default to SeaBIOS until the remaining bugs
> are killed, then remove the bochs bios.
SeaBIOS will be really helpful in the next talk like a pirate day.

>
> --
> Do not meddle in the internals of kernels, for they are subtle and quick to panic.
>
> --
> 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
>



-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: Re: [PATCH 0/5] bios: >4G updates

[Kevin O'Connor]

On Tue, Oct 14, 2008 at 05:29:12PM +0200, Avi Kivity wrote:
> 
> >> As an aside, is there any interest in using SeaBIOS with kvm?
> >>
> >>     
> > There is a great interest. I just don't know time frame for this. Avi?
> >   
> 
> I'd like the seabios repository to be a git submodule, so we don't have
> to rewrite stuff.  So I'll experiment a bit with git submodules and pull
> it in soon.
> 
> Kevin, will you accept qemu-specific and kvm-specific patches to
> SeaBIOS?  I'd like to avoid permanent deltas.

Yes.

There is already code specific to qemu and coreboot.  I don't see any
issues with having a CONFIG_KVM build option.

-Kevin

Re: Re: [PATCH 0/5] bios: >4G updates

[Avi Kivity]

Kevin O'Connor wrote:
>> Kevin, will you accept qemu-specific and kvm-specific patches to
>> SeaBIOS?  I'd like to avoid permanent deltas.
>>     
>
> Yes.
>
>   

Thanks.

> There is already code specific to qemu and coreboot.  I don't see any
> issues with having a CONFIG_KVM build option.
>   

Most kvm specific patches would actually be fairly generic features that 
haven't been upstreamed yet.  The only truly kvm specific patch would be 
tpr patching, which qemu doesn't need.

-- 
error compiling committee.c: too many arguments to function

Re: Re: [PATCH 0/5] bios: >4G updates

[Kevin O'Connor]

On Wed, Oct 15, 2008 at 07:46:49PM +0200, Avi Kivity wrote:
> Kevin O'Connor wrote:
>> There is already code specific to qemu and coreboot.  I don't see any
>> issues with having a CONFIG_KVM build option.
>
> Most kvm specific patches would actually be fairly generic features that  
> haven't been upstreamed yet.  The only truly kvm specific patch would be  
> tpr patching, which qemu doesn't need.

Yeah - most of the stuff that is wrapped in "#ifdef BX_QEMU" in bochs
bios is not really qemu specific.  In SeaBIOS, there is no longer a
CONFIG_QEMU option - instead the code has been unified where possible
and feature specific options were added where necessary (eg,
CONFIG_UUID_BACKDOOR).

Hopefully we can do the same for KVM stuff.  However, it's okay if
that's not practical.

-Kevin

Re: Re: [PATCH 0/5] bios: >4G updates

[Alex Williamson]

On Sun, 2008-10-12 at 18:50 -0400, Kevin O'Connor wrote:
> As an aside, is there any interest in using SeaBIOS with kvm?
> 
> SeaBIOS is a port of bochs bios to gcc.  I've been using SeaBIOS
> (along with coreboot) to boot and provide bios functions on real
> hardware.  It works fine under qemu also.

Sounds interesting to me.  The VirtaulBox project has also made
improvements to the bochs bios that might be nice to pull in.  I'd also
like to see the TianoCore EFI image, that ia64 is using, work on x86.
There's an x86 version for QEMU on the QEMU downloads page.  With the
(wip) patch below to increase the bios reserved region to 1MB I can boot
to the EFI shell, but KVM is missing some emulation to boot Linux (works
with --no-kvm, maybe an ff 6f opcode?).  I haven't had a chance to debug
it further.  Thanks,

Alex

Increase BIOS memory region to 1MB

Signed-off-by: Alex Williamson <alex.williamson@hp.com>
--

diff --git a/bios/rombios.c b/bios/rombios.c
index 818ce63..57e5139 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -4579,17 +4579,17 @@ ASM_END
                         break;
                     case 5:
                         /* 3 pages before the bios, we map the vmx tss pages */
-                        set_e820_range(ES, regs.u.r16.di, 0xfffbd000L,
-                                       0xfffc0000L, 0, 0, 2);
+                        set_e820_range(ES, regs.u.r16.di, 0xffdfd000L,
+                                       0xffe00000L, 0, 0, 2);
                         regs.u.r32.ebx = 6;
                         regs.u.r32.eax = 0x534D4150;
                         regs.u.r32.ecx = 0x14;
                         CLEAR_CF();
                          return;
                     case 6:
-                        /* 256KB BIOS area at the end of 4 GB */
+                        /* 1MB BIOS area at the end of 4 GB */
                         set_e820_range(ES, regs.u.r16.di,
-                                       0xfffc0000L, 0x00000000L ,0, 0, 2);
+                                       0xffe00000L, 0x00000000L ,0, 0, 2);
                         if (extra_highbits_memory_size || extra_lowbits_memory_size)
                             regs.u.r32.ebx = 7;
                         else
diff --git a/libkvm/libkvm-x86.c b/libkvm/libkvm-x86.c
index a8cca15..d9850a4 100644
--- a/libkvm/libkvm-x86.c
+++ b/libkvm/libkvm-x86.c
@@ -42,7 +42,7 @@ static int kvm_init_tss(kvm_context_t kvm)
 		 * this address is 3 pages before the bios, and the bios should present
 		 * as unavaible memory
 		 */
-		r = kvm_set_tss_addr(kvm, 0xfffbd000);
+		r = kvm_set_tss_addr(kvm, 0xffdfd000);
 		if (r < 0) {
 			fprintf(stderr, "kvm_init_tss: unable to set tss addr\n");
 			return r;



-- 
Alex Williamson                             HP Open Source & Linux Org.