public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
* The way of mapping BIOS into the guest's address space
@ 2012-02-14 11:03 Yang Bai
  2012-02-14 11:10 ` Pekka Enberg
  2012-02-14 14:57 ` cody
  0 siblings, 2 replies; 10+ messages in thread
From: Yang Bai @ 2012-02-14 11:03 UTC (permalink / raw)
  To: penberg; +Cc: kvm

Hi all,

Since on X86, bios is always at the end of the address space, so I
have some thought about how to implement the seabios support for kvm
tool.

1. using kvm__register_mem to map the end of address space to the
guest then copy the code of seabios to this mem region. Just emulating
the bios chip.

2. leave the bios code alone and don't touch the guest's address
space. If the guest accesses the address belonging to the bios, it
will be an IO request and we can emulate the IO access to the bios
chip.

Any ideas about this?

And question:  How could I set the first instruction address after we
issue the vmlaunch instruction?

Thanks,
Yang

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: The way of mapping BIOS into the guest's address space
  2012-02-14 11:03 The way of mapping BIOS into the guest's address space Yang Bai
@ 2012-02-14 11:10 ` Pekka Enberg
  2012-02-14 12:13   ` Cyrill Gorcunov
  2012-02-14 14:57 ` cody
  1 sibling, 1 reply; 10+ messages in thread
From: Pekka Enberg @ 2012-02-14 11:10 UTC (permalink / raw)
  To: Yang Bai; +Cc: kvm, Ingo Molnar, Sasha Levin, Cyrill Gorcunov, Asias He

On Tue, Feb 14, 2012 at 1:03 PM, Yang Bai <hamo.by@gmail.com> wrote:
> Since on X86, bios is always at the end of the address space, so I
> have some thought about how to implement the seabios support for kvm
> tool.
>
> 1. using kvm__register_mem to map the end of address space to the
> guest then copy the code of seabios to this mem region. Just emulating
> the bios chip.
>
> 2. leave the bios code alone and don't touch the guest's address
> space. If the guest accesses the address belonging to the bios, it
> will be an IO request and we can emulate the IO access to the bios
> chip.
>
> Any ideas about this?

The latter solution doesn't make any sense to me. Cyrill, do we really
need to put the BIOS at the end of the address space? Don't we have
unused space below 1 MB?

> And question:  How could I set the first instruction address after we
> issue the vmlaunch instruction?

You need to set ->boot_ip and fiends. See
tools/kvm/x86/kvm.c::load_bzimage() for an example.

                        Pekka

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: The way of mapping BIOS into the guest's address space
  2012-02-14 11:10 ` Pekka Enberg
@ 2012-02-14 12:13   ` Cyrill Gorcunov
       [not found]     ` <CAO_0yfNM8EjEb-MTHp3-5sY4nvmY=gJRmuHJQTByXKZ3YY++Zg@mail.gmail.com>
  2012-02-15  4:07     ` Kevin O'Connor
  0 siblings, 2 replies; 10+ messages in thread
From: Cyrill Gorcunov @ 2012-02-14 12:13 UTC (permalink / raw)
  To: Pekka Enberg; +Cc: Yang Bai, kvm, Ingo Molnar, Sasha Levin, Asias He

On Tue, Feb 14, 2012 at 01:10:59PM +0200, Pekka Enberg wrote:
> On Tue, Feb 14, 2012 at 1:03 PM, Yang Bai <hamo.by@gmail.com> wrote:
> > Since on X86, bios is always at the end of the address space, so I
> > have some thought about how to implement the seabios support for kvm
> > tool.
> >
> > 1. using kvm__register_mem to map the end of address space to the
> > guest then copy the code of seabios to this mem region. Just emulating
> > the bios chip.

I think this is what should be done.

> >
> > 2. leave the bios code alone and don't touch the guest's address
> > space. If the guest accesses the address belonging to the bios, it
> > will be an IO request and we can emulate the IO access to the bios
> > chip.
> >
> > Any ideas about this?
> 
> The latter solution doesn't make any sense to me. Cyrill, do we really
> need to put the BIOS at the end of the address space? Don't we have
> unused space below 1 MB?

I don't remember for sure how SeaBIOS works actually. What I rememer
is that it aquires all hw environment might have. So without real look
into seabios code I fear I can't answer. But reserving end of 4G address
space for bios copy sounds reasonable if we going to behave as real
hardware. Maybe we could poke someone from KVM camp for a hint?

	Cyrill

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: The way of mapping BIOS into the guest's address space
       [not found]     ` <CAO_0yfNM8EjEb-MTHp3-5sY4nvmY=gJRmuHJQTByXKZ3YY++Zg@mail.gmail.com>
@ 2012-02-14 13:32       ` Cyrill Gorcunov
  2012-02-14 15:35         ` Pekka Enberg
  0 siblings, 1 reply; 10+ messages in thread
From: Cyrill Gorcunov @ 2012-02-14 13:32 UTC (permalink / raw)
  To: Yang Bai; +Cc: Asias He, Ingo Molnar, Pekka Enberg, kvm, Sasha Levin

