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

[Gleb Natapov <gleb@redhat.com>]

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? And this kind of addressing has no meaning as interface between
qemu and firmware since qemu does not map PCI bars.

> >>
> >> 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.

--
			Gleb.