From: Ian Campbell <ian.campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: "Prasun.kapoor@cavium.com" <Prasun.kapoor@cavium.com>,
Manish Jaggi <mjaggi@caviumnetworks.com>,
"Kumar, Vijaya" <Vijaya.Kumar@caviumnetworks.com>,
Julien Grall <julien.grall@linaro.org>,
Xen Devel <xen-devel@lists.xen.org>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: PCI Passthrough Design - Draft 3
Date: Wed, 12 Aug 2015 15:42:10 +0100 [thread overview]
Message-ID: <1439390530.8356.41.camel@citrix.com> (raw)
In-Reply-To: <20150812142549.GE17002@l.oracle.com>
On Wed, 2015-08-12 at 10:25 -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Aug 12, 2015 at 09:56:41AM +0100, Ian Campbell wrote:
> > On Tue, 2015-08-11 at 16:34 -0400, Konrad Rzeszutek Wilk wrote:
> > >
> > > > 2.2 PHYSDEVOP_pci_host_bridge_add hypercall
> > > > ----------------------------------------------
> > > > Xen code accesses PCI configuration space based on the sbdf
> > > > received from
> > > > the
> > > > guest. The order in which the pci device tree node appear may not
> > > > be the
> > > > same
> > > > order of device enumeration in dom0. Thus there needs to be a
> > > > mechanism to
> > > > bind
> > > > the segment number assigned by dom0 to the pci host controller. The
> > > > hypercall
> > > > is introduced:
> > >
> > > Why can't we extend the existing hypercall to have the segment value?
> > >
> > > Oh wait, PHYSDEVOP_manage_pci_add_ext does it already!
> > >
> > > And have the hypercall (and Xen) be able to deal with introduction of
> > > PCI
> > > devices that are out of sync?
> > >
> > > Maybe I am confused but aren't PCI host controllers also 'uploaded'
> > > to
> > > Xen?
> >
> > The issue is that Dom0 and Xen need to agree on a common numbering
> > space
> > for the "PCI domain" AKA "segment", which is really just a software
> > concept
> > i.e. on ARM Linux just makes them up (on x86 I believe they come from
> > some
> > firmware table so Xen and Dom0 "agree" to both use that).
>
> Doesn't the PCI domain or segments have an notion of which PCI devices are
> underneath it? Or vice-verse - PCI devices know what their segment (or domain) is?
The PCI domain or segment does contain a device, but it is a purely OS
level concept, it has no real meaning in the hardware. So both Xen and
Linux are free to fabricate whatever segment naming space they want, but
obviously they need to agree, hence this hypercall lets Linux tell Xen what
segment it has associated with a given PCI controller.
Perhaps an example will help.
Imagine we have two PCI host bridges, one with CFG space at 0xA0000000 and
a second with CFG space at 0xB0000000.
Xen discovers these and assigns segment 0=0xA0000000 and segment
1=0xB0000000.
Dom0 discovers them too but assigns segment 1=0xA0000000 and segment
0=0xB0000000 (i.e. the other way).
Now Dom0 makes a hypercall referring to a device as (segment=1,BDF), i.e.
the device with BDF behind the root bridge at 0xA0000000. (Perhaps this is
the PHYSDEVOP_manage_pci_add_ext call).
But Xen thinks it is talking about the device with BDF behind the root
bridge at 0xB0000000 because Dom0 and Xen do not agree on what the segments
mean. Now Xen will use the wrong device ID in the IOMMU (since that is
associated with the host bridge), or poke the wrong configuration space, or
whatever.
Or maybe Xen chose 42=0xB0000000 and 43=0xA0000000 so when Dom0 starts
talking about segment=0 and =1 it has no idea what is going on.
PHYSDEVOP_pci_host_bridge_add is intended to allow Dom0 to say "Segment 0
is the host bridge at 0xB0000000" and "Segment 1 is the host bridge at
0xA0000000". With this there is no confusion between Xen and Dom0 because
Xen isn't picking a segment ID, it is being told what it is by Dom0 which
has done the picking.
Does that help?
Ian.
next prev parent reply other threads:[~2015-08-12 14:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-04 12:27 PCI Passthrough Design - Draft 3 Manish Jaggi
2015-08-11 20:34 ` Konrad Rzeszutek Wilk
2015-08-12 7:33 ` Manish Jaggi
2015-08-12 14:24 ` Konrad Rzeszutek Wilk
2015-08-12 8:56 ` Ian Campbell
2015-08-12 14:25 ` Konrad Rzeszutek Wilk
2015-08-12 14:42 ` Ian Campbell [this message]
2015-08-12 14:55 ` Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1439390530.8356.41.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=Prasun.kapoor@cavium.com \
--cc=Vijaya.Kumar@caviumnetworks.com \
--cc=julien.grall@linaro.org \
--cc=konrad.wilk@oracle.com \
--cc=mjaggi@caviumnetworks.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.