On Tue, Feb 14, 2012 at 09:20:18PM +0800, Yang Bai wrote:
> And will seabios replace the present bios implement or co-exsit?

Ideally we should get rid of our minibios completely and only have
seabios here instead.

	Cyrill

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: The way of mapping BIOS into the guest's address space
  2012-02-14 11:03 The way of mapping BIOS into the guest's address space Yang Bai
  2012-02-14 11:10 ` Pekka Enberg
@ 2012-02-14 14:57 ` cody
  1 sibling, 0 replies; 10+ messages in thread
From: cody @ 2012-02-14 14:57 UTC (permalink / raw)
  To: Yang Bai; +Cc: penberg, kvm

On 02/14/2012 07:03 PM, Yang Bai wrote:
> Hi all,
>
> Since on X86, bios is always at the end of the address space, so I
> have some thought about how to implement the seabios support for kvm
> tool.
>
> 1. using kvm__register_mem to map the end of address space to the
> guest then copy the code of seabios to this mem region. Just emulating
> the bios chip.
>
> 2. leave the bios code alone and don't touch the guest's address
> space. If the guest accesses the address belonging to the bios, it
> will be an IO request and we can emulate the IO access to the bios
> chip.
>
> Any ideas about this?
>    
Can I ask what's the purpose of mapping BIOS code to guest? Any usage? 
Shouldn't BIOS's behavior be emulated by hypervisor? Thanks.

-cody
> And question:  How could I set the first instruction address after we
> issue the vmlaunch instruction?
>
> Thanks,
> Yang
> --
> 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
>    


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: The way of mapping BIOS into the guest's address space
  2012-02-14 13:32       ` Cyrill Gorcunov
@ 2012-02-14 15:35         ` Pekka Enberg
  2012-02-14 15:38           ` Cyrill Gorcunov
  0 siblings, 1 reply; 10+ messages in thread
From: Pekka Enberg @ 2012-02-14 15:35 UTC (permalink / raw)
  To: Cyrill Gorcunov; +Cc: Yang Bai, Asias He, Ingo Molnar, kvm, Sasha Levin

On Tue, Feb 14, 2012 at 09:20:18PM +0800, Yang Bai wrote:
>> And will seabios replace the present bios implement or co-exsit?

On Tue, Feb 14, 2012 at 3:32 PM, Cyrill Gorcunov <gorcunov@openvz.org> wrote:
> Ideally we should get rid of our minibios completely and only have
> seabios here instead.

No, no, they should co-exist. There's absolutely no reason to force
people to use a BIOS to boot Linux.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: The way of mapping BIOS into the guest's address space
  2012-02-14 15:35         ` Pekka Enberg
@ 2012-02-14 15:38           ` Cyrill Gorcunov
  2012-02-14 15:41             ` Pekka Enberg
  0 siblings, 1 reply; 10+ messages in thread
From: Cyrill Gorcunov @ 2012-02-14 15:38 UTC (permalink / raw)
  To: Pekka Enberg; +Cc: Yang Bai, Asias He, Ingo Molnar, kvm, Sasha Levin

On Tue, Feb 14, 2012 at 05:35:47PM +0200, Pekka Enberg wrote:
> On Tue, Feb 14, 2012 at 09:20:18PM +0800, Yang Bai wrote:
> >> And will seabios replace the present bios implement or co-exsit?
> 
> On Tue, Feb 14, 2012 at 3:32 PM, Cyrill Gorcunov <gorcunov@openvz.org> wrote:
> > Ideally we should get rid of our minibios completely and only have
> > seabios here instead.
> 
> No, no, they should co-exist. There's absolutely no reason to force
> people to use a BIOS to boot Linux.
> 

I meant run-time (ie in memory). I didn't mean substitude our minibios,
but rather have an ability to either run with compiled-in bios or with
seabios instead.

	Cyrill

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: The way of mapping BIOS into the guest's address space
  2012-02-14 15:38           ` Cyrill Gorcunov
@ 2012-02-14 15:41             ` Pekka Enberg
  0 siblings, 0 replies; 10+ messages in thread
From: Pekka Enberg @ 2012-02-14 15:41 UTC (permalink / raw)
  To: Cyrill Gorcunov; +Cc: Yang Bai, Asias He, Ingo Molnar, kvm, Sasha Levin

On Tue, Feb 14, 2012 at 5:38 PM, Cyrill Gorcunov <gorcunov@openvz.org> wrote:
>> > Ideally we should get rid of our minibios completely and only have
>> > seabios here instead.
>>
>> No, no, they should co-exist. There's absolutely no reason to force
>> people to use a BIOS to boot Linux.
>
> I meant run-time (ie in memory). I didn't mean substitude our minibios,
> but rather have an ability to either run with compiled-in bios or with
> seabios instead.

Sure.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: The way of mapping BIOS into the guest's address space
  2012-02-14 12:13   ` Cyrill Gorcunov
       [not found]     ` <CAO_0yfNM8EjEb-MTHp3-5sY4nvmY=gJRmuHJQTByXKZ3YY++Zg@mail.gmail.com>
