Re: [Qemu-devel] Release plan for 0.12.0

Re: [Qemu-devel] Release plan for 0.12.0

[Laurent Vivier]

>for target-i386 and target-x86_64:
>
>o EFI firmware emulation (as a machine or command line option)
>o OS/2 1.x support
>
>for target-m68k
>
>o Macintosh support at least to boot an Apple Toolbox (the firmware)

To have a running linux-user-m68k should be a more reasonable target.
Then we can think to run a linux kernel but we have to emulate a 68030 or 68040, a nubus bus, nubus cards and Apple video cards.

There is no opensource version of the Apple ROM and it is copyrighted.

Regards,
Laurent
-- 
--------------------- Laurent@vivier.eu  ---------------------
"Tout ce qui est impossible reste à accomplir"    Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard

Re: [Qemu-devel] Release plan for 0.12.0

[Natalia Portillo]

You are wrong my friend.

ARDI Inc opensourced the Executor source code that emulates a System 6  
Mac OS without using a real ROM.

This can be taken as a start.

Other approach can be creating a emulator capable to run the real  
copyrighted ROM before making an opensource substitute or asking Apple  
for releasing it in public domain (as Amstrad did with the Spectrum  
and CPC ROMs).

Also emulating a nubus-less or 68000 Macintosh does not require  
emulating 68030, or nubus at all.

Mac OS is a highly ROM-dependent system as in the device drivers for  
each machine resided at first in the ROM (floppy, hard disk, video).
At the same time it is the most documented one as up to Macintosh II  
the 100% of the Toolbox APIs are documented in Inside Macintosh books  
(which can be obtained second hand in eBay and Amazon, as well as in  
HTML in Apple's webpage)

El 01/10/2009, a las 09:03, Laurent Vivier escribió:

>> for target-i386 and target-x86_64:
>>
>> o EFI firmware emulation (as a machine or command line option)
>> o OS/2 1.x support
>>
>> for target-m68k
>>
>> o Macintosh support at least to boot an Apple Toolbox (the firmware)
>
> To have a running linux-user-m68k should be a more reasonable target.
> Then we can think to run a linux kernel but we have to emulate a  
> 68030 or 68040, a nubus bus, nubus cards and Apple video cards.
>
> There is no opensource version of the Apple ROM and it is copyrighted.
>
> Regards,
> Laurent
> -- 
> --------------------- Laurent@vivier.eu  ---------------------
> "Tout ce qui est impossible reste à accomplir"    Jules Verne
> "Things are only impossible until they're not" Jean-Luc Picard
>

Re: [Qemu-devel] Release plan for 0.12.0

[Laurent Vivier]

>On Thu, Oct 01, 2009 at 02:55:05AM +0100, Natalia Portillo wrote:
>
>> integrating target-alpha and target-zxspectrum in the branch tree
>
>Heh. :)
>
>z80-softmmu now has MSX1 emulation, with thanks to Juha Riihimäki,
>and I've also added the beginnings of ZX Spectrum 128K and SAM Coupé
>emulation.  It still needs quite a few cleanups, though.
>
>When you speak of target-alpha, I presume you're referring to
>Tristan Gingold's system emulation patches... it would certainly be
>nice to see these applied.
>
>Same also for Laurent Vivier's m68k patches -- I would certainly have a
>go at implementing Atari ST emulation, and would also be interested in
>helping with Amiga, 68K Mac and perhaps even NeXT, SUN3, etc.

My TODO list is:
- have a running linux-user to be able to chroot a filesystem and build debian packages.
- boot a linux-m68k kernel (preferably the mac68k one)
- be able to run AROS and perhaps help AROS i386 to run AmigaOS m68k binaries.

MacOS is not not really my cup of tea in this case, I think Basilisk II is a better choice for that.

I'd like to boot MacOS X on the powerpc target, and I'm working on this by adding missing functionalities to openbios (Is someone know what is the meaning of "{ ; depth }" in Forth ? ;-) )

Regards,
Laurent


-- 
--------------------- Laurent@vivier.eu  ---------------------
"Tout ce qui est impossible reste à accomplir"    Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard

Re: [Qemu-devel] Release plan for 0.12.0

[G 3]

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


On Oct 1, 2009, at 4:07 AM, qemu-devel-request@nongnu.org wrote:

>
> To have a running linux-user-m68k should be a more reasonable target.
> Then we can think to run a linux kernel but we have to emulate a  
> 68030 or 68040, a nubus bus, nubus cards and Apple video cards.
>
> There is no opensource version of the Apple ROM and it is copyrighted.
>
> Regards,
> Laurent

Other emulators have succeeded in emulating a 68k Mac. I am sure we  
can. Instead of providing the ROM file, we could always provide  
directions on how to obtain the ROM. I have seen directions on  
obtaining the ROM by using the application TomeViewer to extract the  
ROM from an Apple firmware update file.


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

Re: [Qemu-devel] Release plan for 0.12.0

[Natalia Portillo]

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

That's not the ROM, it's the MacOS Nanokernel used in 8.5 and upper as  
a PowerPC substitute to Toolbox.

This is of comparing the 68k ROMs of Apple that contained the Toolbox  
(most of the MacOS API) along with that specific machine device  
drivers (WIM and SWIM floppy controllers, SCSI, the framebuffer -no  
real video card-, the ADB), and with the PowerPC ROMs that contained a  
mixed 68k-PPC Toolbox, an incomplete OpenFirmware, the 68k emulator.

With 8.5 the ROM only needed to contain the OpenFirmware, as the rest  
(68k-PPC Toolbox, 68k emulator) was included in the "rom file" along  
with the nanokernel, that both loaded the rest of the OS (that  
depended on the toolbox) and the drivers needed as described by OF.

El 01/10/2009, a las 16:10, G 3 escribió:

>
> On Oct 1, 2009, at 4:07 AM, qemu-devel-request@nongnu.org wrote:
>
>>
>> To have a running linux-user-m68k should be a more reasonable target.
>> Then we can think to run a linux kernel but we have to emulate a  
>> 68030 or 68040, a nubus bus, nubus cards and Apple video cards.
>>
>> There is no opensource version of the Apple ROM and it is  
>> copyrighted.
>>
>> Regards,
>> Laurent
>
> Other emulators have succeeded in emulating a 68k Mac. I am sure we  
> can. Instead of providing the ROM file, we could always provide  
> directions on how to obtain the ROM. I have seen directions on  
> obtaining the ROM by using the application TomeViewer to extract the  
> ROM from an Apple firmware update file.
>


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

[Qemu-devel] Release plan for 0.12.0

[Anthony Liguori]

Hi,

Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0.

I'd like to do a few things different this time around.  I don't think 
the -rc process went very well as I don't think we got more testing out 
of it.  I'd like to shorten the timeline for 0.12.0 a good bit.  The 
0.10 stable tree got pretty difficult to maintain toward the end of the 
cycle.  We also had a pretty huge amount of change between 0.10 and 0.11 
so I think a shorter cycle is warranted.

I think aiming for early to mid-December would give us roughly a 3 month 
cycle and would align well with some of the Linux distribution cycles.  
I'd like to limit things to a single -rc that lasted only for about a 
week.  This is enough time to fix most of the obvious issues I think.

I'd also like to try to enumerate some features for this release.  
Here's a short list of things I expect to see for this release 
(target-i386 centric).  Please add or comment on items that you'd either 
like to see in the release or are planning on working on.

 o VMState conversion -- I expect most of the pc target to be completed
 o qdev conversion -- I hope that we'll get most of the pc target 
completely converted to qdev
 o storage live migration
 o switch to SeaBIOS (need to finish porting features from Bochs)
 o switch to gPXE (need to resolve slirp tftp server issue)
 o KSM integration
 o in-kernel APIC support for KVM
 o guest SMP support for KVM
 o updates to the default pc machine type

Please add to this list and I'll collect it all and post it somewhere.

Thanks!

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] Release plan for 0.12.0

[Isaku Yamahata]

On Tue, Sep 29, 2009 at 06:54:53PM -0500, Anthony Liguori wrote:
> Hi,
> 
> Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0.
> 
> I'd like to do a few things different this time around.  I don't think 
> the -rc process went very well as I don't think we got more testing out 
> of it.  I'd like to shorten the timeline for 0.12.0 a good bit.  The 
> 0.10 stable tree got pretty difficult to maintain toward the end of the 
> cycle.  We also had a pretty huge amount of change between 0.10 and 0.11 
> so I think a shorter cycle is warranted.
> 
> I think aiming for early to mid-December would give us roughly a 3 month 
> cycle and would align well with some of the Linux distribution cycles.  
> I'd like to limit things to a single -rc that lasted only for about a 
> week.  This is enough time to fix most of the obvious issues I think.
> 
> I'd also like to try to enumerate some features for this release.  
> Here's a short list of things I expect to see for this release 
> (target-i386 centric).  Please add or comment on items that you'd either 
> like to see in the release or are planning on working on.
> 
> o VMState conversion -- I expect most of the pc target to be completed
> o qdev conversion -- I hope that we'll get most of the pc target 
> completely converted to qdev
> o storage live migration
> o switch to SeaBIOS (need to finish porting features from Bochs)
> o switch to gPXE (need to resolve slirp tftp server issue)
> o KSM integration
> o in-kernel APIC support for KVM
> o guest SMP support for KVM
> o updates to the default pc machine type
> 
> Please add to this list and I'll collect it all and post it somewhere.

 o newer chipset (which is based on Q35 chipset)
 o multiple pci bus 
 o PCI express (MMCONFIG)
 o PCI express hot plug (not acpi based)
 o PCI express switch emulator

Although there is no PCIe emulated device at the moment, 
this will be a fundamental infrastructure for PCI express native
direct attach.

thanks,
-- 
yamahata

Re: [Qemu-devel] Release plan for 0.12.0

[Anthony Liguori]

Hi Isaku,

Isaku Yamahata wrote:
>  o newer chipset (which is based on Q35 chipset)
>  o multiple pci bus 
>  o PCI express (MMCONFIG)
>  o PCI express hot plug (not acpi based)
>  o PCI express switch emulator
>
> Although there is no PCIe emulated device at the moment, 
> this will be a fundamental infrastructure for PCI express native
> direct attach.
>   

Your patches definitely deserve review/commit.  I'll make sure that 
happens for the 0.12 time frame.

Michael, could you help review some of the PCI patches?

Thanks,

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] Release plan for 0.12.0

[Michael S. Tsirkin]

On Wed, Sep 30, 2009 at 08:03:20AM -0500, Anthony Liguori wrote:
> Hi Isaku,
>
> Isaku Yamahata wrote:
>>  o newer chipset (which is based on Q35 chipset)
>>  o multiple pci bus  o PCI express (MMCONFIG)
>>  o PCI express hot plug (not acpi based)
>>  o PCI express switch emulator
>>
>> Although there is no PCIe emulated device at the moment, this will be a 
>> fundamental infrastructure for PCI express native
>> direct attach.
>>   
>
> Your patches definitely deserve review/commit.  I'll make sure that  
> happens for the 0.12 time frame.
>
> Michael, could you help review some of the PCI patches?

Yes, I am doing this sent comments already.
The only thing I have not looked at yet is the new express file.

> Thanks,
>
> -- 
> Regards,
>
> Anthony Liguori

Re: [Qemu-devel] Release plan for 0.12.0

[Avi Kivity]

On 09/30/2009 01:54 AM, Anthony Liguori wrote:
> Hi,
>
> Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0.
>
> I'd like to do a few things different this time around.  I don't think 
> the -rc process went very well as I don't think we got more testing 
> out of it.  I'd like to shorten the timeline for 0.12.0 a good bit.  
> The 0.10 stable tree got pretty difficult to maintain toward the end 
> of the cycle.  We also had a pretty huge amount of change between 0.10 
> and 0.11 so I think a shorter cycle is warranted.
>
> I think aiming for early to mid-December would give us roughly a 3 
> month cycle and would align well with some of the Linux distribution 
> cycles.  I'd like to limit things to a single -rc that lasted only for 
> about a week.  This is enough time to fix most of the obvious issues I 
> think.
>
> I'd also like to try to enumerate some features for this release.  
> Here's a short list of things I expect to see for this release 
> (target-i386 centric).  Please add or comment on items that you'd 
> either like to see in the release or are planning on working on.
>
> o VMState conversion -- I expect most of the pc target to be completed
> o qdev conversion -- I hope that we'll get most of the pc target 
> completely converted to qdev
> o storage live migration
> o switch to SeaBIOS (need to finish porting features from Bochs)
> o switch to gPXE (need to resolve slirp tftp server issue)
> o KSM integration
> o in-kernel APIC support for KVM
> o guest SMP support for KVM
> o updates to the default pc machine type

Machine monitor protocol.

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

Re: [Qemu-devel] Release plan for 0.12.0

[Anthony Liguori]

Avi Kivity wrote:
> On 09/30/2009 01:54 AM, Anthony Liguori wrote:
>> Hi,
>>
>> Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0.
>>
>> I'd like to do a few things different this time around.  I don't 
>> think the -rc process went very well as I don't think we got more 
>> testing out of it.  I'd like to shorten the timeline for 0.12.0 a 
>> good bit.  The 0.10 stable tree got pretty difficult to maintain 
>> toward the end of the cycle.  We also had a pretty huge amount of 
>> change between 0.10 and 0.11 so I think a shorter cycle is warranted.
>>
>> I think aiming for early to mid-December would give us roughly a 3 
>> month cycle and would align well with some of the Linux distribution 
>> cycles.  I'd like to limit things to a single -rc that lasted only 
>> for about a week.  This is enough time to fix most of the obvious 
>> issues I think.
>>
>> I'd also like to try to enumerate some features for this release.  
>> Here's a short list of things I expect to see for this release 
>> (target-i386 centric).  Please add or comment on items that you'd 
>> either like to see in the release or are planning on working on.
>>
>> o VMState conversion -- I expect most of the pc target to be completed
>> o qdev conversion -- I hope that we'll get most of the pc target 
>> completely converted to qdev
>> o storage live migration
>> o switch to SeaBIOS (need to finish porting features from Bochs)
>> o switch to gPXE (need to resolve slirp tftp server issue)
>> o KSM integration
>> o in-kernel APIC support for KVM
>> o guest SMP support for KVM
>> o updates to the default pc machine type
>
> Machine monitor protocol.

