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

Re: [Xen-devel] [PATCH v2 0/4] Fix device listener interface for PCI to PCI bridges



On Mon, Jun 08, 2015 at 05:18:48PM -0400, Don Slutz wrote:
> changes v1 to v2:
>   Split v1 patch into 3.
> 
>   Added a BUG FIX patch (#1: "exec: Do not use MemoryRegion after
>   free").
> 
>     Technically this bug fix should be a separate patch, however this
>     issue only seems to reproduce when this patch set is applied.
> 
> 
>   Michael S. Tsirkin:
>     "You need some other API that makes sense, probably PCI specific."
>       This is basically patch #2: "Extend device listener interface..."
> 
>     "This is relying on undocumented assumptions and how specific
>     firmware works. There's nothing special about bus number 255,
>     and 0 is not very special either (except it happens to be the
>     reset value)."
>       Dropped all checking of 0 and 255.
> 
> 
> Open question by Michael S. Tsirkin:
> 
> >>>> On Thu, May 28, 2015 at 07:25:50AM -0400, Don Slutz wrote:
> ...
> >>>> It is not clear to me that the complexity of tracking bus
> >>>> visibility make sense.  Clearly you do.
> >>> Well what was the point of the change?
> >
> > To get config cycles that are valid that you do not get today.
> >
> >>> If you don't care that we get irrelevant config cycles why not
> >>> just send them all to QEMU?
> >>>
> >
> > That would need to be answered by Paul Durrant and/or other people (see
> > below)
> >
> 
> We could broadcast config space ioreqs to all emulators, the problem
> is how do we know (in the case of a read) which emulator is actually
> the one supplying the data? At some level Xen needs to know who is
> implementing what.
> 
>   Paul Durrant

Can irrelevant emulators all respond with some kind of nack?
Xen would pick the one that did respond correctly.

> So this patch set just adjusts Xen to correctly know the current set
> of PCI devices and their bus, device, and function.
> 
> It does not attempt to calculate the visibility of the PCI devices.

So non-visible devices will appear with invalid bus number values,
conflicting with the visible devices.
Seems wrong.


> 
> v1:
> 
> Note: Right now hvmloader in Xen does not handle PCI to PCI bridges
> and so SeaBIOS does not have access to PCI device(s) on secondary
> buses.  How ever domU can setup the secondary bus(es) and this patch
> will restore access to these PCI devices.
> 
> 
> Don Slutz (4):
>   exec: Do not use MemoryRegion after free
>   Extend device listener interface for PCI to PCI bridges
>   xen: Add usage of device listener interface for PCI to PCI bridges
>   xen: Fix map/unmap of pcidev to ioreq server
> 
>  exec.c                      |  8 ++++--
>  hw/core/qdev.c              |  7 ++++++
>  hw/pci/pci_bridge.c         | 18 +++++++++++++
>  include/hw/qdev-core.h      |  3 +++
>  include/hw/xen/xen_common.h | 61 
> ++++++++++++++++++++++++++++++++++-----------
>  trace-events                |  6 +++--
>  xen-hvm.c                   | 20 +++++++++++++--
>  7 files changed, 102 insertions(+), 21 deletions(-)
> 
> -- 
> 1.8.4

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.