[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware.
From: |
Michael S. Tsirkin |
Subject: |
[Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware. |
Date: |
Thu, 18 Nov 2010 13:38:31 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Thu, Nov 18, 2010 at 12:18:27PM +0200, Gleb Natapov wrote:
> On Wed, Nov 17, 2010 at 09:54:27PM +0000, Blue Swirl wrote:
> > 2010/11/16 Gleb Natapov <address@hidden>:
> > > On Tue, Nov 16, 2010 at 06:30:19PM +0000, Blue Swirl wrote:
> > >> >> Perhaps the FW path should use device class names if no name is
> > >> >> specified.
> > >> > What do you mean by "device class name". We can do something like this:
> > >> > if (dev->child_bus.lh_first)
> > >> > return dev->child_bus.lh_first->info->name;
> > >> >
> > >> > i.e if there is child bus use its bus name as fw name. This will make
> > >> > all pci devices to have "pci" as fw name automatically. The problem is
> > >> > that theoretically same device can provide different buses.
> > >>
> > >> I meant PCI class name, like "display" for display controllers,
> > >> "network" for NICs etc.
> > >>
> > > That is what my pci bus related patch is doing already.
> > >
> > >> >> I'll try Sparc32 to see how this fits there.
> > >>
> > >> Except bootindex is not implemented for SCSI.
> > > Will look into adding it.
> >
> > Thanks. The bootindex on Sparc32 looks like this:
> > bootindex /address@hidden/address@hidden,0
> > /address@hidden/address@hidden
> >
> For arches other then x86 there is a lot of work left to be done :)
> For starter exotic sparc buses should get their own get_fw_dev_path()
> implementation.
>
> > I don't think I got Lance setup right.
> >
> > OF paths for the devices would be:
> > /address@hidden,10000000/address@hidden,10001000/address@hidden,8400000/address@hidden,8800000/address@hidden,0
> > /address@hidden,10000000/address@hidden,10001000/address@hidden,8400010/address@hidden,8c00000
> If qdev hierarchy does not correspond to real HW there is no much we can
> do expect for fixing qdev.
That's bad. This raises a concern: if these paths expose qdev
internals, any attempt to fix this will break migration.
> >
> > The logic for ESP is that ESP (registers at 0x78800000, slot offset
> > 0x880000) is handled by the DMA controller (registers at 0x78400000,
> > slot offset 0x840000), they are in a SBus slot #5, and SBus (registers
> > at 0x10001000) is in turn handled by IOMMU (registers at 0x10000000).
> > Lance should be handled the same way.
> >
> > This hierarchy is partly known by QEMU because DMA accesses use this
> > flow, but not otherwise. There is no concept of SBus slots, DMA talks
> > to IOMMU directly. Though in this case both ESP, Lance and their DMA
> > controllers are on board devices in a MACIO chip. It may be possible
> > to add the hierarchy information at each stage.
> >
> > It should also be possible for BIOS to determine the device just from
> > the physical address if we ignored OF compatibility.
> It would be nice to be OF compatible at least at some level. Of course OF
> spec is not strict enough to have two different implementations produce
> exactly same device path that can be compared by strcpy. Can we apply
> the series now? At least for x86 it provides useful paths and work can
> be continue for other arches by interested parties.
>
> --
> Gleb.
Something I only now realized is that we commit
to never changing the paths for any architecture
that supports migration.
--
MST
- [Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware., (continued)
[Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware., Blue Swirl, 2010/11/14
- [Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware., Gleb Natapov, 2010/11/15
- [Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware., Blue Swirl, 2010/11/15
- [Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware., Gleb Natapov, 2010/11/16
- [Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware., Blue Swirl, 2010/11/16
- [Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware., Gleb Natapov, 2010/11/16
- [Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware., Blue Swirl, 2010/11/17
- [Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware., Gleb Natapov, 2010/11/18
- [Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware.,
Michael S. Tsirkin <=
- [Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware., Gleb Natapov, 2010/11/18
- [Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware., Michael S. Tsirkin, 2010/11/18
- [Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware., Gleb Natapov, 2010/11/18
- [Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware., Michael S. Tsirkin, 2010/11/18
- [Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware., Gleb Natapov, 2010/11/18
- [Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware., Michael S. Tsirkin, 2010/11/18
- [Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware., Gleb Natapov, 2010/11/18
[Qemu-devel] Re: [PATCHv4 15/15] Pass boot device list to firmware., Kevin O'Connor, 2010/11/14