If we're going to support the protocol for 0.12, I'd like to most of the 
code merged by the end of October.

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] Release plan for 0.12.0

[Luiz Capitulino]

On Wed, 30 Sep 2009 08:05:16 -0500
Anthony Liguori <aliguori@us.ibm.com> wrote:

> Avi Kivity wrote:
> > On 09/30/2009 01:54 AM, Anthony Liguori wrote:
> >> Hi,
> >>
> >> Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0.
> >>
> >> I'd like to do a few things different this time around.  I don't 
> >> think the -rc process went very well as I don't think we got more 
> >> testing out of it.  I'd like to shorten the timeline for 0.12.0 a 
> >> good bit.  The 0.10 stable tree got pretty difficult to maintain 
> >> toward the end of the cycle.  We also had a pretty huge amount of 
> >> change between 0.10 and 0.11 so I think a shorter cycle is warranted.
> >>
> >> I think aiming for early to mid-December would give us roughly a 3 
> >> month cycle and would align well with some of the Linux distribution 
> >> cycles.  I'd like to limit things to a single -rc that lasted only 
> >> for about a week.  This is enough time to fix most of the obvious 
> >> issues I think.
> >>
> >> I'd also like to try to enumerate some features for this release.  
> >> Here's a short list of things I expect to see for this release 
> >> (target-i386 centric).  Please add or comment on items that you'd 
> >> either like to see in the release or are planning on working on.
> >>
> >> o VMState conversion -- I expect most of the pc target to be completed
> >> o qdev conversion -- I hope that we'll get most of the pc target 
> >> completely converted to qdev
> >> o storage live migration
> >> o switch to SeaBIOS (need to finish porting features from Bochs)
> >> o switch to gPXE (need to resolve slirp tftp server issue)
> >> o KSM integration
> >> o in-kernel APIC support for KVM
> >> o guest SMP support for KVM
> >> o updates to the default pc machine type
> >
> > Machine monitor protocol.
> 
> If we're going to support the protocol for 0.12, I'd like to most of the 
> code merged by the end of October.

 Four weeks.. Not so much time, but let's try.

 There are two major issues that may delay QMP.

 Firstly, we are still on the infrastructure/design phase, which
is natural to take time. Maybe when handlers start getting converted
en masse things will be faster.

 Secondly: testing. I have a very ugly python script to test the
already converted handlers. The problem is not only the ugliness,
the right way to do this would be to use kvm-autotest. So, I was
planning to take a detailed look at it and perhaps start writing
tests for QMP right when each handler is converted. Right Thing,
but takes time.

Re: [Qemu-devel] Release plan for 0.12.0

[Avi Kivity]

On 10/01/2009 11:13 PM, Luiz Capitulino wrote:
>> If we're going to support the protocol for 0.12, I'd like to most of the
>> code merged by the end of October.
>>      
>   Four weeks.. Not so much time, but let's try.
>
>   There are two major issues that may delay QMP.
>
>   Firstly, we are still on the infrastructure/design phase, which
> is natural to take time. Maybe when handlers start getting converted
> en masse things will be faster.
>    

I sure hope so.  Maybe someone can pitch in if not.

>   Secondly: testing. I have a very ugly python script to test the
> already converted handlers. The problem is not only the ugliness,
> the right way to do this would be to use kvm-autotest. So, I was
> planning to take a detailed look at it and perhaps start writing
> tests for QMP right when each handler is converted. Right Thing,
> but takes time.
>    

I think this could be done by having autotest use two monitors, one with 
the machine protocol and one with the human protocol, trying first the 
machine protocol and falling back if the command is not supported.

Hopefully we can get the autotest people to work on it so we parallelize 
development.  They'll also give user-oriented feedback which can be 
valuable.

Are you using a standard json parser with your test script?  That's an 
additional validation.

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

Re: [Qemu-devel] Release plan for 0.12.0

[Luiz Capitulino]

On Sat, 03 Oct 2009 12:04:57 +0200
Avi Kivity <avi@redhat.com> wrote:

> On 10/01/2009 11:13 PM, Luiz Capitulino wrote:
> >> If we're going to support the protocol for 0.12, I'd like to most of the
> >> code merged by the end of October.
> >>      
> >   Four weeks.. Not so much time, but let's try.
> >
> >   There are two major issues that may delay QMP.
> >
> >   Firstly, we are still on the infrastructure/design phase, which
> > is natural to take time. Maybe when handlers start getting converted
> > en masse things will be faster.
> >    
> 
> I sure hope so.  Maybe someone can pitch in if not.

 I've written a TODO list if someone is willing to help:

http://tinyurl.com/ya7l6bo

> >   Secondly: testing. I have a very ugly python script to test the
> > already converted handlers. The problem is not only the ugliness,
> > the right way to do this would be to use kvm-autotest. So, I was
> > planning to take a detailed look at it and perhaps start writing
> > tests for QMP right when each handler is converted. Right Thing,
> > but takes time.
> >    
> 
> I think this could be done by having autotest use two monitors, one with 
> the machine protocol and one with the human protocol, trying first the 
> machine protocol and falling back if the command is not supported.

 Yes, sounds a good idea.

> Hopefully we can get the autotest people to work on it so we parallelize 
> development.  They'll also give user-oriented feedback which can be 
> valuable.

 I will talk to them about that.

> Are you using a standard json parser with your test script?  That's an 
> additional validation.

 I'm using Python's json module, but I could run one of the checkers
listed in the json's page for each test, before the Python's module
kicks in.

Re: [Qemu-devel] Release plan for 0.12.0

[Avi Kivity]

On 10/05/2009 02:43 PM, Luiz Capitulino wrote:
>> Are you using a standard json parser with your test script?  That's an
>> additional validation.
>>      
>   I'm using Python's json module, but I could run one of the checkers
> listed in the json's page for each test, before the Python's module
> kicks in.
>    

python-json should be sufficient, I think.

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

Re: [Qemu-devel] Release plan for 0.12.0

[Luiz Capitulino]

On Wed, 30 Sep 2009 08:41:23 +0200
Avi Kivity <avi@redhat.com> wrote:

> On 09/30/2009 01:54 AM, Anthony Liguori wrote:
> > Hi,
> >
> > Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0.
> >
> > I'd like to do a few things different this time around.  I don't think 
> > the -rc process went very well as I don't think we got more testing 
> > out of it.  I'd like to shorten the timeline for 0.12.0 a good bit.  
> > The 0.10 stable tree got pretty difficult to maintain toward the end 
> > of the cycle.  We also had a pretty huge amount of change between 0.10 
> > and 0.11 so I think a shorter cycle is warranted.
> >
> > I think aiming for early to mid-December would give us roughly a 3 
> > month cycle and would align well with some of the Linux distribution 
> > cycles.  I'd like to limit things to a single -rc that lasted only for 
> > about a week.  This is enough time to fix most of the obvious issues I 
> > think.
> >
> > I'd also like to try to enumerate some features for this release.  
> > Here's a short list of things I expect to see for this release 
> > (target-i386 centric).  Please add or comment on items that you'd 
> > either like to see in the release or are planning on working on.
> >
> > o VMState conversion -- I expect most of the pc target to be completed
> > o qdev conversion -- I hope that we'll get most of the pc target 
> > completely converted to qdev
> > o storage live migration
> > o switch to SeaBIOS (need to finish porting features from Bochs)
> > o switch to gPXE (need to resolve slirp tftp server issue)
> > o KSM integration
> > o in-kernel APIC support for KVM
> > o guest SMP support for KVM
> > o updates to the default pc machine type
> 
> Machine monitor protocol.

 Yeah, I was going to suggest it as well.

Re: [Qemu-devel] Release plan for 0.12.0

[Michael Tokarev]

Anthony Liguori wrote:
[]
> Here's a short list of things I expect to see for this release 
> (target-i386 centric).  Please add or comment on items that you'd either 
> like to see in the release or are planning on working on.
[..]
> o guest SMP support for KVM

Hmm.  What is this, can you elaborate a bit more please?
-smp nn is already here, no?

Thanks!

/mjt

Re: [Qemu-devel] Release plan for 0.12.0

[Avi Kivity]

On 09/30/2009 10:53 AM, Michael Tokarev wrote:
> Anthony Liguori wrote:
> []
>> Here's a short list of things I expect to see for this release 
>> (target-i386 centric).  Please add or comment on items that you'd 
>> either like to see in the release or are planning on working on.
> [..]
>> o guest SMP support for KVM
>
> Hmm.  What is this, can you elaborate a bit more please?
> -smp nn is already here, no?
>

Only in qemu-kvm.git.  This is about qemu.git (which supports -smp, but 
not with kvm).

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

Re: [Qemu-devel] Release plan for 0.12.0

[Carl-Daniel Hailfinger]

Hi,

On 30.09.2009 01:54, Anthony Liguori wrote:
> Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0.
>
> I'd also like to try to enumerate some features for this release. 
> Here's a short list of things I expect to see for this release
> (target-i386 centric).
>
> o switch to SeaBIOS (need to finish porting features from Bochs)

That switch is much appreciated because it also reduces the testing
matrix of those coreboot developers who boot test every commit with Qemu.

However, to run coreboot on Qemu with the same init sequence as on
simplified real hardware, we need Cache-as-RAM (CAR) support. This is
basically a mode where sizeof(cacheable area) <= sizeof (L2 cache) and
causes the processor to lock the cache and not pass any reads/writes
through to the RAM behind the cached area. The easiest way to implement
this would be to check the cache size criterion upon every MTRR
manipulation and either map a chunk of fresh memory on top of the
existing memory (which may be RAM, ROM or unmapped) for every cacheable
area, and if the cacheable area starts to exceed the L2 cache size,
discard all memory contents of the memory mapped on top.
For additional correctness, the memory shoud not be discarded and
written back to the lower layer of memory if WBINVD (instead of INVD) or
CLFLUSH are called. That one is mostly sugar, though, and coreboot can
do without.

Right now coreboot sets up the MTRRs correctly, but then (conditional on
Qemu) only uses areas which are known to be backed by RAM instead of the
areas designated by CAR.

I'd like to implement CAR support which builds on top of my MTRR code
which was merged some months ago (and I already have code to check for
total cacheable area size), but I need help with the memory mapping
stuff. How do I proceed? Clean up what I have and insert "FIXME"
comments where I don't know how to implement stuff so others can see the
code and comment on it?

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [Qemu-devel] Release plan for 0.12.0

[Anthony Liguori]

Carl-Daniel Hailfinger wrote:
> Hi,
>
> On 30.09.2009 01:54, Anthony Liguori wrote:
>   
>> Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0.
>>
>> I'd also like to try to enumerate some features for this release. 
>> Here's a short list of things I expect to see for this release
>> (target-i386 centric).
>>
>> o switch to SeaBIOS (need to finish porting features from Bochs)
>>     
>
> That switch is much appreciated because it also reduces the testing
> matrix of those coreboot developers who boot test every commit with Qemu.
>
> However, to run coreboot on Qemu with the same init sequence as on
> simplified real hardware, we need Cache-as-RAM (CAR) support. This is
> basically a mode where sizeof(cacheable area) <= sizeof (L2 cache) and
> causes the processor to lock the cache and not pass any reads/writes
> through to the RAM behind the cached area. The easiest way to implement
> this would be to check the cache size criterion upon every MTRR
> manipulation and either map a chunk of fresh memory on top of the
> existing memory (which may be RAM, ROM or unmapped) for every cacheable
> area, and if the cacheable area starts to exceed the L2 cache size,
> discard all memory contents of the memory mapped on top.
> For additional correctness, the memory shoud not be discarded and
> written back to the lower layer of memory if WBINVD (instead of INVD) or
> CLFLUSH are called. That one is mostly sugar, though, and coreboot can
> do without.
>   

Do we really need coreboot to use the same init sequence?   coreboot is 
firmware and we don't necessarily run real firmware under QEMU.  It's a 
short cut that lets us avoid a lot of complexity.

> Right now coreboot sets up the MTRRs correctly, but then (conditional on
> Qemu) only uses areas which are known to be backed by RAM instead of the
> areas designated by CAR.
>
> I'd like to implement CAR support which builds on top of my MTRR code
> which was merged some months ago (and I already have code to check for
> total cacheable area size), but I need help with the memory mapping
> stuff. How do I proceed? Clean up what I have and insert "FIXME"
> comments where I don't know how to implement stuff so others can see the
> code and comment on it?
>   

You could start there.  But from a higher level, I'm not sure I think a 
partial implementation of something like CAR is all that valuable since 
coreboot already runs under QEMU.

> Regards,
> Carl-Daniel
>
>   
-- 

Regards,

Anthony Liguori

Re: [Qemu-devel] Release plan for 0.12.0

[Carl-Daniel Hailfinger]

On 30.09.2009 15:07, Anthony Liguori wrote:
> Carl-Daniel Hailfinger wrote:
>> However, to run coreboot on Qemu with the same init sequence as on
>> simplified real hardware, we need Cache-as-RAM (CAR) support. [...] 
>
> Do we really need coreboot to use the same init sequence?   coreboot
> is firmware and we don't necessarily run real firmware under QEMU. 
> It's a short cut that lets us avoid a lot of complexity.

I know that some people were running 440BX BIOS images for real hardware
on Qemu and they got pretty far.

The complexity would be limited to the MTRR code and unless there were
major architectural changes in mapping RAM to address ranges, no other
code (except VM save and VM restore) should get even a single line changed.

>> Right now coreboot sets up the MTRRs correctly, but then (conditional on
>> Qemu) only uses areas which are known to be backed by RAM instead of the
>> areas designated by CAR.
>>
>> I'd like to implement CAR support which builds on top of my MTRR code
>> which was merged some months ago (and I already have code to check for
>> total cacheable area size), but I need help with the memory mapping
>> stuff. How do I proceed? Clean up what I have and insert "FIXME"
>> comments where I don't know how to implement stuff so others can see the
>> code and comment on it?   
>
> You could start there.  But from a higher level, I'm not sure I think
> a partial implementation of something like CAR is all that valuable
> since coreboot already runs under QEMU.

It only runs if WORKAROUND_QEMU is defined (maybe not exactly that name,
but you get the point). The code in coreboot calculates MTRR settings to
cover the place where the stack will be. To workaround missing CAR in
Qemu, it then has to recalculate the stack location to be able to
actually use the stack. That forces coreboot to keep two stack base
variables and to completely replace the generic logic which switches off
CAR.

I hope the explanation above didn't offend you, I just tried to clarify
why working CAR is such a big deal for coreboot.

If you want either a full CAR implementation or no CAR implementation, I
can write a patch which implements full CAR, but then I need to hook
WBINVD, INVD and CLFLUSH. Neither instruction is executed often enough
to show up in any profile. Besides that, for anything not using CAR
(everything after the firmware), the penalty is a simple test of a
boolean variable per WBINVD/INVD/CLFLUSH.

If you have further questions, please don't hesitate to ask.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [Qemu-devel] Release plan for 0.12.0

[Blue Swirl]

On Wed, Sep 30, 2009 at 6:59 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006@gmx.net> wrote:
> On 30.09.2009 15:07, Anthony Liguori wrote:
>> Carl-Daniel Hailfinger wrote:
>>> However, to run coreboot on Qemu with the same init sequence as on
>>> simplified real hardware, we need Cache-as-RAM (CAR) support. [...]
>>
>> Do we really need coreboot to use the same init sequence?   coreboot
>> is firmware and we don't necessarily run real firmware under QEMU.
>> It's a short cut that lets us avoid a lot of complexity.
>
> I know that some people were running 440BX BIOS images for real hardware
> on Qemu and they got pretty far.
>
> The complexity would be limited to the MTRR code and unless there were
> major architectural changes in mapping RAM to address ranges, no other
> code (except VM save and VM restore) should get even a single line changed.
>
>>> Right now coreboot sets up the MTRRs correctly, but then (conditional on
>>> Qemu) only uses areas which are known to be backed by RAM instead of the
>>> areas designated by CAR.
>>>
>>> I'd like to implement CAR support which builds on top of my MTRR code
>>> which was merged some months ago (and I already have code to check for
>>> total cacheable area size), but I need help with the memory mapping
>>> stuff. How do I proceed? Clean up what I have and insert "FIXME"
>>> comments where I don't know how to implement stuff so others can see the
>>> code and comment on it?
>>
>> You could start there.  But from a higher level, I'm not sure I think
>> a partial implementation of something like CAR is all that valuable
>> since coreboot already runs under QEMU.
>
> It only runs if WORKAROUND_QEMU is defined (maybe not exactly that name,
> but you get the point). The code in coreboot calculates MTRR settings to
> cover the place where the stack will be. To workaround missing CAR in
> Qemu, it then has to recalculate the stack location to be able to
> actually use the stack. That forces coreboot to keep two stack base
> variables and to completely replace the generic logic which switches off
> CAR.
>
> I hope the explanation above didn't offend you, I just tried to clarify
> why working CAR is such a big deal for coreboot.
>
> If you want either a full CAR implementation or no CAR implementation, I
> can write a patch which implements full CAR, but then I need to hook
> WBINVD, INVD and CLFLUSH. Neither instruction is executed often enough
> to show up in any profile. Besides that, for anything not using CAR
> (everything after the firmware), the penalty is a simple test of a
> boolean variable per WBINVD/INVD/CLFLUSH.

The CAR mode could affect only translation so that special CAR
versions of the WBINVD etc. instructions are selected. On switch to
normal mode, the TBs need to be flushed.

Instead of your memory mapping approach (which should work) you could
also try using different memory access functions in CAR mode. It may
be more difficult, though.

Re: [Qemu-devel] Release plan for 0.12.0

[Luiz Capitulino]

On Tue, 29 Sep 2009 18:54:53 -0500
Anthony Liguori <aliguori@us.ibm.com> wrote:

> I think aiming for early to mid-December would give us roughly a 3 month 
> cycle and would align well with some of the Linux distribution cycles.  
> I'd like to limit things to a single -rc that lasted only for about a 
> week.  This is enough time to fix most of the obvious issues I think.

 How do you plan to do it? I mean, are you going to create a separate branch
or make master the -rc?

 Creating a separate branch (which is what we do today, iiuc) makes it
get less attention, freezing master for a certain period is the best
way to stabilize.

 Is this what you had in mind?

Re: [Qemu-devel] Release plan for 0.12.0

[Anthony Liguori]

Luiz Capitulino wrote:
> On Tue, 29 Sep 2009 18:54:53 -0500
> Anthony Liguori <aliguori@us.ibm.com> wrote:
>
>   
>> I think aiming for early to mid-December would give us roughly a 3 month 
>> cycle and would align well with some of the Linux distribution cycles.  
>> I'd like to limit things to a single -rc that lasted only for about a 
>> week.  This is enough time to fix most of the obvious issues I think.
>>     
>
>  How do you plan to do it? I mean, are you going to create a separate branch
> or make master the -rc?
>
>  Creating a separate branch (which is what we do today, iiuc) makes it
> get less attention, freezing master for a certain period is the best
> way to stabilize.
>
>  Is this what you had in mind?
>   
What do people think?

One reason I branch is because some people care a bit less about 
releases so it makes the process non-disruptive to them.  If the other 
maintainers agreed though, I would certainly like to have the master 
branch essentially frozen for the week before the release.

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] Release plan for 0.12.0

[Fred Leeflang]

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

2009/9/30 Anthony Liguori <aliguori@us.ibm.com>

> Luiz Capitulino wrote:
>
>> On Tue, 29 Sep 2009 18:54:53 -0500
>> Anthony Liguori <aliguori@us.ibm.com> wrote:
>>
>>
>>
>>> I think aiming for early to mid-December would give us roughly a 3 month
>>> cycle and would align well with some of the Linux distribution cycles.  I'd
>>> like to limit things to a single -rc that lasted only for about a week.
>>>  This is enough time to fix most of the obvious issues I think.
>>>
>>>
>>
>>  How do you plan to do it? I mean, are you going to create a separate
>> branch
>> or make master the -rc?
>>
>>  Creating a separate branch (which is what we do today, iiuc) makes it
>> get less attention, freezing master for a certain period is the best
>> way to stabilize.
>>
>>  Is this what you had in mind?
>>
>>
> What do people think?
>
> One reason I branch is because some people care a bit less about releases
> so it makes the process non-disruptive to them.  If the other maintainers
> agreed though, I would certainly like to have the master branch essentially
> frozen for the week before the release.
>

freezing is only neccesary if you need time to gather all the patches, build
and test them together etc. If you don't feel you or the developers need to
do that to get a reliable release out I think it only halts developers
without any clear reason to do so. Calling 'attention' to a release is not a
clear reason IMO.

-Fred

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

Re: [Qemu-devel] Release plan for 0.12.0

[Luiz Capitulino]

On Wed, 30 Sep 2009 17:03:23 +0200
Fred Leeflang <fredl@dutchie.org> wrote:

> 2009/9/30 Anthony Liguori <aliguori@us.ibm.com>
> 
> > Luiz Capitulino wrote:
> >
> >> On Tue, 29 Sep 2009 18:54:53 -0500
> >> Anthony Liguori <aliguori@us.ibm.com> wrote:
> >>
> >>
> >>
> >>> I think aiming for early to mid-December would give us roughly a 3 month
> >>> cycle and would align well with some of the Linux distribution cycles.  I'd
> >>> like to limit things to a single -rc that lasted only for about a week.
> >>>  This is enough time to fix most of the obvious issues I think.
> >>>
> >>>
> >>
> >>  How do you plan to do it? I mean, are you going to create a separate
> >> branch
> >> or make master the -rc?
> >>
> >>  Creating a separate branch (which is what we do today, iiuc) makes it
> >> get less attention, freezing master for a certain period is the best
> >> way to stabilize.
> >>
> >>  Is this what you had in mind?
> >>
> >>
> > What do people think?
> >
> > One reason I branch is because some people care a bit less about releases
> > so it makes the process non-disruptive to them.  If the other maintainers
> > agreed though, I would certainly like to have the master branch essentially
> > frozen for the week before the release.
> >
> 
> freezing is only neccesary if you need time to gather all the patches, build
> and test them together etc. 

 Not exactly, freezing is done to stop/slowdown writing new code and focus
on bug fixing for a period of time.

 This is not only needed for a release, but projects should always try
to find the best balance between 'number of bugs' and 'feature addition rate'.

> If you don't feel you or the developers need to
> do that to get a reliable release out I think it only halts developers
> without any clear reason to do so. Calling 'attention' to a release is not a
> clear reason IMO.

 Having a functional and relatively stable release is not only
important, but it's the ultimate goal IMO.

 Obviously we should take care not to take extremes. No QEMU release
will be 100% bug free, that's why we have stables.

Re: [Qemu-devel] Release plan for 0.12.0

[Gerd Hoffmann]

On 09/30/09 16:45, Anthony Liguori wrote:
> One reason I branch is because some people care a bit less about
> releases so it makes the process non-disruptive to them. If the other
> maintainers agreed though, I would certainly like to have the master
> branch essentially frozen for the week before the release.

We had much longer disruptions without a release freeze, so why worry 
about a single week?  One week freeze is short enougth that the 
disruption isn't a big issue.  It will help testing the to-be-released 
code.  Go for it.

cheers,
   Gerd

Re: [Qemu-devel] Release plan for 0.12.0

[Natalia Portillo]

for target-i386 and target-x86_64:

o EFI firmware emulation (as a machine or command line option)
o OS/2 1.x support

for target-m68k

o Macintosh support at least to boot an Apple Toolbox (the firmware)

for target-ppc

