qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCHv8 00/16] boot order specification


From: Gleb Natapov
Subject: Re: [Qemu-devel] Re: [PATCHv8 00/16] boot order specification
Date: Sat, 11 Dec 2010 21:11:26 +0200

On Sat, Dec 11, 2010 at 07:06:04PM +0000, Blue Swirl wrote:
> 2010/12/11 Gleb Natapov <address@hidden>:
> > On Sat, Dec 11, 2010 at 08:02:23PM +0200, Gleb Natapov wrote:
> >> On Sat, Dec 11, 2010 at 05:19:01PM +0000, Blue Swirl wrote:
> >> > >>                                                 What should we do with
> >> > >> address@hidden vs address@hidden
> >> > > There is no available IDE OF binding spec, so I when with the way
> >> > > OpenBIOS reports ata on qemu-x86. I have no idea what 600 in 
> >> > > address@hidden
> >> > > may mean, but looking at g3_beige_300.html there is no such node there
> >> > > and looking at any other device tree in 
> >> > > http://penguinppc.org/historical/dev-trees-html/
> >> > > I haven't found one that use this kind of addressing for pci-ata.
> >> > > http://penguinppc.org/historical/dev-trees-html/g3bw_400.html for
> >> > > instance has address@hidden/address@hidden/address@hidden/ata-4. 
> >> > > address@hidden kind of
> >> > > addressing is used by devices on mac-io bus which I do not think we
> >> > > emulate in qemu. So it looks like OpneBIOS is wrong here.
> >> >
> >> > We have PMAC IDE, but this device is CMD646, so mac-io bus addressing
> >> > rules should not be used.
> >> >
> >> So you agree that OpenBIOS is wrong here?
> >>
> >> > In this tree there are two disks connected to CMD646, named
> >> > /address@hidden/address@hidden/address@hidden/ata-4/disk and
> >> > /address@hidden/address@hidden/address@hidden/ata-4/address@hidden:
> >> > http://penguinppc.org/historical/dev-trees-html/g4_pci_350.html
> >> You are saying that qemu creates paths like:
> >> /address@hidden/address@hidden/address@hidden/address@hidden
> >> /address@hidden/address@hidden/address@hidden/address@hidden
> >>
> >> I do not understand why qemu creates node address@hidden It should be 
> >> address@hidden
> >> according to the code. I'll look at why unit-address is incorrect for
> >> the node. But assuming that this problem is fixed then paths created by
> >> qemu is very similar to the paths in g4_pci_350.html. It looks like in
> >> g4_pci_350.html they omit unit address if it is zero.
> >>
> > Ah the problem is that we have not qdevified mac io bus. Since first to
> > ide disks are automatically attached to mac-io bus device paths for them
> > are incorrect. Next two ide devices will be attached to CMD646 and qemu
> > will generate correct device paths for them:
> >
> > qemu-system-ppc -drive if=none,id=hda,file=/dev/null -device 
> > ide-drive,drive=hda,bootindex=1
> > -drive if=none,id=cd,file=/dev/null -device ide-drive,drive=cd,bootindex=0 
> > -nographic -drive
> > if=none,id=hdb,file=/dev/null -device 
> > ide-drive,drive=hdb,bus=ide.0,bootindex=2 -drive
> > if=none,id=hdc,file=/dev/null -device 
> > ide-drive,drive=hdc,bus=ide.0,bootindex=3
> > adding '/address@hidden/address@hidden/address@hidden/address@hidden' at 
> > index 0
> > adding '/address@hidden/address@hidden/address@hidden/address@hidden' at 
> > index 1
> > adding '/address@hidden/address@hidden/address@hidden/address@hidden' at 
> > index 2
> > adding '/address@hidden/address@hidden/address@hidden/address@hidden' at 
> > index 3
> 
> But why is the path almost the same as CMD646, shouldn't 'address@hidden' be
> different since the PCI device is not the same?
>
It should, but since the mac io is not qdevified there is no qdev pci
device for it.
 
> > So the fix is to qdevify mac io bus.
> 
> OK.

--
                        Gleb.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]