Re: [Qemu-devel] [PATCH 0/5] boot order specification

[Gleb Natapov <gleb@redhat.com>]

On Tue, Oct 26, 2010 at 08:49:09PM +0000, Blue Swirl wrote:
> On Tue, Oct 26, 2010 at 8:34 PM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Tue, Oct 26, 2010 at 07:57:00PM +0000, Blue Swirl wrote:
> >> On Tue, Oct 26, 2010 at 7:35 PM, Gleb Natapov <gleb@redhat.com> wrote:
> >> > On Tue, Oct 26, 2010 at 05:00:25PM +0000, Blue Swirl wrote:
> >> >> On Tue, Oct 26, 2010 at 3:43 PM, Gleb Natapov <gleb@redhat.com> wrote:
> >> >> > On Tue, Oct 26, 2010 at 03:35:38PM +0000, Blue Swirl wrote:
> >> >> >> On Tue, Oct 26, 2010 at 10:48 AM, Gleb Natapov <gleb@redhat.com> wrote:
> >> >> >> > This is current sate of the patch series for people to comment on.
> >> >> >> > I dropped ioport double reservation checking from isa-bus and added
> >> >> >> > bus_id field for IDE bus since as Markus pointed out unit has different
> >> >> >> > meaning there.
> >> >> >> >
> >> >> >> > This patch series produce names like:
> >> >> >> >
> >> >> >> > ISA@03f1-03f5,03f7/fd@a
> >> >> >> > ISA@03f1-03f5,03f7/fd@b
> >> >> >> > PCI@0000:00:01.1/IDE@1:0
> >> >> >> > PCI@0000:00:01.1/IDE@1:1
> >> >> >> > PCI@0000:00:03.0/virtio-blk@0
> >> >> >> > PCI@0000:00:04.0/virtio-net@0
> >> >> >> >
> >> >> >> > They will be passed to BIOS to determine boot order.
> >> >> >>
> >> >> >> We also use OpenBIOS for PPC and Sparcs. A compatible boot device for
> >> >> >> those would be OpenFirmware tree name. I think your names should then
> >> >> >> become:
> >> >> >> /pci/isa/fdc@3f1/fd@0
> >> >> >> /pci/isa/fdc@3f1/fd@1
> >> >> > Why is it PCI?
> >> >>
> >> >> I just assumed a PCI to ISA bridge.
> >> >>
> >> >> >> /pci/ide@0/1,0
> >> >> >> /pci/ide@0/1,1
> >> >> > Where pci address here?
> >> >> >
> >> >> >> /pci/virtio-net@1
> >> >> >> /pci/virtio-net@2
> >> >> > And here?
> >> >>
> >> >> That was the part I invented.
> >> >>
> >> >> > And we will need to describe ROMs too. I planned to have something like:
> >> >> > ROM@romfilename for roms loaded with -option-rom command line option.
> >> >>
> >> >> I don't think OF has standard for those.
> >> >>
> >> >> >>
> >> >> >> The PCI addressing scheme in OF was a bit twisty, I just invented
> >> >> >> integers in place of those.
> >> >> >>
> >> >> >> Anyway, I don't think we should invent yet another device path naming system.
> >> >> > IS this format documented somewhere? I am not attached to specific
> >> >> > format at all.
> >> >>
> >> >> A lot of docs are here:
> >> >> http://playground.sun.com/pub/p1275/home.html
> >> > Search for flat, device or tree returns nothing on this page.
> >> >
> >> > But looking elsewhere I found some description of DTS. It is very
> >> > elaborate and looks like this:
> >> >
> >> > /pci@xxx {
> >> > plenty of info here
> >> > }
> >> >
> >> > The only example of /pci@xxx that I found is here
> >> > http://wiki.freebsd.org/FlattenedDeviceTree but not any spec about its
> >> > format.
> >>
> >> That's FDT, it's a bit different.
> >>
> >> There are some trees here:
> >> http://penguinppc.org/historical/dev-trees-html/trees-index.html
> >>
> >> For example dual G4 500 has several /pci@xyz nodes.
> >>
> > Yes, it has: /pci@f0000000 for instance. Now lets try to decipher
> > address f0000000 according to pci2_1.pdf below. It says:
> > The text representation of a PCI address is one of the following forms:
> >         DD
> >         DD,F
> >         [n]i[t]DD,F,RR,NNNNNNNN
> >         [n]m[t][p]DD,F,RR,NNNNNNNN
> >         [n]x[p]DD,F,RR,NNNNNNNNNNNNNNNN
> >    where:
> >         DD                         is an ASCII hexadecimal number in the range 0...1F
> >         F                          is an ASCII numeral in the range 0...7
> >         RR                         is an ASCII hexadecimal number in the range 0...FF
> >         NNNNNNNN                   is an ASCII hexadecimal number in the range 0...FFFFFFFF
> >         NNNNNNNNNNNNNNNN           is an ASCII hexadecimal number in the range 0...FFFFFFFFFFFFFFFF
> >         [n]                        is the letter 'n', whose presence is optional
> >         [t]                        is the letter 't', whose presence is optional
> >         [p]                        is the letter 'p', whose presence is optional
> >         i                          is the letter 'i'
> >         m                          is the letter 'm'
> >         x                          is the letter 'x'
> >         ,                          is the character ',' (comma)
> >
> > Nothing resembles f0000000. There is also 2.2.1.1 Numerical Representation
> > but no luck there too. This number is illegal according to it. May be
> > this is memory address PCI bar is mapped into? But according to which
> > spec?
> 
> For PPC yes, but that depends on the system. This is described in the
> common spec.
> 
Can you point me to PDF and page to read? I am lost in all this specs
especially as I can't find the link between specs and reality.

> >And this kind of addressing has no meaning as interface between
> > qemu and firmware since qemu does not map PCI bars.
> 
> No, but we still need to identify the devices. This could still be a
PCI address does this perfectly (for PCI devices).

> useful way to address them so that also the BIOS can identify them.
Qemu does not map PCI bars so it can't produce this number.

> For example, this 0xf0000000 can be used by BIOS to probe for a PCI
> controller.
How? This is just random address in PCI hole as far as qemu is conserned.

> 
> >> >>
> >> >> Here's the PCI bindings doc:
> >> >> http://playground.sun.com/pub/p1275/bindings/pci/pci2_1.pdf
> >> > The funny thing is that pci address used in /pci@ example from wiki
> >> > above is incorrect according to this spec.
> >> >
> >> > And I thought ACPI spec is confusing :) Can you clarify things a little
> >> > bit please?
> >>
> >> Perhaps you should start by reading the main OF document, it can be found in:
> >> http://www.openfirmware.info/IEEE_1275-1994
> > Perhaps. But searching for PCI there returns nothing. What section
> > exactly should enlighten me? One interesting thing I found at the
> > beginning:
> >  1.1 Purpose and scope
> >  This document describes a software architecture for the firmware that
> >  controls a computer before the operating system has begun execution
> >
> > Interfaces between firmware and OS is not always suitable for
> > qemu->guest communication.
> 
> That can be true.
> 
> Next idea: If QEMU passed a FDT to BIOS, then the original boot device
> problem could be solved by decorating various tree nodes with
> "QEMU,boot" tags.

We will never agree on FDT implementation in qemu. Besides for PC you
don't really need it.  All devices either can be enumerated or at well
known to BIOS locations. And looking at the specs I'd rather go re-read
ACPI spec twice :) They have even examples there! If we had FDT in qemu
already I would agree with you that passing part of it to BIOS is a
reasonable solution for boot order problem, but implementing FDT to
solve it is overkill.

--
			Gleb.