o Mac OS X support (there is already a open source emulator able to  
boot it shouldn't be so difficult to correct QEMU bugs on it)

for target-mips

o Windows NT support

integrating target-alpha and target-zxspectrum in the branch tree
a new official os support list design (please, give me ideas, css,  
help, anything!) with a better captcha

El 30/09/2009, a las 00:54, Anthony Liguori escribió:

> Hi,
>
> Now that 0.11.0 is behind us, it's time to start thinking about  
> 0.12.0.
>
> I'd like to do a few things different this time around.  I don't  
> think the -rc process went very well as I don't think we got more  
> testing out of it.  I'd like to shorten the timeline for 0.12.0 a  
> good bit.  The 0.10 stable tree got pretty difficult to maintain  
> toward the end of the cycle.  We also had a pretty huge amount of  
> change between 0.10 and 0.11 so I think a shorter cycle is warranted.
>
> I think aiming for early to mid-December would give us roughly a 3  
> month cycle and would align well with some of the Linux distribution  
> cycles.  I'd like to limit things to a single -rc that lasted only  
> for about a week.  This is enough time to fix most of the obvious  
> issues I think.
>
> I'd also like to try to enumerate some features for this release.   
> Here's a short list of things I expect to see for this release  
> (target-i386 centric).  Please add or comment on items that you'd  
> either like to see in the release or are planning on working on.
>
> o VMState conversion -- I expect most of the pc target to be completed
> o qdev conversion -- I hope that we'll get most of the pc target  
> completely converted to qdev
> o storage live migration
> o switch to SeaBIOS (need to finish porting features from Bochs)
> o switch to gPXE (need to resolve slirp tftp server issue)
> o KSM integration
> o in-kernel APIC support for KVM
> o guest SMP support for KVM
> o updates to the default pc machine type
>
> Please add to this list and I'll collect it all and post it somewhere.
>
> Thanks!
>
> -- 
> Regards,
>
> Anthony Liguori
>
>
>
>

Re: [Qemu-devel] Release plan for 0.12.0

[Carl-Daniel Hailfinger]

On 01.10.2009 03:55, Natalia Portillo wrote:
> for target-i386 and target-x86_64:
>
> o EFI firmware emulation (as a machine or command line option)

Are there any opensource EFI implementations with hardware init? I know
that an opensource EFI glue layer exists, but AFAIK hardware init is
still closed source. That leaves coreboot+UEFI (works somewhat) or
SeaBIOS+UEFI (no idea if this is possible). If I missed an announcement
about opensource hw init for EFI, I wish to apologize.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [Qemu-devel] Release plan for 0.12.0

[Jordan Justen]

I work for Intel on the edk2.tianocore.org project.  Related
to QEMU & UEFI, I am working on this project:
https://edk2.tianocore.org/OVMF.html

So, I would like to see 0.12 support UEFI, and it'd be great
if our OVMF project could enable this.

Related to OVMF I submitted this patch in August:
http://patchwork.ozlabs.org/patch/31009/
I hope this patch would enable QEMU to ship the legacy
bochs BIOS, and OVMF.  The user would be able to select
the OVMF UEFI firmware via the -M command line parameter.

-Jordan

On Thu, Oct 1, 2009 at 01:07, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006@gmx.net> wrote:
>
> On 01.10.2009 03:55, Natalia Portillo wrote:
> > for target-i386 and target-x86_64:
> >
> > o EFI firmware emulation (as a machine or command line option)
>
> Are there any opensource EFI implementations with hardware init? I know
> that an opensource EFI glue layer exists, but AFAIK hardware init is
> still closed source. That leaves coreboot+UEFI (works somewhat) or
> SeaBIOS+UEFI (no idea if this is possible). If I missed an announcement
> about opensource hw init for EFI, I wish to apologize.
>
> Regards,
> Carl-Daniel
>
> --
> http://www.hailfinger.org/
>
>
>

Re: [Qemu-devel] Release plan for 0.12.0

[Natalia Portillo]

The only opensource EFI implementation I know about is the Intel EFI  
Reference.

Dunno if it includes hardware initialization.

El 01/10/2009, a las 09:07, Carl-Daniel Hailfinger escribió:

> On 01.10.2009 03:55, Natalia Portillo wrote:
>> for target-i386 and target-x86_64:
>>
>> o EFI firmware emulation (as a machine or command line option)
>
> Are there any opensource EFI implementations with hardware init? I  
> know
> that an opensource EFI glue layer exists, but AFAIK hardware init is
> still closed source. That leaves coreboot+UEFI (works somewhat) or
> SeaBIOS+UEFI (no idea if this is possible). If I missed an  
> announcement
> about opensource hw init for EFI, I wish to apologize.
>
> Regards,
> Carl-Daniel
>
> -- 
> http://www.hailfinger.org/
>
>

Re: [Qemu-devel] Release plan for 0.12.0

[Jordan Justen]

I work for Intel on the edk2.tianocore.org project.  (Compared to the
original edk) edk2 may be of interest to those on this list since it
supports building on several OS's with several different toolchains.
In other words, it also supports building under Linux and OS X with
the GNU compiler and binutils.

Within our edk2 tree, we have two projects that relate to QEMU.

The DUET platform is a UEFI emulator that boots like a legacy OS on
top of a legacy BIOS.  It contains various hardware initialization
drivers for several legacy hardware devices, but it also will call
into the legacy BIOS and make use of certain items from the legacy
BIOS.  DUET can boot from the QEMU legacy BIOS, but it does require a
disk to be setup to have the DUET image on it.  I am not sure if all
of DUET's code is currently safe for a UEFI OS to be able to access
UEFI runtime services.

The OVMF platform is a project to build a (mostly) UEFI compatible
firmware for virtual machines.  QEMU support is one of the main goals
for OVMF.  The OVMF rom image completely replaces QEMU's standard
bios.bin, and therefore we must have hardware drivers for any hardware
within the QEMU VM that we want to make use of.  The project also has
the goal to support UEFI OS's at runtime.

-Jordan

On Thu, Oct 1, 2009 at 21:38, Natalia Portillo <claunia@claunia.com> wrote:
>
> The only opensource EFI implementation I know about is the Intel EFI Reference.
>
> Dunno if it includes hardware initialization.
>
> El 01/10/2009, a las 09:07, Carl-Daniel Hailfinger escribió:
>
>> On 01.10.2009 03:55, Natalia Portillo wrote:
>>>
>>> for target-i386 and target-x86_64:
>>>
>>> o EFI firmware emulation (as a machine or command line option)
>>
>> Are there any opensource EFI implementations with hardware init? I know
>> that an opensource EFI glue layer exists, but AFAIK hardware init is
>> still closed source. That leaves coreboot+UEFI (works somewhat) or
>> SeaBIOS+UEFI (no idea if this is possible). If I missed an announcement
>> about opensource hw init for EFI, I wish to apologize.
>>
>> Regards,
>> Carl-Daniel
>>
>> --
>> http://www.hailfinger.org/
>>
>>
>
>
>

Re: [Qemu-devel] Release plan for 0.12.0

[Carl-Daniel Hailfinger]

Hi Jordan,

thanks for the detailed explanation. It certainly helped me understand
some parts of the tianocore umbrealla better.

On 02.10.2009 07:37, Jordan Justen wrote:
> I work for Intel on the edk2.tianocore.org project.  (Compared to the
> original edk) edk2 may be of interest to those on this list since it
> supports building on several OS's with several different toolchains.
> In other words, it also supports building under Linux and OS X with
> the GNU compiler and binutils.
>   

Neat. I remember the toolchain issues Linux-based developers had in the
past, so I think this is a good thing.


> Within our edk2 tree, we have two projects that relate to QEMU.
>
> The DUET platform is a UEFI emulator that boots like a legacy OS on
> top of a legacy BIOS.  It contains various hardware initialization
> drivers for several legacy hardware devices, but it also will call
> into the legacy BIOS and make use of certain items from the legacy
> BIOS.  DUET can boot from the QEMU legacy BIOS, but it does require a
> disk to be setup to have the DUET image on it.  I am not sure if all
> of DUET's code is currently safe for a UEFI OS to be able to access
> UEFI runtime services.
>   

By the way, SeaBIOS can boot virtual floppy images stored in the ROM (at
least when SeaBIOS runs as coreboot payload), so if you can fit DUET
into a floppy image (or if Kevin adds support for virtual harddisk
images), you can have a coreboot+SeaBIOS+DUET ROM right now.


> The OVMF platform is a project to build a (mostly) UEFI compatible
> firmware for virtual machines.  QEMU support is one of the main goals
> for OVMF.  The OVMF rom image completely replaces QEMU's standard
> bios.bin, and therefore we must have hardware drivers for any hardware
> within the QEMU VM that we want to make use of.  The project also has
> the goal to support UEFI OS's at runtime.
>   

So OVMF is not just hardware init, but a complete package of hardware
init and UEFI interface?


Regards,
Carl-Daniel

Re: [Qemu-devel] Release plan for 0.12.0

[Anthony Liguori]

Natalia Portillo wrote:
> for target-i386 and target-x86_64:
>
> o EFI firmware emulation (as a machine or command line option)
> o OS/2 1.x support

AFAIK, no one is actually working on these.  EFI is also not terribly 
useful without a CSM and I suspect porting SeaBIOS to tiano core is 
going to be a big effort.

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] Release plan for 0.12.0

[Jordan Justen]

On Thu, Oct 1, 2009 at 05:45, Anthony Liguori <aliguori@us.ibm.com> wrote:
> Natalia Portillo wrote:
>>
>> for target-i386 and target-x86_64:
>>
>> o EFI firmware emulation (as a machine or command line option)
>> o OS/2 1.x support
>
> AFAIK, no one is actually working on these.  EFI is also not terribly useful
> without a CSM and I suspect porting SeaBIOS to tiano core is going to be a
> big effort.

Several Linux distributions are getting UEFI support ironed out now,
so UEFI can be used without a CSM.  QEMU support for UEFI could
help the Linux distributions to enable UEFI support...

Windows Vista and 7 support UEFI on x64-64, but I've not been able
to boot either with the OVMF project yet.  (I suspect that the video driver
might not be initializing correctly, but the root cause of the failure is not
yet known.)

>
> --
> Regards,
>
> Anthony Liguori
>
>
>
>

Re: [Qemu-devel] Release plan for 0.12.0

[Anthony Liguori]

Jordan Justen wrote:
> On Thu, Oct 1, 2009 at 05:45, Anthony Liguori <aliguori@us.ibm.com> wrote:
>   
>> Natalia Portillo wrote:
>>     
>>> for target-i386 and target-x86_64:
>>>
>>> o EFI firmware emulation (as a machine or command line option)
>>> o OS/2 1.x support
>>>       
>> AFAIK, no one is actually working on these.  EFI is also not terribly useful
>> without a CSM and I suspect porting SeaBIOS to tiano core is going to be a
>> big effort.
>>     
>
> Several Linux distributions are getting UEFI support ironed out now,
> so UEFI can be used without a CSM.  QEMU support for UEFI could
> help the Linux distributions to enable UEFI support...
>   

I see a CSM as a pre-requisite for merging a uefi rom.  A user can 
already use a uefi rom by simply using the -bios parameter so there's 
nothing inhibiting testing.  My concern about introducing a new machine 
type is that it would require duplicate testing and force the selection 
of uefi up through the management tool stack.

OTH, uefi + a CSM based on SeaBIOS could be used as the default 
firmware.  I don't think it's a reasonable target for 0.12 but I think 
if someone actively worked on it, it would be possible for future releases.

Regards,

Anthony Liguori

Re: [Qemu-devel] Release plan for 0.12.0

[Jordan Justen]

On Thu, Oct 1, 2009 at 14:23, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Jordan Justen wrote:
>>
>> On Thu, Oct 1, 2009 at 05:45, Anthony Liguori <aliguori@us.ibm.com> wrote:
>>
>>>
>>> Natalia Portillo wrote:
>>>
>>>>
>>>> for target-i386 and target-x86_64:
>>>>
>>>> o EFI firmware emulation (as a machine or command line option)
>>>> o OS/2 1.x support
>>>>
>>>
>>> AFAIK, no one is actually working on these.  EFI is also not terribly
>>> useful
>>> without a CSM and I suspect porting SeaBIOS to tiano core is going to be
>>> a
>>> big effort.
>>>
>>
>> Several Linux distributions are getting UEFI support ironed out now,
>> so UEFI can be used without a CSM.  QEMU support for UEFI could
>> help the Linux distributions to enable UEFI support...
>>
>
> I see a CSM as a pre-requisite for merging a uefi rom.  A user can already
> use a uefi rom by simply using the -bios parameter so there's nothing
> inhibiting testing.  My concern about introducing a new machine type is that
> it would require duplicate testing and force the selection of uefi up
> through the management tool stack.

I understand your points.  You want to keep a single machine type and
try to support UEFI and legacy boots with that firmware.
Unfortunately, I don't know that we will be able to provide that via
OVMF.  There is no open source CSM for us to make use of.

And, it is true that -bios can be used for OVMF by those with a
particular interest in UEFI.  But for a more general audience, I think
without the -M switch a Linux distribution couldn't package qemu in
such a way that both a legacy bios and the OVMF firmware would be
available.

> OTH, uefi + a CSM based on SeaBIOS could be used as the default firmware.  I
> don't think it's a reasonable target for 0.12 but I think if someone
> actively worked on it, it would be possible for future releases.

I don't know of any efforts to create an open source CSM.  Is someone
working on converting SeaBIOS to act as a CSM?

For tianocore.org & OVMF we would further be restricted by requiring a
BSD licensed CSM.  Of course, if there was a SeaBIOS based CSM, then
I'm sure OVMF could be modified to make use of it easily enough.  We
just wouldn't be able to have the SeaBIOS CSM on tianocore.org and
part of the normal tianocore.org OVMF releases.

>
> Regards,
>
> Anthony Liguori
>

Re: [Qemu-devel] Release plan for 0.12.0

[Anthony Liguori]

Jordan Justen wrote:
> On Thu, Oct 1, 2009 at 14:23, Anthony Liguori <anthony@codemonkey.ws> wrote:
>   
>> I see a CSM as a pre-requisite for merging a uefi rom.  A user can already
>> use a uefi rom by simply using the -bios parameter so there's nothing
>> inhibiting testing.  My concern about introducing a new machine type is that
>> it would require duplicate testing and force the selection of uefi up
>> through the management tool stack.
>>     
>
> I understand your points.  You want to keep a single machine type and
> try to support UEFI and legacy boots with that firmware.
> Unfortunately, I don't know that we will be able to provide that via
> OVMF.  There is no open source CSM for us to make use of.
>
> And, it is true that -bios can be used for OVMF by those with a
> particular interest in UEFI.  But for a more general audience, I think
> without the -M switch a Linux distribution couldn't package qemu in
> such a way that both a legacy bios and the OVMF firmware would be
> available.
>   

My concern is that if we provide separate machine types, it doubles our 
testing since we have to test guests with both the BIOS firmware and the 
UEFI firmware.  It also hurts usability since a user now has to make the 
decision as to whether they want to use UEFI or not.  A user should not 
have to even know what EFI is.

So I think the best way forward is to hold off on UEFI in mainline until 
we can provide a single unified stack.

>> OTH, uefi + a CSM based on SeaBIOS could be used as the default firmware.  I
>> don't think it's a reasonable target for 0.12 but I think if someone
>> actively worked on it, it would be possible for future releases.
>>     
>
> I don't know of any efforts to create an open source CSM.  Is someone
> working on converting SeaBIOS to act as a CSM?
>   

There are multiple parties that seem to be interested in uefi for 
guests.  I expect that one of those parties will end up doing the work 
if that's the requirement that we put down.

> For tianocore.org & OVMF we would further be restricted by requiring a
> BSD licensed CSM.  Of course, if there was a SeaBIOS based CSM, then
> I'm sure OVMF could be modified to make use of it easily enough.  We
> just wouldn't be able to have the SeaBIOS CSM on tianocore.org and
> part of the normal tianocore.org OVMF releases.
>   

I don't think that's a big problem for us.

Regards,

Anthony Liguori

Re: [Qemu-devel] Release plan for 0.12.0

[Jordan Justen]

On Fri, Oct 2, 2009 at 06:29, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Jordan Justen wrote:
>>
>> On Thu, Oct 1, 2009 at 14:23, Anthony Liguori <anthony@codemonkey.ws>
>> wrote:
>>
>>>
>>> I see a CSM as a pre-requisite for merging a uefi rom.  A user can
>>> already
>>> use a uefi rom by simply using the -bios parameter so there's nothing
>>> inhibiting testing.  My concern about introducing a new machine type is
>>> that
>>> it would require duplicate testing and force the selection of uefi up
>>> through the management tool stack.
>>>
>>
>> I understand your points.  You want to keep a single machine type and
>> try to support UEFI and legacy boots with that firmware.
>> Unfortunately, I don't know that we will be able to provide that via
>> OVMF.  There is no open source CSM for us to make use of.
>>
>> And, it is true that -bios can be used for OVMF by those with a
>> particular interest in UEFI.  But for a more general audience, I think
>> without the -M switch a Linux distribution couldn't package qemu in
>> such a way that both a legacy bios and the OVMF firmware would be
>> available.
>>
>
> My concern is that if we provide separate machine types, it doubles our
> testing since we have to test guests with both the BIOS firmware and the
> UEFI firmware.  It also hurts usability since a user now has to make the
> decision as to whether they want to use UEFI or not.  A user should not have
> to even know what EFI is.
>
> So I think the best way forward is to hold off on UEFI in mainline until we
> can provide a single unified stack.

Ok.  I understand if this is the way the QEMU project wants to
proceed.  I think it might delay UEFI support somewhat, but it
certainly would be better for the user if they did not have to provide
the correct command line to boot.

While it is true that a separate machine type could potentially be
viewed as increasing the testing requirements, I am not so sure.  If
QEMU has a UEFI+CSM solution, wouldn't we still have to test both UEFI
based OS boot and the CSM based legacy OS boot?

>>> OTH, uefi + a CSM based on SeaBIOS could be used as the default firmware.
>>>  I
>>> don't think it's a reasonable target for 0.12 but I think if someone
>>> actively worked on it, it would be possible for future releases.
>>>
>>
>> I don't know of any efforts to create an open source CSM.  Is someone
>> working on converting SeaBIOS to act as a CSM?
>>
>
> There are multiple parties that seem to be interested in uefi for guests.  I
> expect that one of those parties will end up doing the work if that's the
> requirement that we put down.
>
>> For tianocore.org & OVMF we would further be restricted by requiring a
>> BSD licensed CSM.  Of course, if there was a SeaBIOS based CSM, then
>> I'm sure OVMF could be modified to make use of it easily enough.  We
>> just wouldn't be able to have the SeaBIOS CSM on tianocore.org and
>> part of the normal tianocore.org OVMF releases.
>>
>
> I don't think that's a big problem for us.

Yes, I agree that this is would not be a problem for QEMU.  In fact,
I'd like to take back my opinion regarding how this may or may not be
usable by tianocore.org and OVMF.  Although we don't have GPL code
hosted within any of our tianocore.org projects at this time, maybe
this could change...

I do know that we don't intend to start an open source CSM project on
tianocore.org at this time.

But, if such a project was started, I think we would support
development via email on our edk2 dev list, and potentially even host
the project on tianocore.org.

So, I would invite anyone thinking of tackling such a task to join the
edk2 dev list to discuss your work.  Furthermore, if you'd like to
request the project to be hosted on tianocore.org, feel free to ask
our administrators.  (As mentioned previously, we usually deal with
the BSD license on tianocore.org, but please don't let this hold you
back from asking questions, or requesting hosting of your project.)

Thanks,

-Jordan

Re: [Qemu-devel] Release plan for 0.12.0

[Carl-Daniel Hailfinger]

On 02.10.2009 18:58, Jordan Justen wrote:
> On Fri, Oct 2, 2009 at 06:29, Anthony Liguori <anthony@codemonkey.ws> wrote:
>   
>> So I think the best way forward is to hold off on UEFI in mainline until we
>> can provide a single unified stack.
>>     
>
> While it is true that a separate machine type could potentially be
> viewed as increasing the testing requirements, I am not so sure.  If
> QEMU has a UEFI+CSM solution, wouldn't we still have to test both UEFI
> based OS boot and the CSM based legacy OS boot?
>   

Given that you can easily pack coreboot+SeaBIOS+UEFI into one ROM and
have coreboot boot either SeaBIOS (BIOS interface) or UEFI (EFI
interface), wouldn't that solve all problems in one go? You get an
unified stack and don't have to mess around with different firmware
files because coreboot can read in a Qemu machine config option (or
NVRAM/CMOS) and select the interface based on that.

The hardware init part would be identical for all variants, only the
interface would differ. coreboot works now and has the benefit of
supporting real hardware as well, so the difference between a setup
inside Qemu and a setup on real hardware is minimal.


>>> I don't know of any efforts to create an open source CSM.  Is someone
>>> working on converting SeaBIOS to act as a CSM?
>>>       

The coreboot solution would also avoid converting SeaBIOS because
SeaBIOS already works as coreboot payload (that's how coreboot
developers call the CSM).


> I do know that we don't intend to start an open source CSM project on
> tianocore.org at this time.
>
> But, if such a project was started, I think we would support
> development via email on our edk2 dev list, and potentially even host
> the project on tianocore.org.
>
> So, I would invite anyone thinking of tackling such a task to join the
> edk2 dev list to discuss your work.  Furthermore, if you'd like to
> request the project to be hosted on tianocore.org, feel free to ask
> our administrators.  (As mentioned previously, we usually deal with
> the BSD license on tianocore.org, but please don't let this hold you
> back from asking questions, or requesting hosting of your project.)
>   

I do invite everyone who is interested in having one single ROM file
with EFI+SeaBIOS to join the coreboot list as well. We already have
coreboot+SeaBIOS running (both on hardware and inside Qemu) and
coreboot+tianocore works as well. It has the advantage of requiring zero
changes in coreboot, zero changes in SeaBIOS and (I think) zero changes
in Tianocore.

As a nice side benefit for the EFI specialists, you get the ability to
run EFI on every coreboot supported platform.


If you have any questions, please ask.

Regards,
Carl-Daniel

Re: [Qemu-devel] Release plan for 0.12.0

[Anthony Liguori]

Carl-Daniel Hailfinger wrote:
> On 02.10.2009 18:58, Jordan Justen wrote:
>   
>> On Fri, Oct 2, 2009 at 06:29, Anthony Liguori <anthony@codemonkey.ws> wrote:
>>   
>>     
>>> So I think the best way forward is to hold off on UEFI in mainline until we
>>> can provide a single unified stack.
>>>     
>>>       
>> While it is true that a separate machine type could potentially be
>> viewed as increasing the testing requirements, I am not so sure.  If
>> QEMU has a UEFI+CSM solution, wouldn't we still have to test both UEFI
>> based OS boot and the CSM based legacy OS boot?
>>   
>>     
>
> Given that you can easily pack coreboot+SeaBIOS+UEFI into one ROM and
> have coreboot boot either SeaBIOS (BIOS interface) or UEFI (EFI
> interface), wouldn't that solve all problems in one go? You get an
> unified stack and don't have to mess around with different firmware
> files because coreboot can read in a Qemu machine config option (or
> NVRAM/CMOS) and select the interface based on that.
>   

If you want to to work seamlessly, you need to check for the EFI system 
partition to see whether it's an EFI capable OS and then fallback 
gracefully to SeaBIOS boot.

> The hardware init part would be identical for all variants, only the
> interface would differ. coreboot works now and has the benefit of
> supporting real hardware as well, so the difference between a setup
> inside Qemu and a setup on real hardware is minimal.
>   

Tianocore's OVMF project should provide all the required initialization 
for EFI on QEMU.

> The coreboot solution would also avoid converting SeaBIOS because
> SeaBIOS already works as coreboot payload (that's how coreboot
> developers call the CSM).
>   

I'll bite, what's the advantage of doing coreboot + SeaBIOS vs. SeaBIOS 
alone?  Forget about EFI for the moment, should be considering switching 
to coreboot + SeaBIOS for 0.12?

Regards,

Anthony Liguori

Re: [Qemu-devel] Release plan for 0.12.0

[Carl-Daniel Hailfinger]

[Adding the coreboot list to CC. Please ignore the moderation messages,
your addresses will be whitelisted ASAP.]

On 02.10.2009 20:53, Anthony Liguori wrote:
> Carl-Daniel Hailfinger wrote:
>> Given that you can easily pack coreboot+SeaBIOS+UEFI into one ROM and
>> have coreboot boot either SeaBIOS (BIOS interface) or UEFI (EFI
>> interface), wouldn't that solve all problems in one go? You get an
>> unified stack and don't have to mess around with different firmware
>> files because coreboot can read in a Qemu machine config option (or
>> NVRAM/CMOS) and select the interface based on that.
>>   
>
> If you want to to work seamlessly, you need to check for the EFI
> system partition to see whether it's an EFI capable OS and then
> fallback gracefully to SeaBIOS boot.

Hm. Wouldn't that be a layering violation (hw init != reading the disk)
and also cause problems if you want to boot an EFI capable OS from
SeaBIOS? I can think of someone having an EFI bootable disk image who
wants to boot that disk image with EFI and BIOS without having to
repartition.


>> The hardware init part would be identical for all variants, only the
>> interface would differ. coreboot works now and has the benefit of
>> supporting real hardware as well, so the difference between a setup
>> inside Qemu and a setup on real hardware is minimal.   
>
> Tianocore's OVMF project should provide all the required
> initialization for EFI on QEMU.

Yes, but then we'd have two sets of hardware init: OVMF for EFI, SeaBIOS
for SeaBIOS. That also means each hw init codebase has to support the
new Q35 chipset proposed for Qemu.

It's not any better if SeaBIOS gets changed into a CSM for EFI. Then you
have SeaBIOS on top of EFI on top of OVMF. As I understand it, OVMF had
less testing than the Bochs BIOS or SeaBIOS on Qemu.

Jordan, I have to admit that I'm surprised OVMF was apparently created
from scratch although quite a few (established) hardware init solutions
already exist for Qemu: SeaBIOS, Bochs BIOS, coreboot, and some old
hobbyist projects. I'd like to understand the reasons for that and fix
them in coreboot (Kevin O'Connor will probably fix them in SeaBIOS). If
you ported/modified existing code, I'd be interested in the original
codebase to learn from it (especially what you had to change).


>> The coreboot solution would also avoid converting SeaBIOS because
>> SeaBIOS already works as coreboot payload (that's how coreboot
>> developers call the CSM).
>>   
>
> I'll bite, what's the advantage of doing coreboot + SeaBIOS vs.
> SeaBIOS alone?  Forget about EFI for the moment, should be considering
> switching to coreboot + SeaBIOS for 0.12?

Advantages:
- Code coverage increase: SeaBIOS is used with coreboot on real
hardware, so the BIOS interface part of SeaBIOS gets a lot more testing
than the Qemu hardware init part of SeaBIOS.

- coreboot supports real 440BX hardware besides Qemu, so the coreboot
init code is exercised more (and there is still a sizable number of such
machines around (clusters), many of them running coreboot).

- Only one ROM image needed. A coreboot ROM can pack the VGA BIOS into
the ROM image and SeaBIOS will automatically load it from there. Same
for network card ROMs (with gPXE etc.).

- coreboot ROMs (including those with SeaBIOS and/or EFI and/or VGABIOS)
are archives and can be listed/edited with cbfstool if you want to know
what's in there.

- coreboot ROMs use compression, so you can stuff more code (and PCI
option ROMs) into smaller ROMs.

- coreboot has pretty verbose hardware init messages (if you want that)
and can be totally silent as well. The messages end up in a log buffer
which can be read by the OS (experimental feature, not available by
default).

There are a lot more advantages, but I want to give other coreboot
developers a chance to chime in. If you add EFI to the mix, the
synergies increase.


Regards,
Carl-Daniel

Re: [Qemu-devel] Release plan for 0.12.0

[Jordan Justen]

On Fri, Oct 2, 2009 at 14:39, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006@gmx.net> wrote:
> [Adding the coreboot list to CC. Please ignore the moderation messages,
> your addresses will be whitelisted ASAP.]
>
> On 02.10.2009 20:53, Anthony Liguori wrote:
>> Carl-Daniel Hailfinger wrote:
>>> Given that you can easily pack coreboot+SeaBIOS+UEFI into one ROM and
>>> have coreboot boot either SeaBIOS (BIOS interface) or UEFI (EFI
>>> interface), wouldn't that solve all problems in one go? You get an
>>> unified stack and don't have to mess around with different firmware
>>> files because coreboot can read in a Qemu machine config option (or
>>> NVRAM/CMOS) and select the interface based on that.
>>>
>>
>> If you want to to work seamlessly, you need to check for the EFI
>> system partition to see whether it's an EFI capable OS and then
>> fallback gracefully to SeaBIOS boot.
>
> Hm. Wouldn't that be a layering violation (hw init != reading the disk)
> and also cause problems if you want to boot an EFI capable OS from
> SeaBIOS? I can think of someone having an EFI bootable disk image who
> wants to boot that disk image with EFI and BIOS without having to
> repartition.
>
>
>>> The hardware init part would be identical for all variants, only the
>>> interface would differ. coreboot works now and has the benefit of
>>> supporting real hardware as well, so the difference between a setup
>>> inside Qemu and a setup on real hardware is minimal.
>>
>> Tianocore's OVMF project should provide all the required
>> initialization for EFI on QEMU.
>
> Yes, but then we'd have two sets of hardware init: OVMF for EFI, SeaBIOS
> for SeaBIOS. That also means each hw init codebase has to support the
> new Q35 chipset proposed for Qemu.
>
> It's not any better if SeaBIOS gets changed into a CSM for EFI. Then you
> have SeaBIOS on top of EFI on top of OVMF. As I understand it, OVMF had
> less testing than the Bochs BIOS or SeaBIOS on Qemu.
>
> Jordan, I have to admit that I'm surprised OVMF was apparently created
> from scratch although quite a few (established) hardware init solutions
> already exist for Qemu: SeaBIOS, Bochs BIOS, coreboot, and some old
> hobbyist projects.

The edk2 project provides an infrastructure for building complete UEFI
firmware solutions.  OVMF is a sample platform which demonstrates how
edk2 can be used to build firmware to boot a UEFI platform.

Aside from just this, OVMF is an effort to support VMs on edk2.  (Ie,
more than just QEMU.)  Ideally the project, and code of OVMF could be
used by any VM vendor as a sample for building UEFI compatible
firmware.

Most of the code required to support QEMU was already open sourced on
edk2 before OVMF was launched.  At the time that we started OVMF, it
did not seem like any project was targeting UEFI support on QEMU.
Tristan Gingold had done a port for UEFI QEMU support, but at that
time it did not seem to be functional with the current QEMU, nor
actively developed.

> I'd like to understand the reasons for that and fix
> them in coreboot (Kevin O'Connor will probably fix them in SeaBIOS).

If you want to remove any need for OVMF on QEMU, then I think all that
is needed is to support booting UEFI OS's for both i386 and x86-64.
Of course, we may still have some use for the OVMF project on edk2 as
a sample platform.

> If
> you ported/modified existing code, I'd be interested in the original
> codebase to learn from it (especially what you had to change).

As I mentioned above, a good portion of the code was already available
in edk2.tianocore.org.  Edk2 is BSD licensed, and therefore from a
licensing perspective should be easy for your project to utilize.

>
>>> The coreboot solution would also avoid converting SeaBIOS because
>>> SeaBIOS already works as coreboot payload (that's how coreboot
>>> developers call the CSM).
>>>
>>
>> I'll bite, what's the advantage of doing coreboot + SeaBIOS vs.
>> SeaBIOS alone?  Forget about EFI for the moment, should be considering
>> switching to coreboot + SeaBIOS for 0.12?
>
> Advantages:
> - Code coverage increase: SeaBIOS is used with coreboot on real
> hardware, so the BIOS interface part of SeaBIOS gets a lot more testing
> than the Qemu hardware init part of SeaBIOS.
>
> - coreboot supports real 440BX hardware besides Qemu, so the coreboot
> init code is exercised more (and there is still a sizable number of such
> machines around (clusters), many of them running coreboot).
>
> - Only one ROM image needed. A coreboot ROM can pack the VGA BIOS into
> the ROM image and SeaBIOS will automatically load it from there. Same
> for network card ROMs (with gPXE etc.).
>
> - coreboot ROMs (including those with SeaBIOS and/or EFI and/or VGABIOS)
> are archives and can be listed/edited with cbfstool if you want to know
> what's in there.
>
> - coreboot ROMs use compression, so you can stuff more code (and PCI
> option ROMs) into smaller ROMs.
>
> - coreboot has pretty verbose hardware init messages (if you want that)
> and can be totally silent as well. The messages end up in a log buffer
> which can be read by the OS (experimental feature, not available by
> default).
>
> There are a lot more advantages, but I want to give other coreboot
> developers a chance to chime in. If you add EFI to the mix, the
> synergies increase.
>
>
> Regards,
> Carl-Daniel
>

Re: [Qemu-devel] Release plan for 0.12.0

[Carl-Daniel Hailfinger]

On 03.10.2009 00:28, Jordan Justen wrote:
> On Fri, Oct 2, 2009 at 14:39, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006@gmx.net> wrote:
>   
>> Jordan, I have to admit that I'm surprised OVMF was apparently created
>> from scratch although quite a few (established) hardware init solutions
>> already exist for Qemu: SeaBIOS, Bochs BIOS, coreboot, and some old
>> hobbyist projects.
>>     
>
> The edk2 project provides an infrastructure for building complete UEFI
> firmware solutions.  OVMF is a sample platform which demonstrates how
> edk2 can be used to build firmware to boot a UEFI platform.
>   

I wish to apologize for the misunderstanding. I thought OVMF was only
hardware init. Thanks for correcting me.


> Aside from just this, OVMF is an effort to support VMs on edk2.  (Ie,
> more than just QEMU.)  Ideally the project, and code of OVMF could be
> used by any VM vendor as a sample for building UEFI compatible
> firmware.
>   

How does it relate to real hardware? You mention OVMF as an effort to
support VMs on edk2. Does this mean that VMs need special support or
that real hardware has different needs?


> Most of the code required to support QEMU was already open sourced on
> edk2 before OVMF was launched.  At the time that we started OVMF, it
> did not seem like any project was targeting UEFI support on QEMU.
> Tristan Gingold had done a port for UEFI QEMU support, but at that
> time it did not seem to be functional with the current QEMU, nor
> actively developed.
>   

I see.


>> I'd like to understand the reasons for that and fix
>> them in coreboot (Kevin O'Connor will probably fix them in SeaBIOS).
>>     
>
> If you want to remove any need for OVMF on QEMU, then I think all that
> is needed is to support booting UEFI OS's for both i386 and x86-64.
> Of course, we may still have some use for the OVMF project on edk2 as
> a sample platform.
>   

Given that my original statement incorrectly assumed OVMF was only about
hardware init, please let me try to express what I originally meant (and
which came across with unintended meaning).
I hope to use all EFI support code from OVMF, keep SeaBIOS, and have
coreboot as common hardware init base.


>> If
>> you ported/modified existing code, I'd be interested in the original
>> codebase to learn from it (especially what you had to change).
>>     
>
> As I mentioned above, a good portion of the code was already available
> in edk2.tianocore.org.

Thanks for the pointer.


> Edk2 is BSD licensed, and therefore from a
> licensing perspective should be easy for your project to utilize.
>   

(Speaking with my coreboot hat on.)
The goal of coreboot is not to assimilate and change other projects, but
to provide hardware init for any code which needs it.

After hardware init, it passes control to a payload (SeaBIOS, UEFI,
GRUB2, FILO, Linux, Plan9...). There are no callbacks to coreboot, each
payload is expected to talk to the hardware on its own. Except for ACPI
tables (and a memory map), nothing of coreboot stays in memory after
passing control to that payload. If you want some basic hardware drivers
for your favourite payload, you can use the BSD-licensed libpayload
library in your code, but most payloads (SeaBIOS, GRUB2, ...) have their
own drivers anyway.
Operating systems like Linux and Plan9 which do not need any BIOS/EFI
interface can be stored in the ROM and will be booted directly by
coreboot (if in ROM). Boot loaders like GRUB2 or FILO don't need
BIOS/EFI either, can be stored in ROM and will then be booted directly.
BIOS and EFI code can be used as a coreboot payload in ROM as well. Some
people are even working on making U-Boot available as coreboot payload.

The idea is to have coreboot handle all the hardware-specific
initialization and allow all other code to be mostly hardware-agnostic
(unless said code wants to implement drivers). The clean interface
(well, no interface, coreboot just passes control to the payload) allows
payloads to do whatever they want as long as they provide a single
32-bit entry point coreboot can jump to.


Regards,
Carl-Daniel

Re: [Qemu-devel] Release plan for 0.12.0

[Jordan Justen]

Carl-Daniel,

It sounds like there is a whole lot of overlap in what coreboot and
tianocore are trying to enable.

The key difference is that tianocore is focused on enabling the UEFI
interfaces within platforms.

OS loaders in UEFI are UEFI applications, and therefore just like in
the case of the UEFI shell (which is a UEFI application), they could
be embedded in the ROM.  So, this is similar to the coreboot payloads
concept.  But, it is not quite as central of a design goal for UEFI
systems as it appears to be within coreboot.

UEFI does provide runtime services that an OS can make use of, so that
sounds a bit different that coreboot.  (Linux does have support for
these interfaces.)  Essentially you can think of UEFI as a better
spec'd version of what the legacy BIOS was, but with more
extensibility designed into the interfaces.

Anyway, it sounds like a useful project might be to develop a UEFI
coreboot payload based on the tianocore.org code.  Our DUET platform
would only work on top of seabios, and OVMF has some overlap in
hardware initialization along with being a VM/QEMU specific solution.
Of course, we are always glad to hear if people are able to make use
of our code, and we like to encourage any UEFI or tianocore related
contributions to tianocore.org.

Thanks,

-Jordan

On Fri, Oct 2, 2009 at 16:05, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006@gmx.net> wrote:
> On 03.10.2009 00:28, Jordan Justen wrote:
>> On Fri, Oct 2, 2009 at 14:39, Carl-Daniel Hailfinger
>> <c-d.hailfinger.devel.2006@gmx.net> wrote:
>>
>>> Jordan, I have to admit that I'm surprised OVMF was apparently created
>>> from scratch although quite a few (established) hardware init solutions
>>> already exist for Qemu: SeaBIOS, Bochs BIOS, coreboot, and some old
>>> hobbyist projects.
>>>
>>
>> The edk2 project provides an infrastructure for building complete UEFI
>> firmware solutions.  OVMF is a sample platform which demonstrates how
>> edk2 can be used to build firmware to boot a UEFI platform.
>>
>
> I wish to apologize for the misunderstanding. I thought OVMF was only
> hardware init. Thanks for correcting me.
>
>
>> Aside from just this, OVMF is an effort to support VMs on edk2.  (Ie,
>> more than just QEMU.)  Ideally the project, and code of OVMF could be
>> used by any VM vendor as a sample for building UEFI compatible
>> firmware.
>>
>
> How does it relate to real hardware? You mention OVMF as an effort to
> support VMs on edk2. Does this mean that VMs need special support or
> that real hardware has different needs?
>
>
>> Most of the code required to support QEMU was already open sourced on
>> edk2 before OVMF was launched.  At the time that we started OVMF, it
>> did not seem like any project was targeting UEFI support on QEMU.
>> Tristan Gingold had done a port for UEFI QEMU support, but at that
>> time it did not seem to be functional with the current QEMU, nor
>> actively developed.
>>
>
> I see.
>
>
>>> I'd like to understand the reasons for that and fix
>>> them in coreboot (Kevin O'Connor will probably fix them in SeaBIOS).
>>>
>>
>> If you want to remove any need for OVMF on QEMU, then I think all that
>> is needed is to support booting UEFI OS's for both i386 and x86-64.
>> Of course, we may still have some use for the OVMF project on edk2 as
>> a sample platform.
>>
>
> Given that my original statement incorrectly assumed OVMF was only about
> hardware init, please let me try to express what I originally meant (and
> which came across with unintended meaning).
> I hope to use all EFI support code from OVMF, keep SeaBIOS, and have
> coreboot as common hardware init base.
>
>
>>> If
>>> you ported/modified existing code, I'd be interested in the original
>>> codebase to learn from it (especially what you had to change).
>>>
>>
>> As I mentioned above, a good portion of the code was already available
>> in edk2.tianocore.org.
>
> Thanks for the pointer.
>
>
>> Edk2 is BSD licensed, and therefore from a
>> licensing perspective should be easy for your project to utilize.
>>
>
> (Speaking with my coreboot hat on.)
> The goal of coreboot is not to assimilate and change other projects, but
> to provide hardware init for any code which needs it.
>
> After hardware init, it passes control to a payload (SeaBIOS, UEFI,
> GRUB2, FILO, Linux, Plan9...). There are no callbacks to coreboot, each
> payload is expected to talk to the hardware on its own. Except for ACPI
> tables (and a memory map), nothing of coreboot stays in memory after
> passing control to that payload. If you want some basic hardware drivers
> for your favourite payload, you can use the BSD-licensed libpayload
> library in your code, but most payloads (SeaBIOS, GRUB2, ...) have their
> own drivers anyway.
> Operating systems like Linux and Plan9 which do not need any BIOS/EFI
> interface can be stored in the ROM and will be booted directly by
> coreboot (if in ROM). Boot loaders like GRUB2 or FILO don't need
> BIOS/EFI either, can be stored in ROM and will then be booted directly.
> BIOS and EFI code can be used as a coreboot payload in ROM as well. Some
> people are even working on making U-Boot available as coreboot payload.
>
> The idea is to have coreboot handle all the hardware-specific
> initialization and allow all other code to be mostly hardware-agnostic
> (unless said code wants to implement drivers). The clean interface
> (well, no interface, coreboot just passes control to the payload) allows
> payloads to do whatever they want as long as they provide a single
> 32-bit entry point coreboot can jump to.
>
>
> Regards,
> Carl-Daniel
>

Re: [Qemu-devel] Release plan for 0.12.0

[Gleb Natapov]

On Fri, Oct 02, 2009 at 11:39:50PM +0200, Carl-Daniel Hailfinger wrote:
> > I'll bite, what's the advantage of doing coreboot + SeaBIOS vs.
> > SeaBIOS alone?  Forget about EFI for the moment, should be considering
> > switching to coreboot + SeaBIOS for 0.12?
> 
> Advantages:
> - Code coverage increase: SeaBIOS is used with coreboot on real
> hardware, so the BIOS interface part of SeaBIOS gets a lot more testing
> than the Qemu hardware init part of SeaBIOS.
> 
> - coreboot supports real 440BX hardware besides Qemu, so the coreboot
> init code is exercised more (and there is still a sizable number of such
> machines around (clusters), many of them running coreboot).
> 
QEMU goal is to run popular OSes and OS usually don't care about low level
chipset details. That's way QEMU's chipset emulation implements only
bare minimum that is needed for OS to run: no need to initialize memory
controller for instance. Coreboot goal, on the other hand, is to talk to
real HW, so to use it on QEMU will require implementing chipset features
that are not needed to accomplish QEMU goal. So for me real 440BX
hardware support of coreboot is actually disadvantage. QEMU don't
have real 440BX hardware and there is not point in having one. It is
possible to implement 440BX-qemu support in coreboot of course if there
are other advantages worth having.

> - Only one ROM image needed. A coreboot ROM can pack the VGA BIOS into
> the ROM image and SeaBIOS will automatically load it from there. Same
> for network card ROMs (with gPXE etc.).
> 
> - coreboot ROMs (including those with SeaBIOS and/or EFI and/or VGABIOS)
> are archives and can be listed/edited with cbfstool if you want to know
> what's in there.
> 
> - coreboot ROMs use compression, so you can stuff more code (and PCI
> option ROMs) into smaller ROMs.
> 
> - coreboot has pretty verbose hardware init messages (if you want that)
> and can be totally silent as well. The messages end up in a log buffer
> which can be read by the OS (experimental feature, not available by
> default).
> 
> There are a lot more advantages, but I want to give other coreboot
> developers a chance to chime in. If you add EFI to the mix, the
> synergies increase.
> 
> 
> Regards,
> Carl-Daniel
> 

--
			Gleb.

Re: [Qemu-devel] Release plan for 0.12.0

[Jordan Justen]

Carl-Daniel,

Interesting.  So, where can I download a QEMU bios rom to boot a UEFI
OS with this solution?

Can you explain what coreboot+tianocore means?  Which parts of
tianocore do you use in this situation?

If your solution can accomplish all of what you say, I'm not sure how
OVMF would be able to compete against in terms of being included with
QEMU.  Part of the reason for starting OVMF was to help enable UEFI
support within VM's such as QEMU.  If OVMF was utilized by QEMU it
definitely would have been a bit of a boost for our efforts, but if
QEMU accomplishes UEFI support via another path, then overall we will
still be happy.

Thanks,

-Jordan

On Fri, Oct 2, 2009 at 11:45, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006@gmx.net> wrote:
> On 02.10.2009 18:58, Jordan Justen wrote:
>> On Fri, Oct 2, 2009 at 06:29, Anthony Liguori <anthony@codemonkey.ws> wrote:
>>
>>> So I think the best way forward is to hold off on UEFI in mainline until we
>>> can provide a single unified stack.
>>>
>>
>> While it is true that a separate machine type could potentially be
>> viewed as increasing the testing requirements, I am not so sure.  If
>> QEMU has a UEFI+CSM solution, wouldn't we still have to test both UEFI
>> based OS boot and the CSM based legacy OS boot?
>>
>
> Given that you can easily pack coreboot+SeaBIOS+UEFI into one ROM and
> have coreboot boot either SeaBIOS (BIOS interface) or UEFI (EFI
> interface), wouldn't that solve all problems in one go? You get an
> unified stack and don't have to mess around with different firmware
> files because coreboot can read in a Qemu machine config option (or
> NVRAM/CMOS) and select the interface based on that.
>
> The hardware init part would be identical for all variants, only the
> interface would differ. coreboot works now and has the benefit of
> supporting real hardware as well, so the difference between a setup
> inside Qemu and a setup on real hardware is minimal.
>
>
>>>> I don't know of any efforts to create an open source CSM.  Is someone
>>>> working on converting SeaBIOS to act as a CSM?
>>>>
>
> The coreboot solution would also avoid converting SeaBIOS because
> SeaBIOS already works as coreboot payload (that's how coreboot
> developers call the CSM).
>
>
>> I do know that we don't intend to start an open source CSM project on
>> tianocore.org at this time.
>>
>> But, if such a project was started, I think we would support
>> development via email on our edk2 dev list, and potentially even host
>> the project on tianocore.org.
>>
>> So, I would invite anyone thinking of tackling such a task to join the
>> edk2 dev list to discuss your work.  Furthermore, if you'd like to
>> request the project to be hosted on tianocore.org, feel free to ask
>> our administrators.  (As mentioned previously, we usually deal with
>> the BSD license on tianocore.org, but please don't let this hold you
>> back from asking questions, or requesting hosting of your project.)
>>
>
> I do invite everyone who is interested in having one single ROM file
> with EFI+SeaBIOS to join the coreboot list as well. We already have
> coreboot+SeaBIOS running (both on hardware and inside Qemu) and
> coreboot+tianocore works as well. It has the advantage of requiring zero
> changes in coreboot, zero changes in SeaBIOS and (I think) zero changes
> in Tianocore.
>
> As a nice side benefit for the EFI specialists, you get the ability to
> run EFI on every coreboot supported platform.
>
>
> If you have any questions, please ask.
>
> Regards,
> Carl-Daniel
>

Re: [Qemu-devel] Release plan for 0.12.0

[Anthony Liguori]

Jordan Justen wrote:
> Carl-Daniel,
>
> Interesting.  So, where can I download a QEMU bios rom to boot a UEFI
> OS with this solution?
>
> Can you explain what coreboot+tianocore means?  Which parts of
> tianocore do you use in this situation?
>
> If your solution can accomplish all of what you say, I'm not sure how
> OVMF would be able to compete against in terms of being included with
> QEMU.  Part of the reason for starting OVMF was to help enable UEFI
> support within VM's such as QEMU.  If OVMF was utilized by QEMU it
> definitely would have been a bit of a boost for our efforts, but if
> QEMU accomplishes UEFI support via another path, then overall we will
> still be happy.
>   

FWIW, I looked more closely at Coreboot + SeaBIOS today.  It's much less 
functional than just SeaBIOS alone.  There really is no additional 
functionality because all payloads that Coreboot can run already run 
directly under QEMU (or under SeaBIOS).

With respect to Coreboot + SeaBIOS + UEFI, AFAIK, you cannot have 
multiple payloads without using essentially a payload switcher (like 
Bayou).  The problem with this though is your just deferring the 
EFI/BIOS choice to the user in a different place.  What we need is a 
mechanism to transparently choose UEFI or SeaBIOS depending on whether 
the guest is EFI aware.

I think option roms further complicate the matter because we would need 
a gPXE EFI module to support network boot.  That makes the switch logic 
even more complicated.  For PCI passthrough, I assume that the legacy 
option ROMs have to be loaded through a CSM so if we want to enable PCI 
passthrough, we really need a proper CSM.

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] Release plan for 0.12.0

[Carl-Daniel Hailfinger]

Hi Jordan,

I have to admit that I'm not the expert for coreboot+EFI solutions. I
know they exist and work, but I'll defer to other developers on the
coreboot list to give you detailed answers. Please see below for what I
think I know (but I'll gladly accept any corrections).


On 02.10.2009 22:57, Jordan Justen wrote:
> Carl-Daniel,
>
> Interesting.  So, where can I download a QEMU bios rom to boot a UEFI
> OS with this solution?
>
> Can you explain what coreboot+tianocore means?  Which parts of
> tianocore do you use in this situation?
>   

This mail is CC: to the coreboot list and I'm sure someone who knows
more than I can respond.

The documentation about Tianocore/UEFI/EFI is not entirely clear about
the names of each part of the stack, but if I understand correctly,
there is a hardware init part (OVMF for Qemu) and parts which boot EFI
enabled operating systems, provide EFI services to the operating system,
or give users a shell to work from.

coreboot is pure hardware init (CPU, RAM, chipset, PCI), it has no
drivers whatsoever. It does provide ACPI tables for the hardware and a
memory map. Once coreboot finishes hardware initialization, it passes
control to a payload (which has drivers, boots the OS, provides
services). That payload is hardware-independent unless it explicitly
wants to contain non-generic drivers. It is possible to use the exact
same SeaBIOS binary as coreboot payload on Qemu, Pentium III systems
with i440BX chipset, AMD Phenom systems with 690G chipset, Via Nano
systems with VX800 chipset, and Intel Core 2 Duo systems with i945 chipset.
Unless I'm mistaken, OVMF and coreboot have pretty much the same purpose.


> If your solution can accomplish all of what you say, I'm not sure how
> OVMF would be able to compete against in terms of being included with
> QEMU.  Part of the reason for starting OVMF was to help enable UEFI
> support within VM's such as QEMU.  If OVMF was utilized by QEMU it
> definitely would have been a bit of a boost for our efforts, but if
> QEMU accomplishes UEFI support via another path, then overall we will
> still be happy.
>   

Please don't get me wrong. The number of developers in the open source
firmware space is small and I'm happy that you're such a developer. My
main worry is splitting one task among too many projects, with the
danger of frustation if only one project is accepted into Qemu. I don't
have an axe to grind against EFI (which is desired by many people) or
OVMF (which is purpose-built for UEFI in Qemu).
That's why I want to understand your goals and hope to find a way to
accomplish your goals, coreboot goals and at the same time have Qemu get
the best firmware possible.


> Thanks,
>
> -Jordan
>   

Regards,
Carl-Daniel

> On Fri, Oct 2, 2009 at 11:45, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006@gmx.net> wrote:
>   
>> On 02.10.2009 18:58, Jordan Justen wrote:
>>     
>>> On Fri, Oct 2, 2009 at 06:29, Anthony Liguori <anthony@codemonkey.ws> wrote:
>>>
>>>       
>>>> So I think the best way forward is to hold off on UEFI in mainline until we
>>>> can provide a single unified stack.
>>>>
>>>>         
>>> While it is true that a separate machine type could potentially be
>>> viewed as increasing the testing requirements, I am not so sure.  If
>>> QEMU has a UEFI+CSM solution, wouldn't we still have to test both UEFI
>>> based OS boot and the CSM based legacy OS boot?
>>>
>>>       
>> Given that you can easily pack coreboot+SeaBIOS+UEFI into one ROM and
>> have coreboot boot either SeaBIOS (BIOS interface) or UEFI (EFI
>> interface), wouldn't that solve all problems in one go? You get an
>>     

Re: [Qemu-devel] Release plan for 0.12.0

[Natalia Portillo]

Mac OS X / Intel also depends on EFI, even if netkas and others hacked  
it to run on BIOS it would be great to have an emulator capable of  
running it.

About license terms Apple states:
Mac OS X Server can be run emulated as long as they are run inside a  
Macintosh.
That is, we can have a Linux in an iMac running QEMU for emulating Mac  
OS X Server.
It is forbidden to run Mac OS X (client) in anything other than a real  
Apple hardware (nothing forbides having an emulator capable of doing  
so).

El 01/10/2009, a las 22:10, Jordan Justen escribió:

> On Thu, Oct 1, 2009 at 05:45, Anthony Liguori <aliguori@us.ibm.com>  
> wrote:
>> Natalia Portillo wrote:
>>>
>>> for target-i386 and target-x86_64:
>>>
>>> o EFI firmware emulation (as a machine or command line option)
>>> o OS/2 1.x support
>>
>> AFAIK, no one is actually working on these.  EFI is also not  
>> terribly useful
>> without a CSM and I suspect porting SeaBIOS to tiano core is going  
>> to be a
>> big effort.
>
> Several Linux distributions are getting UEFI support ironed out now,
> so UEFI can be used without a CSM.  QEMU support for UEFI could
> help the Linux distributions to enable UEFI support...
>
> Windows Vista and 7 support UEFI on x64-64, but I've not been able
> to boot either with the OVMF project yet.  (I suspect that the video  
> driver
> might not be initializing correctly, but the root cause of the  
> failure is not
> yet known.)
>
>>
>> --
>> Regards,
>>
>> Anthony Liguori
>>
>>
>>
>>
>

Re: [Qemu-devel] Release plan for 0.12.0

[Stuart Brady]

On Thu, Oct 01, 2009 at 02:55:05AM +0100, Natalia Portillo wrote:

> integrating target-alpha and target-zxspectrum in the branch tree

Heh. :)

z80-softmmu now has MSX1 emulation, with thanks to Juha Riihimäki,
and I've also added the beginnings of ZX Spectrum 128K and SAM Coupé
emulation.  It still needs quite a few cleanups, though.

When you speak of target-alpha, I presume you're referring to
Tristan Gingold's system emulation patches... it would certainly be
nice to see these applied.

Same also for Laurent Vivier's m68k patches -- I would certainly have a
go at implementing Atari ST emulation, and would also be interested in
helping with Amiga, 68K Mac and perhaps even NeXT, SUN3, etc.

> a new official os support list design (please, give me ideas, css,
> help, anything!) with a better captcha

For the OS support list, I'd perhaps suggest something similar to the
Wine AppDB -- one page per OS version per architecture, containing
details of each tester's QEMU configuration (KVM/TCG, host OS/arch,
emulated devices, etc.) and guest OS configuration (drivers/kernel used,
service packs applied, etc.), together with any extra notes.

If it's of any use: http://source.winehq.org/git/appdb.git/

Cheers,
-- 
Stuart Brady

Re: [Qemu-devel] Release plan for 0.12.0

[Natalia Portillo]

Hi Stuart!

Nice to read you!

El 01/10/2009, a las 21:50, Stuart Brady escribió:

> On Thu, Oct 01, 2009 at 02:55:05AM +0100, Natalia Portillo wrote:
>
>> integrating target-alpha and target-zxspectrum in the branch tree
>
> Heh. :)
>
> z80-softmmu now has MSX1 emulation, with thanks to Juha Riihimäki,
> and I've also added the beginnings of ZX Spectrum 128K and SAM Coupé
> emulation.  It still needs quite a few cleanups, though.
Great great!!!
If you need any software for testing them just email me.

Could you please email me the public domain ROMs?
I've lost them

> When you speak of target-alpha, I presume you're referring to
> Tristan Gingold's system emulation patches... it would certainly be
> nice to see these applied.
Yes I indeed didn't remember his name.

> Same also for Laurent Vivier's m68k patches -- I would certainly  
> have a
> go at implementing Atari ST emulation, and would also be interested in
> helping with Amiga, 68K Mac and perhaps even NeXT, SUN3, etc.
If operating systems or real systems are need for that I have almost  
all.
Atari ST512FM, ST1024, Amiga 500, a pletory of Macs.
And of course, Atari TOS, Amiga Kickstart, OS and Workbench, Mac OS, A/ 
UX, NeXTStep and OpenStep, and SunOS/sun3.

>> a new official os support list design (please, give me ideas, css,
>> help, anything!) with a better captcha
>
> For the OS support list, I'd perhaps suggest something similar to the
> Wine AppDB -- one page per OS version per architecture, containing
> details of each tester's QEMU configuration (KVM/TCG, host OS/arch,
> emulated devices, etc.) and guest OS configuration (drivers/kernel  
> used,
> service packs applied, etc.), together with any extra notes.
>
> If it's of any use: http://source.winehq.org/git/appdb.git/
A GREAT idea I'll check on it.