@ 2012-02-15  4:07     ` Kevin O'Connor
  2012-02-15 10:12       ` Cyrill Gorcunov
  1 sibling, 1 reply; 10+ messages in thread
From: Kevin O'Connor @ 2012-02-15  4:07 UTC (permalink / raw)
  To: Cyrill Gorcunov
  Cc: Pekka Enberg, Yang Bai, kvm, Ingo Molnar, Sasha Levin, Asias He

On Tue, Feb 14, 2012 at 04:13:42PM +0400, Cyrill Gorcunov wrote:
> On Tue, Feb 14, 2012 at 01:10:59PM +0200, Pekka Enberg wrote:
> > On Tue, Feb 14, 2012 at 1:03 PM, Yang Bai <hamo.by@gmail.com> wrote:
> > > Since on X86, bios is always at the end of the address space, so I
> > > have some thought about how to implement the seabios support for kvm
> > > tool.
> > >
> > > 1. using kvm__register_mem to map the end of address space to the
> > > guest then copy the code of seabios to this mem region. Just emulating
> > > the bios chip.
> 
> I think this is what should be done.
> 
> > >
> > > 2. leave the bios code alone and don't touch the guest's address
> > > space. If the guest accesses the address belonging to the bios, it
> > > will be an IO request and we can emulate the IO access to the bios
> > > chip.
> > >
> > > Any ideas about this?
> > 
> > The latter solution doesn't make any sense to me. Cyrill, do we really
> > need to put the BIOS at the end of the address space? Don't we have
> > unused space below 1 MB?
> 
> I don't remember for sure how SeaBIOS works actually. What I rememer
> is that it aquires all hw environment might have. So without real look
> into seabios code I fear I can't answer. But reserving end of 4G address
> space for bios copy sounds reasonable if we going to behave as real
> hardware. Maybe we could poke someone from KVM camp for a hint?

SeaBIOS has two ways to be deployed - first is to copy the image to
the top of the first 1MB (eg, 0xe0000-0xfffff) and jump to
0xf000:0xfff0 in 16bit mode.  The second way is to use the SeaBIOS elf
and deploy into memory (according to the elf memory map) and jump to
SeaBIOS in 32bit mode (according to the elf entry point).

SeaBIOS doesn't really need to be in the top 4G of ram.  SeaBIOS does
expect to have normal PC hardware devices (eg, a PIC), though many
hardware devices can be compiled out via its kconfig interface.  The
more interesting challenge will likely be in communicating critical
pieces of information (eg, total memory size) into SeaBIOS.

The SeaBIOS mailing list (seabios@seabios.org) is probably a better
location for technical seabios questions.

-Kevin

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: The way of mapping BIOS into the guest's address space
  2012-02-15  4:07     ` Kevin O'Connor
@ 2012-02-15 10:12       ` Cyrill Gorcunov
  0 siblings, 0 replies; 10+ messages in thread
From: Cyrill Gorcunov @ 2012-02-15 10:12 UTC (permalink / raw)
  To: Kevin O'Connor
  Cc: Pekka Enberg, Yang Bai, kvm, Ingo Molnar, Sasha Levin, Asias He

On Tue, Feb 14, 2012 at 11:07:08PM -0500, Kevin O'Connor wrote:
...
> > hardware. Maybe we could poke someone from KVM camp for a hint?
> 
> SeaBIOS has two ways to be deployed - first is to copy the image to
> the top of the first 1MB (eg, 0xe0000-0xfffff) and jump to
> 0xf000:0xfff0 in 16bit mode.  The second way is to use the SeaBIOS elf
> and deploy into memory (according to the elf memory map) and jump to
> SeaBIOS in 32bit mode (according to the elf entry point).
> 
> SeaBIOS doesn't really need to be in the top 4G of ram.  SeaBIOS does
> expect to have normal PC hardware devices (eg, a PIC), though many
> hardware devices can be compiled out via its kconfig interface.  The
> more interesting challenge will likely be in communicating critical
> pieces of information (eg, total memory size) into SeaBIOS.
> 
> The SeaBIOS mailing list (seabios@seabios.org) is probably a better
> location for technical seabios questions.
> 

Hi Kevin, thanks for pointing. Yes, providing info back to seabios
to setup mttr and such (so seabios would recognize them) is
most challeging I think.

	Cyrill

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2012-02-15 10:12 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-14 11:03 The way of mapping BIOS into the guest's address space Yang Bai
2012-02-14 11:10 ` Pekka Enberg
2012-02-14 12:13   ` Cyrill Gorcunov
     [not found]     ` <CAO_0yfNM8EjEb-MTHp3-5sY4nvmY=gJRmuHJQTByXKZ3YY++Zg@mail.gmail.com>
2012-02-14 13:32       ` Cyrill Gorcunov
2012-02-14 15:35         ` Pekka Enberg
2012-02-14 15:38           ` Cyrill Gorcunov
2012-02-14 15:41             ` Pekka Enberg
2012-02-15  4:07     ` Kevin O'Connor
2012-02-15 10:12       ` Cyrill Gorcunov
2012-02-14 14:57 ` cody

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox