qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [0/10] Clean up PCI code to allow for multiple root bus


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [0/10] Clean up PCI code to allow for multiple root buses (v2)
Date: Thu, 6 Jun 2013 13:01:49 +0300

On Thu, Jun 06, 2013 at 06:48:44PM +1000, David Gibson wrote:
> The current PCI subsystem has kind of half-hearted support for
> multiple independent root buses - aka PCI domains - in the form of the
> PCIHostBus structure and its domain field.  However, it doesn't quite
> work because pci_host_bus_register() is always called with a domain of
> 0.
> 
> Worse, though, the whole concept of numbered domains isn't general
> enough.  Many platforms can have independent root buses (usually on
> wholly independent host bridges), but only x86 gives them a
> hardware-significant domain number, essentially as a hack to allow all
> the separate config spaces to be accessed via the same IO ports.
> Linux guests on other platforms will show domain numbers in lspci, but
> these are purely guest assigned, so qemu won't know about them.
> 
> This patch series, therefore, removes the broken-as-is domain concept
> from qemu, and replaces it with a different way of handling multiple
> root buses, based on a host bridge class method to provide a
> identifier for the root bus.  This hook is designed in such a way as
> to allow a single bridge object to support mutiple root buses with
> future changes, which will allow future implementations of x86 north
> bridges with multiple domains to be supported correctly, and in way
> that matches the existing practice for all external interfaces.
> 
> v2:
>   * Rework concept of "primary" bus in response to Michael Tsirkin's
>     comments.


Looks good to me.

Acked-by: Michael S. Tsirkin <address@hidden>

I'll wait a bit so others have a chance to comment, then apply
if everyone is happy.

No need to repost for the lack of -M flag - I wish there was a way
to specify that in git config.

-- 
MST



reply via email to

[Prev in Thread] Current Thread [Next in Thread]