Regards,
Natalia Portillo

Re: [Qemu-devel] Release plan for 0.12.0

[Stuart Brady]

On Fri, Oct 02, 2009 at 05:51:37AM +0100, Natalia Portillo wrote:
> Hi Stuart!
> 
> Nice to read you!

And you, Natalia! :-)

> El 01/10/2009, a las 21:50, Stuart Brady escribió:
> 
> >z80-softmmu now has MSX1 emulation, with thanks to Juha Riihimäki,
> >and I've also added the beginnings of ZX Spectrum 128K and SAM Coupé
> >emulation.  It still needs quite a few cleanups, though.

> Great great!!!
> If you need any software for testing them just email me.

I've no real problems getting hold of SAM and Spectrum software, but I
expect there are still bugs in the Z80 emulation... certainly, support
for the Z80's undocumented flags would be useful!

> Could you please email me the public domain ROMs?
> I've lost them

The ZX Spectrum ROMs are available here:

   http://www.shadowmagic.org.uk/spectrum/roms.html

For 48K emulation, you'll likely want 48.rom, renamed to zx-rom.bin...
For 128K emulation, you'd need to join 128-0.rom and 128-1.rom together,
and named zx128-rom.bin.

The SAM Coupe ROM is available here:

   ftp://ftp.nvg.ntnu.no/pub/sam-coupe/emulation/ROMs/samroms.zip

