On Mon, Jun 15, 2015 at 12:18:16PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > I'm wondering whenever things become easier if we add config registers
> > > to the pxb, where the firmware can program the bus number range and we
> > > can use the config register base as a way to specify which pxb we
Hi,
> > I'm wondering whenever things become easier if we add config registers
> > to the pxb, where the firmware can program the bus number range and we
> > can use the config register base as a way to specify which pxb we are
> > referring to ?
> But then we'll need a bunch of fw cfg entries
On Mon, Jun 15, 2015 at 08:01:08AM +0200, Gerd Hoffmann wrote:
> On Fr, 2015-06-12 at 09:23 -0400, Kevin O'Connor wrote:
> > On Fri, Jun 12, 2015 at 03:17:27PM +0300, Marcel Apfelbaum wrote:
> > > On 06/12/2015 09:00 AM, Gerd Hoffmann wrote:
> > > >>On each boot, coreboot might decide to assign a d
On 06/15/2015 09:50 AM, Gerd Hoffmann wrote:
Hi,
I'm wondering whenever things become easier if we add config registers
to the pxb, where the firmware can program the bus number range and we
can use the config register base as a way to specify which pxb we are
referring to ?
... and, while
On Mon, Jun 15, 2015 at 12:50:08PM +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2015-06-14 at 17:59 -0400, Kevin O'Connor wrote:
> > There are x86 systems with multiple separate PCI root buses where one
> > can access the pci config space of all the buses using the same 0x0cf8
> > IO space. Duri
Hi,
> I'm wondering whenever things become easier if we add config registers
> to the pxb, where the firmware can program the bus number range and we
> can use the config register base as a way to specify which pxb we are
> referring to ?
... and, while thinking about ben's reply elsewhere in t
On Fr, 2015-06-12 at 09:23 -0400, Kevin O'Connor wrote:
> On Fri, Jun 12, 2015 at 03:17:27PM +0300, Marcel Apfelbaum wrote:
> > On 06/12/2015 09:00 AM, Gerd Hoffmann wrote:
> > >>On each boot, coreboot might decide to assign a different bus id to
> > >>the extra roots (for example, if a device with
On Sun, 2015-06-14 at 17:59 -0400, Kevin O'Connor wrote:
> There are x86 systems with multiple separate PCI root buses where one
> can access the pci config space of all the buses using the same 0x0cf8
> IO space. During system setup, the multiple PCI root buses are each
> configured to only respo
On Mon, Jun 15, 2015 at 07:39:18AM +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2015-06-14 at 20:06 +0200, Michael S. Tsirkin wrote:
>
> > > As I understand it, the use case for multiple PCI roots is large
> > > servers that process a lot of IO.
> >
> > For better or worse, guest OS-es assume t
On Sun, 2015-06-14 at 20:06 +0200, Michael S. Tsirkin wrote:
> > As I understand it, the use case for multiple PCI roots is large
> > servers that process a lot of IO.
>
> For better or worse, guest OS-es assume that numa locality
> can only be specified for PCI roots.
>
> So the use case is to
On Sun, Jun 14, 2015 at 08:06:22PM +0200, Michael S. Tsirkin wrote:
> To summarise, you feel that modifying bus id without reordering
> bus ids between roots is likely, modifications that would
> cause reordering are unlikely, thus counting bus ids
> in order gives a stable index. Is that right?
Y
On Sun, Jun 14, 2015 at 10:50:22AM -0400, Kevin O'Connor wrote:
> On Sun, Jun 14, 2015 at 02:05:52PM +0200, Michael S. Tsirkin wrote:
> > On Fri, Jun 12, 2015 at 02:40:10PM -0400, Kevin O'Connor wrote:
> > > > (2) The QEMU command line and the effects the command line has on the
> > > > virtual har
On Sun, Jun 14, 2015 at 02:05:52PM +0200, Michael S. Tsirkin wrote:
> On Fri, Jun 12, 2015 at 02:40:10PM -0400, Kevin O'Connor wrote:
> > > (2) The QEMU command line and the effects the command line has on the
> > > virtual hardware should not change. However, all of the following have
> > > to be
On Sun, Jun 14, 2015 at 02:10:22PM +0200, Michael S. Tsirkin wrote:
> On Thu, Jun 11, 2015 at 12:48:22PM -0400, Kevin O'Connor wrote:
> > The SeaBIOS code is used on both virtual machines and real machines.
> > The bus number is something that is generated by software and it is
> > not assured to b
On Thu, Jun 11, 2015 at 12:48:22PM -0400, Kevin O'Connor wrote:
> On Thu, Jun 11, 2015 at 04:35:33PM +0200, Laszlo Ersek wrote:
> > On 06/11/15 15:58, Kevin O'Connor wrote:
> > > On Thu, Jun 11, 2015 at 04:37:08PM +0300, Marcel Apfelbaum wrote:
> > >> The fixes solves the following issue:
> > >> Th
On Fri, Jun 12, 2015 at 02:40:10PM -0400, Kevin O'Connor wrote:
> > (2) The QEMU command line and the effects the command line has on the
> > virtual hardware should not change. However, all of the following have
> > to be updated:
> >
> > - the "explicit_ofw_unit_address" property assignments in
On 06/12/15 20:40, Kevin O'Connor wrote:
> On Fri, Jun 12, 2015 at 05:45:04PM +0200, Laszlo Ersek wrote:
>> On 06/12/15 15:03, Kevin O'Connor wrote
>>> As for what I would suggest - well, SeaBIOS has already supported
>>> multiple root buses for years and already has a mechanism for
>>> determinist
On Fri, Jun 12, 2015 at 05:45:04PM +0200, Laszlo Ersek wrote:
> On 06/12/15 15:03, Kevin O'Connor wrote
> > As for what I would suggest - well, SeaBIOS has already supported
> > multiple root buses for years and already has a mechanism for
> > deterministically specifying a device on an extra root
On 06/12/15 15:03, Kevin O'Connor wrote
> On Fri, Jun 12, 2015 at 11:25:50AM +0200, Laszlo Ersek wrote:
>> On 06/11/15 21:24, Kevin O'Connor wrote:
>>> On Thu, Jun 11, 2015 at 08:34:56PM +0200, Laszlo Ersek wrote:
On 06/11/15 19:46, Marcel Apfelbaum wrote:
> On 06/11/2015 07:54 PM, Kevin O
On Fri, Jun 12, 2015 at 03:17:27PM +0300, Marcel Apfelbaum wrote:
> On 06/12/2015 09:00 AM, Gerd Hoffmann wrote:
> >>On each boot, coreboot might decide to assign a different bus id to
> >>the extra roots (for example, if a device with a PCI bridge is
> >>inserted and it's bus allocation causes bus
On Fri, Jun 12, 2015 at 11:25:50AM +0200, Laszlo Ersek wrote:
> On 06/11/15 21:24, Kevin O'Connor wrote:
> > On Thu, Jun 11, 2015 at 08:34:56PM +0200, Laszlo Ersek wrote:
> >> On 06/11/15 19:46, Marcel Apfelbaum wrote:
> >>> On 06/11/2015 07:54 PM, Kevin O'Connor wrote:
> On real machines, the
On 06/12/2015 09:00 AM, Gerd Hoffmann wrote:
Hi,
On each boot, coreboot might decide to assign a different bus id to
the extra roots (for example, if a device with a PCI bridge is
inserted and it's bus allocation causes bus ids to shift).
Technically, coreboot could even change the order ext
On 06/11/15 21:24, Kevin O'Connor wrote:
> On Thu, Jun 11, 2015 at 08:34:56PM +0200, Laszlo Ersek wrote:
>> On 06/11/15 19:46, Marcel Apfelbaum wrote:
>>> On 06/11/2015 07:54 PM, Kevin O'Connor wrote:
On real machines, the firmware assigns the 4 - it's not a physical
address; it's a logic
Hi,
> On each boot, coreboot might decide to assign a different bus id to
> the extra roots (for example, if a device with a PCI bridge is
> inserted and it's bus allocation causes bus ids to shift).
> Technically, coreboot could even change the order extra buses are
> assigned bus ids, but does
On Thu, Jun 11, 2015 at 08:34:56PM +0200, Laszlo Ersek wrote:
> On 06/11/15 19:46, Marcel Apfelbaum wrote:
> > On 06/11/2015 07:54 PM, Kevin O'Connor wrote:
> >> On real machines, the firmware assigns the 4 - it's not a physical
> >> address; it's a logical address (like all bus numbers in PCI). T
On Thu, Jun 11, 2015 at 08:46:01PM +0300, Marcel Apfelbaum wrote:
> On 06/11/2015 07:54 PM, Kevin O'Connor wrote:
> >On real machines, the firmware assigns the 4 - it's not a physical
> >address; it's a logical address (like all bus numbers in PCI). The
> >firmware might assign a totally different
On 06/11/15 19:46, Marcel Apfelbaum wrote:
> On 06/11/2015 07:54 PM, Kevin O'Connor wrote:
>> On Thu, Jun 11, 2015 at 05:36:06PM +0300, Marcel Apfelbaum wrote:
>>> On 06/11/2015 05:24 PM, Kevin O'Connor wrote:
On Thu, Jun 11, 2015 at 05:12:33PM +0300, Marcel Apfelbaum wrote:
> On 06/11/201
On 06/11/2015 07:54 PM, Kevin O'Connor wrote:
On Thu, Jun 11, 2015 at 05:36:06PM +0300, Marcel Apfelbaum wrote:
On 06/11/2015 05:24 PM, Kevin O'Connor wrote:
On Thu, Jun 11, 2015 at 05:12:33PM +0300, Marcel Apfelbaum wrote:
On 06/11/2015 04:58 PM, Kevin O'Connor wrote:
On Thu, Jun 11, 2015 at
On Thu, Jun 11, 2015 at 05:36:06PM +0300, Marcel Apfelbaum wrote:
> On 06/11/2015 05:24 PM, Kevin O'Connor wrote:
> >On Thu, Jun 11, 2015 at 05:12:33PM +0300, Marcel Apfelbaum wrote:
> >>On 06/11/2015 04:58 PM, Kevin O'Connor wrote:
> >>>On Thu, Jun 11, 2015 at 04:37:08PM +0300, Marcel Apfelbaum wr
On Thu, Jun 11, 2015 at 04:35:33PM +0200, Laszlo Ersek wrote:
> On 06/11/15 15:58, Kevin O'Connor wrote:
> > On Thu, Jun 11, 2015 at 04:37:08PM +0300, Marcel Apfelbaum wrote:
> >> The fixes solves the following issue:
> >> The PXB device exposes a new pci root bridge with the
> >> fw path: /pci-r
On 06/11/15 16:36, Marcel Apfelbaum wrote:
> On 06/11/2015 05:24 PM, Kevin O'Connor wrote:
>> On Thu, Jun 11, 2015 at 05:12:33PM +0300, Marcel Apfelbaum wrote:
>>> On 06/11/2015 04:58 PM, Kevin O'Connor wrote:
On Thu, Jun 11, 2015 at 04:37:08PM +0300, Marcel Apfelbaum wrote:
> The fixes so
On 06/11/2015 05:24 PM, Kevin O'Connor wrote:
On Thu, Jun 11, 2015 at 05:12:33PM +0300, Marcel Apfelbaum wrote:
On 06/11/2015 04:58 PM, Kevin O'Connor wrote:
On Thu, Jun 11, 2015 at 04:37:08PM +0300, Marcel Apfelbaum wrote:
The fixes solves the following issue:
The PXB device exposes a new pc
On 06/11/15 15:58, Kevin O'Connor wrote:
> On Thu, Jun 11, 2015 at 04:37:08PM +0300, Marcel Apfelbaum wrote:
>> The fixes solves the following issue:
>> The PXB device exposes a new pci root bridge with the
>> fw path: /pci-root@4/..., in which 4 is the root bus number.
>> Before this patch the f
On Thu, Jun 11, 2015 at 05:12:33PM +0300, Marcel Apfelbaum wrote:
> On 06/11/2015 04:58 PM, Kevin O'Connor wrote:
> >On Thu, Jun 11, 2015 at 04:37:08PM +0300, Marcel Apfelbaum wrote:
> >>The fixes solves the following issue:
> >>The PXB device exposes a new pci root bridge with the
> >>fw path: /
On 06/11/2015 04:58 PM, Kevin O'Connor wrote:
On Thu, Jun 11, 2015 at 04:37:08PM +0300, Marcel Apfelbaum wrote:
The fixes solves the following issue:
The PXB device exposes a new pci root bridge with the
fw path: /pci-root@4/..., in which 4 is the root bus number.
Before this patch the fw path
On Thu, Jun 11, 2015 at 04:37:08PM +0300, Marcel Apfelbaum wrote:
> The fixes solves the following issue:
> The PXB device exposes a new pci root bridge with the
> fw path: /pci-root@4/..., in which 4 is the root bus number.
> Before this patch the fw path was wrongly computed:
> /pci-root@1/
On 06/11/15 15:37, Marcel Apfelbaum wrote:
> The fixes solves the following issue:
> The PXB device exposes a new pci root bridge with the
> fw path: /pci-root@4/..., in which 4 is the root bus number.
> Before this patch the fw path was wrongly computed:
> /pci-root@1/pci@i0cf8/...
> Fix the
The fixes solves the following issue:
The PXB device exposes a new pci root bridge with the
fw path: /pci-root@4/..., in which 4 is the root bus number.
Before this patch the fw path was wrongly computed:
/pci-root@1/pci@i0cf8/...
Fix the above issues: Correct the bus number and remove the
ex
38 matches
Mail list logo
