[Ksummit-2012-discuss] PCI breakout session
benh at kernel.crashing.org
Mon Jun 18 10:19:45 UTC 2012
On Mon, 2012-06-18 at 11:08 +0300, Michael S. Tsirkin wrote:
> > > The "right" approach is to probably move the resource assignment to
> > > between the initial scan pass and the "adding" of devices (in our PCI
> > > stack terminology, adding -> register with the driver model), and
> > > naturally have the final fixups called right before the latter. But this
> > > will have some sort of impact on all archs so we probably want to do
> > > quite a bit of code auditing first.
> An interesting related problem is hot-plugging complex bridged hierarchies - esoteric
> on real hardware but easy and sometimes useful in a VM.
> It would seem that at least for that space, adding support
> for moving resources around could be useful. For things like IO it
> only seems possible to do with cooperation from the drivers - and at least for
> VMs that's not such a big deal as we only emulate a handful of devices.
> Or do we need to try and solve it generally straight away?
I'd say don't do it :-) Or rather try to give each device in the VM its
own dedicated virtual host bridge & bus :-) There are pros and cons to
the approach of course, if it's pass-through and the devices are in a
single isolation group they must be showed at once, but in that case,
I'd say show up the whole group as one host bridge with the stuff below
it. We've been spending quite a bit of time on that for KVM/ppc so let's
add that to the agenda for the discussion if you want.
(We can start on the linux-pci list if you prefer).
> > >
> > > Of course that's scary since PCI is so prone to regressions, especially
> > > on x86 ...
> > >
> > > I have some specific issues with resource allocation on bridges that
> > > segment the MMIO space in interesting ways (for error handling) that I
> > > want to discuss and get feedback on how to best deal with.
> > >
> > > Do we start writing an agenda ?
> > Could we do it on the second mini-summit day? I suspect most of the
> > arch maintainers will want to be there, since PCI is bound into all our
> > architectures in some quite unique ways.
> > James
More information about the Ksummit-2012-discuss