I'd recommend using ROM30 (renaming it to sam-rom.bin).

(Note to all: these are not truly 'free software', but their owners have
given permission for them to be used for emulation.  The MSX ROMs are a
different matter, though.)

The Z80 target is available at:

   http://repo.or.cz/w/qemu/z80.git

BTW, one thing that looks interesting is TAKEDA Toshiya's PC-98
emulation.  If support for the NEC v20's 8080 mode (!) would be useful,
then perhaps parts of the Z80 target might serve as a starting point...

> >Same also for Laurent Vivier's m68k patches -- I would certainly have a
> >go at implementing Atari ST emulation, and would also be interested in
> >helping with Amiga, 68K Mac and perhaps even NeXT, SUN3, etc.

> If operating systems or real systems are need for that I have almost all.
> Atari ST512FM, ST1024, Amiga 500, a pletory of Macs.
> And of course, Atari TOS, Amiga Kickstart, OS and Workbench, Mac OS,
> A/UX, NeXTStep and OpenStep, and SunOS/sun3.

Those would certainly be useful for testing!  For the time being,
Laurent's plan to boot linux-m68k sounds like a good approach.

> >For the OS support list, I'd perhaps suggest something similar to the
> >Wine AppDB [...]
> >If it's of any use: http://source.winehq.org/git/appdb.git/

> A GREAT idea I'll check on it.

Thanks!  I'm eager to hear what conclusion you come to. :-)

Cheers,
-- 
Stuart Brady

Re: [Qemu-devel] Release plan for 0.12.0

[Natalia Portillo]

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

>
>>> For the OS support list, I'd perhaps suggest something similar to  
>>> the
>>> Wine AppDB [...]
>>> If it's of any use: http://source.winehq.org/git/appdb.git/
>
>> A GREAT idea I'll check on it.
>
> Thanks!  I'm eager to hear what conclusion you come to. :-)

I've got the GIT source but the question is how to modify it to handle  
the device list.
As wine just needs a version, but QEMU needs version + chosen system  
emulation + chosen machine + chosen graphics + chosen audio + chosen  
network + chosen mass storage.

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

Re: [Qemu-devel] Release plan for 0.12.0

[Stefan Weil]

Anthony Liguori schrieb:
> Hi,
>
> Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0.
>
> I'd like to do a few things different this time around.  I don't think
> the -rc process went very well as I don't think we got more testing
> out of it.  I'd like to shorten the timeline for 0.12.0 a good bit. 
> The 0.10 stable tree got pretty difficult to maintain toward the end
> of the cycle.  We also had a pretty huge amount of change between 0.10
> and 0.11 so I think a shorter cycle is warranted.
>
> I think aiming for early to mid-December would give us roughly a 3
> month cycle and would align well with some of the Linux distribution
> cycles.  I'd like to limit things to a single -rc that lasted only for
> about a week.  This is enough time to fix most of the obvious issues I
> think.
>
> I'd also like to try to enumerate some features for this release. 
> Here's a short list of things I expect to see for this release
> (target-i386 centric).  Please add or comment on items that you'd
> either like to see in the release or are planning on working on.
>
> o VMState conversion -- I expect most of the pc target to be completed
> o qdev conversion -- I hope that we'll get most of the pc target
> completely converted to qdev
> o storage live migration
> o switch to SeaBIOS (need to finish porting features from Bochs)
> o switch to gPXE (need to resolve slirp tftp server issue)
> o KSM integration
> o in-kernel APIC support for KVM
> o guest SMP support for KVM
> o updates to the default pc machine type
>
> Please add to this list and I'll collect it all and post it somewhere.
>
> Thanks!
>

* VDI block driver
* Update eepro100 driver
* Fix VNC support for Windows

Stefan

Re: [Qemu-devel] Release plan for 0.12.0

[Anthony Liguori]

Stefan Weil wrote:
> * VDI block driver
>   

If a new rev is submitted in time, sure.

> * Update eepro100 driver
>   

I have some of the patches that Blue Swirl didn't apply in my staging 
tree so they should get included assuming all goes well.

> * Fix VNC support for Windows
>   

I wasn't aware this was broken, can you file a bug report?

Regards,

Anthony Liguori

Re: [Qemu-devel] Release plan for 0.12.0

[Stefan Weil]

Anthony Liguori schrieb:
> Stefan Weil wrote:
>> * VDI block driver
>>   
>
> If a new rev is submitted in time, sure.

The one from qemu master? There is no plan for a new revision.

>
>> * Update eepro100 driver
>>   
>
> I have some of the patches that Blue Swirl didn't apply in my staging
> tree so they should get included assuming all goes well.

Some more patches are in my local queue.
I'm waiting for the last ones to get included before I'll send new ones.

>
>> * Fix VNC support for Windows
>>   
>
> I wasn't aware this was broken, can you file a bug report?

A patch was just sent to qemu-devel.

>
> Regards,
>
> Anthony Liguori
>


Regards

Stefan Weil

Re: [Qemu-devel] Release plan for 0.12.0

[TAKEDA, toshiya]

Anthony Liguori さんは書きました:
>Hi,
>
>Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0.
>
>I'd like to do a few things different this time around.  I don't think 
>the -rc process went very well as I don't think we got more testing out 
>of it.  I'd like to shorten the timeline for 0.12.0 a good bit.  The 
>0.10 stable tree got pretty difficult to maintain toward the end of the 
>cycle.  We also had a pretty huge amount of change between 0.10 and 0.11 
>so I think a shorter cycle is warranted.
>
>I think aiming for early to mid-December would give us roughly a 3 month 
>cycle and would align well with some of the Linux distribution cycles.  
>I'd like to limit things to a single -rc that lasted only for about a 
>week.  This is enough time to fix most of the obvious issues I think.
>
>I'd also like to try to enumerate some features for this release.  
>Here's a short list of things I expect to see for this release 
>(target-i386 centric).  Please add or comment on items that you'd either 
>like to see in the release or are planning on working on.
>
> o VMState conversion -- I expect most of the pc target to be completed
> o qdev conversion -- I hope that we'll get most of the pc target 
>completely converted to qdev
> o storage live migration
> o switch to SeaBIOS (need to finish porting features from Bochs)
> o switch to gPXE (need to resolve slirp tftp server issue)
> o KSM integration
> o in-kernel APIC support for KVM
> o guest SMP support for KVM
> o updates to the default pc machine type
>
>Please add to this list and I'll collect it all and post it somewhere.

o NEC PC-9821 family support on target-i386

In the last patch MS-DOS can boot on QEMU.
I think I can add support nic (LGY-98) and IDE in 0.12.0
and I hope I can boot FreeBSD/pc98 on it.

PS.
I will repost v3 patch in the next week, please wait reviewing v2 patch I post Oct.1.

Thanks,
TAKEDA, toshiya

>Thanks!
>
>-- 
>Regards,
>
>Anthony Liguori
>
>
>
>

Re: [Qemu-devel] Release plan for 0.12.0

[Jens Osterkamp]

On Wednesday 30 September 2009, Anthony Liguori wrote:

>  o VMState conversion -- I expect most of the pc target to be completed
>  o qdev conversion -- I hope that we'll get most of the pc target
> completely converted to qdev
>  o storage live migration
>  o switch to SeaBIOS (need to finish porting features from Bochs)
>  o switch to gPXE (need to resolve slirp tftp server issue)
>  o KSM integration
>  o in-kernel APIC support for KVM
>  o guest SMP support for KVM
>  o updates to the default pc machine type
>
> Please add to this list and I'll collect it all and post it somewhere.

What about Or Gerlitz' raw backend driver ? I did not see it go in yet, or did 
I miss something ?

Jens

Re: [Qemu-devel] Release plan for 0.12.0

[Anthony Liguori]

Jens Osterkamp wrote:
> On Wednesday 30 September 2009, Anthony Liguori wrote:
>
>   
>>  o VMState conversion -- I expect most of the pc target to be completed
>>  o qdev conversion -- I hope that we'll get most of the pc target
>> completely converted to qdev
>>  o storage live migration
>>  o switch to SeaBIOS (need to finish porting features from Bochs)
>>  o switch to gPXE (need to resolve slirp tftp server issue)
>>  o KSM integration
>>  o in-kernel APIC support for KVM
>>  o guest SMP support for KVM
>>  o updates to the default pc machine type
>>
>> Please add to this list and I'll collect it all and post it somewhere.
>>     
>
> What about Or Gerlitz' raw backend driver ? I did not see it go in yet, or did 
> I miss something ?
>   

The patch seems to have not been updated after the initial posting and 
the first feedback cycle.

I'm generally inclined to oppose the functionality as I don't think it 
offers any advantages over the existing backends.

Regards,

Anthony Liguori

Re: [Qemu-devel] Release plan for 0.12.0

[Arnd Bergmann]

On Thursday 08 October 2009, Anthony Liguori wrote:
> Jens Osterkamp wrote:
> > On Wednesday 30 September 2009, Anthony Liguori wrote:
> >
> >> Please add to this list and I'll collect it all and post it somewhere.
> >>     
> >
> > What about Or Gerlitz' raw backend driver ? I did not see it go in yet, or did 
> > I miss something ?
> >   
> 
> The patch seems to have not been updated after the initial posting and 
> the first feedback cycle.
> 
> I'm generally inclined to oppose the functionality as I don't think it 
> offers any advantages over the existing backends.

There are two reasons why I think this backend is important:

- As an easy way to provide isolation between guests (private ethernet
  port aggregator, PEPA) and external enforcement of network priviledges
  (virtual ethernet port aggregator, VEPA) using the macvlan subsystem.

- As a counterpart to the vhost_net driver, providing an identical
  user interface with or without vhost_net acceleration in the kernel.

	Arnd <><

Re: [Qemu-devel] Release plan for 0.12.0

[Anthony Liguori]

Arnd Bergmann wrote:
> There are two reasons why I think this backend is important:
>
> - As an easy way to provide isolation between guests (private ethernet
>   port aggregator, PEPA) and external enforcement of network priviledges
>   (virtual ethernet port aggregator, VEPA) using the macvlan subsystem.
>   

Can't this all be done with tap and a bridge?

Regards,

Anthony Liguori

Re: [Qemu-devel] Release plan for 0.12.0

[Michael S. Tsirkin]

On Wed, Oct 14, 2009 at 08:53:55AM -0500, Anthony Liguori wrote:
> Arnd Bergmann wrote:
>> There are two reasons why I think this backend is important:
>>
>> - As an easy way to provide isolation between guests (private ethernet
>>   port aggregator, PEPA) and external enforcement of network priviledges
>>   (virtual ethernet port aggregator, VEPA) using the macvlan subsystem.
>>   
>
> Can't this all be done with tap and a bridge?

Not with existing kernels, I think.

> Regards,
>
> Anthony Liguori

Re: [Qemu-devel] Release plan for 0.12.0

[Michael S. Tsirkin]

On Wed, Oct 14, 2009 at 03:09:28PM +0200, Arnd Bergmann wrote:
> On Thursday 08 October 2009, Anthony Liguori wrote:
> > Jens Osterkamp wrote:
> > > On Wednesday 30 September 2009, Anthony Liguori wrote:
> > >
> > >> Please add to this list and I'll collect it all and post it somewhere.
> > >>     
> > >
> > > What about Or Gerlitz' raw backend driver ? I did not see it go in yet, or did 
> > > I miss something ?
> > >   
> > 
> > The patch seems to have not been updated after the initial posting and 
> > the first feedback cycle.
> > 
> > I'm generally inclined to oppose the functionality as I don't think it 
> > offers any advantages over the existing backends.
> 
> There are two reasons why I think this backend is important:
> 
> - As an easy way to provide isolation between guests (private ethernet
>   port aggregator, PEPA) and external enforcement of network priviledges
>   (virtual ethernet port aggregator, VEPA) using the macvlan subsystem.
> 
> - As a counterpart to the vhost_net driver, providing an identical
>   user interface with or without vhost_net acceleration in the kernel.
> 
> 	Arnd <><

I think raw sockets also support RX mac/vlan filtering in kernel, which
might be faster than doing it in virtio in userspace as it's done now.

-- 
MST