[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device
From: |
Michael S. Tsirkin |
Subject: |
[Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device |
Date: |
Mon, 8 Nov 2010 18:48:20 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Mon, Nov 08, 2010 at 09:36:59AM -0700, Alex Williamson wrote:
> On Mon, 2010-11-08 at 18:26 +0200, Michael S. Tsirkin wrote:
> > On Mon, Nov 08, 2010 at 07:52:12AM -0700, Alex Williamson wrote:
> > > On Mon, 2010-11-08 at 13:22 +0200, Michael S. Tsirkin wrote:
> > > > On Mon, Oct 04, 2010 at 03:53:11PM -0600, Alex Williamson wrote:
> > > > > pcibus_dev_print() was erroneously retrieving the device bus
> > > > > number from the secondary bus number offset of the device
> > > > > instead of the bridge above the device. This ends of landing
> > > > > in the 2nd byte of the 3rd BAR for devices, which thankfully
> > > > > is usually zero. pcibus_get_dev_path() copied this code,
> > > > > inheriting the same bug. pcibus_get_dev_path() is used for
> > > > > ramblock naming, so changing it can effect migration. However,
> > > > > I've only seen this byte be non-zero for an assigned device,
> > > > > which can't migrate anyway, so hopefully we won't run into
> > > > > any issues.
> > > > >
> > > > > Signed-off-by: Alex Williamson <address@hidden>
> > > >
> > > > Good catch. Applied.
> > > > I don't really see why do we put the dev path
> > > > in the bus object: why not let device supply its name?
> > >
> > > Because the device name is not unique. This came about from the
> > > discussion about how to create a canonical device path that Gleb and
> > > Markus are again trying to hash out. If we go up to the bus and get the
> > > bus address, we have a VM unique name. Unfortunately, it's difficult to
> > > define what the bus should print in all cases (ISA), but since they
> > > don't do hotplug and typically don't allocate ramblocks, we can mostly
> > > ignore it for this use case.
> > >
> > > > And I think this will affect nested bridges. However they are currently
> > > > broken anyway: we really must convert to topological names as bus number
> > > > is guest-assigned - they don't have to be unique, even.
> > >
> > > Yes, nested bridges are a problem. How can the seg/bus/devfn not be
> > > unique?
> >
> > Bus numbers for nested bridges are guest assigned. We start with 0 after
> > reset.
>
> Right, invalid bus numbers are not unique.
Well, you can call them invalid, but this is the only
number there is until guest assigns something :)
> > > > What does fixing this involve? Just changing pcibus_get_dev_path?
> > >
> > > How do you plan to fix it? Don't forget that migration depends on these
> > > names, so some kind of compatibility layer would be required. Thanks,
> > >
> > > Alex
> >
> > Replace bus number with slot numbers of parent bridges up to the root.
> > This works for root bridge in a compatible way because bus number there
> > is hard-coded to 0.
> > IMO nested bridges are broken anyway, no way to be compatible there.
> >
> >
> > Gleb, Markus, I think the following should be sufficient for PCI. What
> > do you think? Also - do we need to update QMP/monitor to teach them to
> > work with these paths?
> >
> > This is on top of Alex's patch, completely untested.
>
> This function was originally intended to be recursive, so that each bus
> could call the parent until we hit a canonical name. It just so happens
> that the root bus provides that for non-nested devices. So I think
> instead we should have a different function for bridges that appends to
> what the root get_dev_path returns.
>
> Alex
This won't be compatible: the format that we have is
DDDD:BB:SS.F
which means that string concatenation can not get you from bus path
to device path (remember that bridge is a PCI device too).
And frankly if we can make it non-recursive I'd rather have it
that way. We are not solving the tower of hanoi here.
--
MST
- [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device, Michael S. Tsirkin, 2010/11/08
- [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device, Alex Williamson, 2010/11/08
- [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device, Michael S. Tsirkin, 2010/11/08
- [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device, Gleb Natapov, 2010/11/08
- [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device, Michael S. Tsirkin, 2010/11/08
- [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device, Gleb Natapov, 2010/11/08
- Re: [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device, Isaku Yamahata, 2010/11/08
- Re: [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device, Michael S. Tsirkin, 2010/11/09
- Re: [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device, Markus Armbruster, 2010/11/19
- Re: [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device, Gleb Natapov, 2010/11/19
- Re: [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device, Michael S. Tsirkin, 2010/11/20
- Re: [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device, Gleb Natapov, 2010/11/21
- Re: [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device, Michael S. Tsirkin, 2010/11/21