On Tuesday 17 March 2015 06:01 PM, Jan Beulich wrote:
On 17.03.15 at 13:06, mja...@caviumnetworks.com wrote:
On Tuesday 17 March 2015 12:58 PM, Jan Beulich wrote:
On 17.03.15 at 06:26, mja...@caviumnetworks.com wrote:
In drivers/xen/pci.c on notification BUS_NOTIFY_ADD_DEVICE dom0 issues a
On 17.03.15 at 06:26, mja...@caviumnetworks.com wrote:
In drivers/xen/pci.c on notification BUS_NOTIFY_ADD_DEVICE dom0 issues a
hypercall to inform xen that a new pci device has been added.
If we were to inform xen about a new pci bus that is added there are 2 ways
a) Issue the hypercall
On Tuesday 17 March 2015 12:58 PM, Jan Beulich wrote:
On 17.03.15 at 06:26, mja...@caviumnetworks.com wrote:
In drivers/xen/pci.c on notification BUS_NOTIFY_ADD_DEVICE dom0 issues a
hypercall to inform xen that a new pci device has been added.
If we were to inform xen about a new pci bus that
On 17.03.15 at 13:06, mja...@caviumnetworks.com wrote:
On Tuesday 17 March 2015 12:58 PM, Jan Beulich wrote:
On 17.03.15 at 06:26, mja...@caviumnetworks.com wrote:
In drivers/xen/pci.c on notification BUS_NOTIFY_ADD_DEVICE dom0 issues a
hypercall to inform xen that a new pci device has been
On Tue, Mar 17, 2015 at 10:56:48AM +0530, Manish Jaggi wrote:
On Friday 27 February 2015 10:20 PM, Ian Campbell wrote:
On Fri, 2015-02-27 at 16:35 +, Jan Beulich wrote:
On 27.02.15 at 16:24, ian.campb...@citrix.com wrote:
On Fri, 2015-02-27 at 14:54 +, Stefano Stabellini wrote:
On Friday 27 February 2015 10:20 PM, Ian Campbell wrote:
On Fri, 2015-02-27 at 16:35 +, Jan Beulich wrote:
On 27.02.15 at 16:24, ian.campb...@citrix.com wrote:
On Fri, 2015-02-27 at 14:54 +, Stefano Stabellini wrote:
MMCFG is a Linux config option, not to be confused with
On 11.03.15 at 19:26, stefano.stabell...@eu.citrix.com wrote:
On Mon, 23 Feb 2015, Jan Beulich wrote:
On 20.02.15 at 18:33, ian.campb...@citrix.com wrote:
On Fri, 2015-02-20 at 15:15 +, Jan Beulich wrote:
That's the issue we are trying to resolve, with device tree there is no
On Wed, 2015-03-11 at 18:26 +, Stefano Stabellini wrote:
In other words I think that we still need PHYSDEVOP_pci_host_bridge_add
(http://marc.info/?l=xen-develm=142470392016381) or equivalent, but
we can drop the bus field from the struct.
I think it makes sense for the struct to contain a
On Thu, 12 Mar 2015, Jan Beulich wrote:
On 11.03.15 at 19:26, stefano.stabell...@eu.citrix.com wrote:
On Mon, 23 Feb 2015, Jan Beulich wrote:
On 20.02.15 at 18:33, ian.campb...@citrix.com wrote:
On Fri, 2015-02-20 at 15:15 +, Jan Beulich wrote:
That's the issue we are trying to
On 12.03.15 at 11:33, stefano.stabell...@eu.citrix.com wrote:
On Thu, 12 Mar 2015, Jan Beulich wrote:
On 11.03.15 at 19:26, stefano.stabell...@eu.citrix.com wrote:
On Mon, 23 Feb 2015, Jan Beulich wrote:
No - there can be multiple roots (i.e. host bridges) on a single
segment. Segments
On Mon, 23 Feb 2015, Jan Beulich wrote:
On 20.02.15 at 18:33, ian.campb...@citrix.com wrote:
On Fri, 2015-02-20 at 15:15 +, Jan Beulich wrote:
That's the issue we are trying to resolve, with device tree there is no
explicit segment ID, so we have an essentially unindexed set of PCI
On Monday 02 March 2015 05:18 PM, Ian Campbell wrote:
On Fri, 2015-02-27 at 17:15 +, Stefano Stabellini wrote:
On Fri, 27 Feb 2015, Ian Campbell wrote:
On Fri, 2015-02-27 at 16:35 +, Jan Beulich wrote:
On 27.02.15 at 16:24, ian.campb...@citrix.com wrote:
On Fri, 2015-02-27 at 14:54
On Fri, 2015-02-27 at 17:15 +, Stefano Stabellini wrote:
On Fri, 27 Feb 2015, Ian Campbell wrote:
On Fri, 2015-02-27 at 16:35 +, Jan Beulich wrote:
On 27.02.15 at 16:24, ian.campb...@citrix.com wrote:
On Fri, 2015-02-27 at 14:54 +, Stefano Stabellini wrote:
MMCFG is a
On 27.02.15 at 16:24, ian.campb...@citrix.com wrote:
On Fri, 2015-02-27 at 14:54 +, Stefano Stabellini wrote:
MMCFG is a Linux config option, not to be confused with
PHYSDEVOP_pci_mmcfg_reserved that is a Xen hypercall interface. I don't
think that the way Linux (or FreeBSD) call
On Fri, 27 Feb 2015, Ian Campbell wrote:
On Fri, 2015-02-27 at 16:35 +, Jan Beulich wrote:
On 27.02.15 at 16:24, ian.campb...@citrix.com wrote:
On Fri, 2015-02-27 at 14:54 +, Stefano Stabellini wrote:
MMCFG is a Linux config option, not to be confused with
On Fri, 2015-02-27 at 14:33 +, Stefano Stabellini wrote:
On Thu, 26 Feb 2015, Ian Campbell wrote:
On Thu, 2015-02-26 at 15:39 +0530, Manish Jaggi wrote:
Have you reached a conclusion?
My current thinking on how PCI for Xen on ARM should look is thus:
xen/arch/arm/pci.c:
On Thu, 26 Feb 2015, Ian Campbell wrote:
On Thu, 2015-02-26 at 15:39 +0530, Manish Jaggi wrote:
Have you reached a conclusion?
My current thinking on how PCI for Xen on ARM should look is thus:
xen/arch/arm/pci.c:
New file, containing core PCI infrastructure for ARM. Includes:
On Fri, 2015-02-27 at 15:41 +0530, Pranavkumar Sawargaonkar wrote:
Hi Julien,
On Thu, Feb 26, 2015 at 8:47 PM, Julien Grall julien.gr...@linaro.org wrote:
On 26/02/15 14:46, Pranavkumar Sawargaonkar wrote:
Hi
Hi Pranavkumar,
Also if we just show only one vITS (or only one Virtual
Hi Julien,
On Thu, Feb 26, 2015 at 8:47 PM, Julien Grall julien.gr...@linaro.org wrote:
On 26/02/15 14:46, Pranavkumar Sawargaonkar wrote:
Hi
Hi Pranavkumar,
Also if we just show only one vITS (or only one Virtual v2m frame)
instead of two vITS
then actual hardware interrupt number and
On 26/02/15 14:46, Pranavkumar Sawargaonkar wrote:
Hi
Hi Pranavkumar,
Also if we just show only one vITS (or only one Virtual v2m frame)
instead of two vITS
then actual hardware interrupt number and virtual interrupt number
which guest will see will become different
This will hamper direct
Hi
On Thu, Feb 26, 2015 at 4:19 PM, Vijay Kilari vijay.kil...@gmail.com wrote:
On Wed, Feb 25, 2015 at 3:50 PM, Ian Campbell ian.campb...@citrix.com wrote:
On Wed, 2015-02-25 at 08:03 +0530, Manish Jaggi wrote:
On 24/02/15 7:13 pm, Julien Grall wrote:
On 24/02/15 00:23, Manish Jaggi wrote:
On Thu, 2015-02-26 at 16:19 +0530, Vijay Kilari wrote:
On Wed, Feb 25, 2015 at 3:50 PM, Ian Campbell ian.campb...@citrix.com wrote:
On Wed, 2015-02-25 at 08:03 +0530, Manish Jaggi wrote:
On 24/02/15 7:13 pm, Julien Grall wrote:
On 24/02/15 00:23, Manish Jaggi wrote:
Because you have to
Hi Ian,
On 26/02/15 11:12, Ian Campbell wrote:
I have few queries
1) If Dom0 has 'n' ITS nodes, then how does Xen know which virtual ITS
command Q is
mapped to which Physical ITS command Q.
In case of linux, the ITS node is added as msi chip to pci using
of_pci_msi_chip_add()
On Wed, Feb 25, 2015 at 3:50 PM, Ian Campbell ian.campb...@citrix.com wrote:
On Wed, 2015-02-25 at 08:03 +0530, Manish Jaggi wrote:
On 24/02/15 7:13 pm, Julien Grall wrote:
On 24/02/15 00:23, Manish Jaggi wrote:
Because you have to parse all the device tree to remove the reference
to the
On Monday 23 February 2015 09:50 PM, Jan Beulich wrote:
On 23.02.15 at 16:46, ian.campb...@citrix.com wrote:
On Mon, 2015-02-23 at 15:27 +, Jan Beulich wrote:
On 23.02.15 at 16:02, ian.campb...@citrix.com wrote:
Is the reason for the scan being of segment 0 only is that it is the one
On Thu, 2015-02-26 at 15:39 +0530, Manish Jaggi wrote:
Have you reached a conclusion?
My current thinking on how PCI for Xen on ARM should look is thus:
xen/arch/arm/pci.c:
New file, containing core PCI infrastructure for ARM. Includes:
pci_hostbridge_register(), which
On Wed, 2015-02-25 at 08:03 +0530, Manish Jaggi wrote:
On 24/02/15 7:13 pm, Julien Grall wrote:
On 24/02/15 00:23, Manish Jaggi wrote:
Because you have to parse all the device tree to remove the reference
to the second ITS. It's pointless and can be difficult to do it.
Could you please
On 24/02/15 7:13 pm, Julien Grall wrote:
On 24/02/15 00:23, Manish Jaggi wrote:
Because you have to parse all the device tree to remove the reference
to the second ITS. It's pointless and can be difficult to do it.
Could you please describe the case where it is difficult
You have to parse
On 20/02/15 8:09 pm, Ian Campbell wrote:
On Fri, 2015-02-20 at 19:44 +0530, Manish Jaggi wrote:
Another option might be a new hypercall (assuming one doesn't already
exist) to register a PCI bus which would take e.g. the PCI CFG base
address and return a new u16 segment id to be used for all
On 23/02/2015 10:59, Manish Jaggi wrote:
On 20/02/15 8:09 pm, Ian Campbell wrote:
On Fri, 2015-02-20 at 19:44 +0530, Manish Jaggi wrote:
Another option might be a new hypercall (assuming one doesn't already
exist) to register a PCI bus which would take e.g. the PCI CFG base
address and
On 23.02.15 at 13:45, ian.campb...@citrix.com wrote:
On Mon, 2015-02-23 at 08:43 +, Jan Beulich wrote:
On 20.02.15 at 18:33, ian.campb...@citrix.com wrote:
On Fri, 2015-02-20 at 15:15 +, Jan Beulich wrote:
That's the issue we are trying to resolve, with device tree there is no
On Mon, 2015-02-23 at 14:07 +, Jan Beulich wrote:
On 23.02.15 at 13:45, ian.campb...@citrix.com wrote:
On Mon, 2015-02-23 at 08:43 +, Jan Beulich wrote:
On 20.02.15 at 18:33, ian.campb...@citrix.com wrote:
On Fri, 2015-02-20 at 15:15 +, Jan Beulich wrote:
That's the issue
On 23/02/15 4:44 pm, Julien Grall wrote:
On 23/02/2015 10:59, Manish Jaggi wrote:
On 20/02/15 8:09 pm, Ian Campbell wrote:
On Fri, 2015-02-20 at 19:44 +0530, Manish Jaggi wrote:
Another option might be a new hypercall (assuming one doesn't already
exist) to register a PCI bus which would
On Mon, 2015-02-23 at 08:43 +, Jan Beulich wrote:
On 20.02.15 at 18:33, ian.campb...@citrix.com wrote:
On Fri, 2015-02-20 at 15:15 +, Jan Beulich wrote:
That's the issue we are trying to resolve, with device tree there is no
explicit segment ID, so we have an essentially
On Mon, 2015-02-23 at 14:45 +, Jan Beulich wrote:
On 23.02.15 at 15:33, ian.campb...@citrix.com wrote:
On Mon, 2015-02-23 at 14:07 +, Jan Beulich wrote:
On 23.02.15 at 13:45, ian.campb...@citrix.com wrote:
In which case might we be at liberty to specify that on ARM+Device Tree
On 23/02/15 11:50, Manish Jaggi wrote:
On 23/02/15 4:44 pm, Julien Grall wrote:
On 23/02/2015 10:59, Manish Jaggi wrote:
On 20/02/15 8:09 pm, Ian Campbell wrote:
On Fri, 2015-02-20 at 19:44 +0530, Manish Jaggi wrote:
Another option might be a new hypercall (assuming one doesn't already
On 23.02.15 at 15:33, ian.campb...@citrix.com wrote:
On Mon, 2015-02-23 at 14:07 +, Jan Beulich wrote:
On 23.02.15 at 13:45, ian.campb...@citrix.com wrote:
In which case might we be at liberty to specify that on ARM+Device Tree
systems (i.e. those where the f/w tables don't give an
On 23.02.15 at 16:02, ian.campb...@citrix.com wrote:
On Mon, 2015-02-23 at 14:45 +, Jan Beulich wrote:
In which case the Dom0 OS doing so would need to communicate
its decisions to the hypervisor, as you suggest further down.
So more concretely something like:
#define
On Mon, 2015-02-23 at 15:27 +, Jan Beulich wrote:
On 23.02.15 at 16:02, ian.campb...@citrix.com wrote:
On Mon, 2015-02-23 at 14:45 +, Jan Beulich wrote:
In which case the Dom0 OS doing so would need to communicate
its decisions to the hypervisor, as you suggest further down.
On 23.02.15 at 16:46, ian.campb...@citrix.com wrote:
On Mon, 2015-02-23 at 15:27 +, Jan Beulich wrote:
On 23.02.15 at 16:02, ian.campb...@citrix.com wrote:
Is the reason for the scan being of segment 0 only is that it is the one
which lives at the legacy PCI CFG addresses (or those
On 20.02.15 at 18:33, ian.campb...@citrix.com wrote:
On Fri, 2015-02-20 at 15:15 +, Jan Beulich wrote:
That's the issue we are trying to resolve, with device tree there is no
explicit segment ID, so we have an essentially unindexed set of PCI
buses in both Xen and dom0.
How that?
On 20/02/15 12:10, Manish Jaggi wrote:
On 20/02/15 5:33 pm, Julien Grall wrote:
Hello Manish,
On 20/02/15 11:34, Manish Jaggi wrote:
The platform APIs are enhanced to provide support for parsing pci device
tree nodes and storing the config-space address which is later used for
On 20/02/15 5:33 pm, Julien Grall wrote:
Hello Manish,
On 20/02/15 11:34, Manish Jaggi wrote:
The platform APIs are enhanced to provide support for parsing pci device
tree nodes and storing the config-space address which is later used for
pci_read/pci_write config calls.
Can you explain why
On 20.02.15 at 14:45, ian.campb...@citrix.com wrote:
(Jan, curious if you have any thoughts on this, hopefully I've left
sufficient context for you to get what we are on about, the gist is we
need some way for dom0 and Xen to agree on how a PCI segment ID maps to
an actual PCI root
On Fri, 2015-02-20 at 12:20 +, Julien Grall wrote:
Overall, I would prefer to have a separate file and structure for
handling PCI host. Also, I think we could re-use the Linux code for this
purpose.
(caveat; I've not looked at the code yet)
I had expected that PCI host controllers would
(Jan, curious if you have any thoughts on this, hopefully I've left
sufficient context for you to get what we are on about, the gist is we
need some way for dom0 and Xen to agree on how a PCI segment ID maps to
an actual PCI root controller, I think on x86 you either Just Know from
PC legacy or
On Fri, 2015-02-20 at 14:11 +, Jan Beulich wrote:
On 20.02.15 at 14:45, ian.campb...@citrix.com wrote:
(Jan, curious if you have any thoughts on this, hopefully I've left
sufficient context for you to get what we are on about, the gist is we
need some way for dom0 and Xen to agree on
On 20.02.15 at 15:26, ian.campb...@citrix.com wrote:
On Fri, 2015-02-20 at 14:11 +, Jan Beulich wrote:
Otherwise,
just sequentially assign segment numbers as you discover them or
get them reported by Dom0. You could even have Dom0 tell you
the segment numbers (just like we do on x86),
On Fri, 2015-02-20 at 19:44 +0530, Manish Jaggi wrote:
Another option might be a new hypercall (assuming one doesn't already
exist) to register a PCI bus which would take e.g. the PCI CFG base
address and return a new u16 segment id to be used for all subsequent
PCI related calls. This
On Fri, 2015-02-20 at 14:39 +, Jan Beulich wrote:
On 20.02.15 at 15:26, ian.campb...@citrix.com wrote:
On Fri, 2015-02-20 at 14:11 +, Jan Beulich wrote:
Otherwise,
just sequentially assign segment numbers as you discover them or
get them reported by Dom0. You could even have Dom0
On 20.02.15 at 16:01, ian.campb...@citrix.com wrote:
On Fri, 2015-02-20 at 14:39 +, Jan Beulich wrote:
plus the MMCFG reporting one (PHYSDEVOP_pci_mmcfg_reserved).
This looks promising, but rather under-documented.
#define PHYSDEVOP_pci_mmcfg_reserved24
struct
On 20/02/15 15:13, Manish Jaggi wrote:
On x86 you solve this because both Xen and dom0 can parse the same table
and reach the same answer, sadly DT doesn't have everything needed in
it.
In fact xen and dom0 use the same device tree nodes and in the same
order. xen creates the device tree for
On 20/02/15 8:31 pm, Ian Campbell wrote:
On Fri, 2015-02-20 at 14:39 +, Jan Beulich wrote:
On 20.02.15 at 15:26, ian.campb...@citrix.com wrote:
On Fri, 2015-02-20 at 14:11 +, Jan Beulich wrote:
Otherwise,
just sequentially assign segment numbers as you discover them or
get them
On Fri, 2015-02-20 at 15:15 +, Jan Beulich wrote:
That's the issue we are trying to resolve, with device tree there is no
explicit segment ID, so we have an essentially unindexed set of PCI
buses in both Xen and dom0.
How that? What if two bus numbers are equal? There ought to be
54 matches
Mail list logo
