linux-kernel - Re: [PATCH] PCI/shpchp: fix a bus speed issue on hotplug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1399212446.4302.13.camel@localhost.localdomain>
Date:	Sun, 04 May 2014 17:07:26 +0300
From:	Marcel Apfelbaum <marcel.a@...hat.com>
To:	Ronen Hod <rhod@...hat.com>
Cc:	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	bhelgaas@...gle.com, mst@...hat.com
Subject: Re: [PATCH] PCI/shpchp: fix a bus speed issue on hotplug

On Sun, 2014-05-04 at 16:48 +0300, Ronen Hod wrote:
> On 05/01/2014 05:35 PM, Marcel Apfelbaum wrote:
> > When a board is added, the shpchp driver checks if there
> > is a mismatch between the bridge's adapter and the bus speed.
> > If there is, it sets the subordinate speed (if there is no device on it).
> 
> Since the speed is irrelevant when running in a VM, I suggest that
> you either ignore it altogether, or "normalize" the speed of all the
> devices/bridges/buses in QEMU in order to avoid any conflicts
> in the first place.
Before this patch, this would not help since the primary bus speed
is not even set by the kernel.

After this patch, normalizing the QEMU device/bus/... speed may help
avoiding future conflicts, but we should discuss it in qemu mailing list :).

Ignoring emulated/para-virt device's speed when running in a VM it is\
a good question, but I don't know if such a distinction would be feasible.

Any thoughts would be appreciated,
Thanks,
Marcel

> 
> Thanks, Ronen.
> 
> >
> > However, it takes the reference of the board speed from the primary bus
> > and not from the subordinate. If the primary bus is PCI and not PCIX/PCIe,
> > its speed is not updated and remains 0xff. As a result hotplug fails
> > with error: "Speed of bus ff and adapter 0 mismatch".
> >
> > Fixed that by checking the speed against the subordinate bus.
> >
> > Signed-off-by: Marcel Apfelbaum <marcel.a@...hat.com>
> > Acked-by: Michael S. Tsirkin <mst@...hat.com>
> > ---
> >   drivers/pci/hotplug/shpchp_ctrl.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/hotplug/shpchp_ctrl.c b/drivers/pci/hotplug/shpchp_ctrl.c
> > index 5849927..6efc2ec 100644
> > --- a/drivers/pci/hotplug/shpchp_ctrl.c
> > +++ b/drivers/pci/hotplug/shpchp_ctrl.c
> > @@ -282,8 +282,8 @@ static int board_added(struct slot *p_slot)
> >   		return WRONG_BUS_FREQUENCY;
> >   	}
> >   
> > -	bsp = ctrl->pci_dev->bus->cur_bus_speed;
> > -	msp = ctrl->pci_dev->bus->max_bus_speed;
> > +	bsp = ctrl->pci_dev->subordinate->cur_bus_speed;
> > +	msp = ctrl->pci_dev->subordinate->max_bus_speed;
> >   
> >   	/* Check if there are other slots or devices on the same bus */
> >   	if (!list_empty(&ctrl->pci_dev->subordinate->devices))
> 



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/