From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCHv4 15/15] Pass boot device list to firmware. Date: Thu, 18 Nov 2010 13:45:04 +0200 Message-ID: <20101118114504.GI7948@redhat.com> References: <1289749181-12070-16-git-send-email-gleb@redhat.com> <20101115084242.GG7948@redhat.com> <20101116141112.GS7948@redhat.com> <20101116190246.GA27851@redhat.com> <20101118101827.GC7948@redhat.com> <20101118113831.GD31261@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Blue Swirl , qemu-devel@nongnu.org, kvm@vger.kernel.org, armbru@redhat.com, alex.williamson@redhat.com, kevin@koconnor.net To: "Michael S. Tsirkin" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:65198 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750854Ab0KRLpL convert rfc822-to-8bit (ORCPT ); Thu, 18 Nov 2010 06:45:11 -0500 Content-Disposition: inline In-Reply-To: <20101118113831.GD31261@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Nov 18, 2010 at 01:38:31PM +0200, Michael S. Tsirkin wrote: > 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 : > > > > On Tue, Nov 16, 2010 at 06:30:19PM +0000, Blue Swirl wrote: > > > >> >> Perhaps the FW path should use device class names if no nam= e is specified. > > > >> > What do you mean by "device class name". We can do something= like this: > > > >> > if (dev->child_bus.lh_first) > > > >> > =9A =9A =9A =9Areturn 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. > > >=20 > > > Thanks. The bootindex on Sparc32 looks like this: > > > bootindex /esp@0000000078800000/disk@1,0 > > > /ethernet@ffffffffffffffff/ethernet-phy@0 > > >=20 > > 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. > >=20 > > > I don't think I got Lance setup right. > > >=20 > > > OF paths for the devices would be: > > > /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/= sd@1,0 > > > /iommu@0,10000000/sbus@0,10001000/ledma@5,8400010/le@5,8c00000 > > If qdev hierarchy does not correspond to real HW there is no much w= e can > > do expect for fixing qdev. >=20 > That's bad. This raises a concern: if these paths expose qdev > internals, any attempt to fix this will break migration. >=20 The path expose internal HW hierarchy. It is designed to do so. Qdev designed to do the same: describe HW hierarchy. If qdev fails to do so = it is broken. I do not see connection to migration at all since the path i= s not used in migration code. > > >=20 > > > The logic for ESP is that ESP (registers at 0x78800000, slot offs= et > > > 0x880000) is handled by the DMA controller (registers at 0x784000= 00, > > > slot offset 0x840000), they are in a SBus slot #5, and SBus (regi= sters > > > at 0x10001000) is in turn handled by IOMMU (registers at 0x100000= 00). > > > Lance should be handled the same way. > > >=20 > > > This hierarchy is partly known by QEMU because DMA accesses use t= his > > > flow, but not otherwise. There is no concept of SBus slots, DMA t= alks > > > 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 possi= ble > > > to add the hierarchy information at each stage. > > >=20 > > > 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 cou= rse OF > > spec is not strict enough to have two different implementations pro= duce > > exactly same device path that can be compared by strcpy. Can we ap= ply > > the series now? At least for x86 it provides useful paths and work = can > > be continue for other arches by interested parties. > >=20 > > -- > > Gleb. >=20 > Something I only now realized is that we commit > to never changing the paths for any architecture > that supports migration. >=20 No connection to migration whatsoever. -- Gleb.