[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [SeaBIOS] [PATCH] hw/pci: reserve IO and mem for pci-2-
From: |
Gerd Hoffmann |
Subject: |
Re: [Qemu-devel] [SeaBIOS] [PATCH] hw/pci: reserve IO and mem for pci-2-pci bridges with no devices attached |
Date: |
Tue, 08 Apr 2014 08:05:23 +0200 |
On Mo, 2014-04-07 at 16:34 +0300, Michael S. Tsirkin wrote:
> On Mon, Apr 07, 2014 at 02:44:06PM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > > + u8 shpc_cap = pci_find_capability(s->bus_dev, PCI_CAP_ID_SHPC);
> >
> > > One thing I'd do is maybe check that the relevant memory type is
> > > enabled in the bridge (probably just by writing fff to base and reading
> > > it back).
> >
> > > This will give hypervisors an option to avoid wasting resources:
> > > e.g. it's uncommon for express devices to claim IO.
> >
> > I don't think we'll need that for the SHPC bridge.
>
> Why not?
With typical use cases for the shpc bridge you likely need the io window
anyway.
> I'm referring to this text in the bridge specification:
>
> The I/O Base and I/O Limit registers are optional and define an address
> range that is used
> by the bridge to determine when to forward I/O transactions from one
> interface to the
> other.
> If a bridge does not implement an I/O address range, then both the I/O
> Base and I/O
> Limit registers must be implemented as read-only registers that return
> zero when read. If a
> bridge supports an I/O address range, then these registers must be
> initialized by
> configuration software so default states are not specified.
>
> So we should probe bridge for I/O support before wasting I/O resources on it.
Yes, makes sense from a correctness point of view.
I suspect you'll have a hard time to find such bridges in the x86 world
though, so I'm not sure it is a good idea to emulate this in qemu.
Guests might not handle it correctly.
> > For express it indeed makes sense to avoid claiming IO address space.
> > I'd try to find something more automatic though, where you don't need
> > some kind of "disable io for this express port" config option.
>
> Won't same trick as above work?
Yes, it will work.
But as we probably want support io on express devices (because it is
used in practice, even though being strongly discouraged in the pci
express specs). So doing it that way would require a config switch on
the qemu side to turn on/off io address space support for express
switches/ports.
cheers,
Gerd
- Re: [Qemu-devel] [SeaBIOS] [PATCH] hw/pci: reserve IO and mem for pci-2-pci bridges with no devices attached, (continued)
- Re: [Qemu-devel] [SeaBIOS] [PATCH] hw/pci: reserve IO and mem for pci-2-pci bridges with no devices attached, Michael S. Tsirkin, 2014/04/07
- Re: [Qemu-devel] [SeaBIOS] [PATCH] hw/pci: reserve IO and mem for pci-2-pci bridges with no devices attached, Gerd Hoffmann, 2014/04/07
- Re: [Qemu-devel] [SeaBIOS] [PATCH] hw/pci: reserve IO and mem for pci-2-pci bridges with no devices attached, Marcel Apfelbaum, 2014/04/07
- Re: [Qemu-devel] [SeaBIOS] [PATCH] hw/pci: reserve IO and mem for pci-2-pci bridges with no devices attached, Michael S. Tsirkin, 2014/04/07
- Re: [Qemu-devel] [SeaBIOS] [PATCH] hw/pci: reserve IO and mem for pci-2-pci bridges with no devices attached, Marcel Apfelbaum, 2014/04/07
- Re: [Qemu-devel] [SeaBIOS] [PATCH] hw/pci: reserve IO and mem for pci-2-pci bridges with no devices attached, Marcel Apfelbaum, 2014/04/07
- Re: [Qemu-devel] [SeaBIOS] [PATCH] hw/pci: reserve IO and mem for pci-2-pci bridges with no devices attached, Michael S. Tsirkin, 2014/04/07
- Re: [Qemu-devel] [SeaBIOS] [PATCH] hw/pci: reserve IO and mem for pci-2-pci bridges with no devices attached, Marcel Apfelbaum, 2014/04/07
- Re: [Qemu-devel] [SeaBIOS] [PATCH] hw/pci: reserve IO and mem for pci-2-pci bridges with no devices attached, Michael S. Tsirkin, 2014/04/07
- Re: [Qemu-devel] [SeaBIOS] [PATCH] hw/pci: reserve IO and mem for pci-2-pci bridges with no devices attached,
Gerd Hoffmann <=
- Re: [Qemu-devel] [SeaBIOS] [PATCH] hw/pci: reserve IO and mem for pci-2-pci bridges with no devices attached, Michael S. Tsirkin, 2014/04/08