On Fri, 2015-07-31 at 13:59 +0100, Julien Grall wrote:
Hi Manish,
On 31/07/15 13:50, Manish Jaggi wrote:
Ok, i will implement the same from pciback to toolstack. I am not sure
about the complexity but will give it a try.
With this xen-pciback will not create the vdev-X entry at all.
On 31/07/15 4:49 pm, Ian Campbell wrote:
On Fri, 2015-07-31 at 16:37 +0530, Manish Jaggi wrote:
On Friday 31 July 2015 01:35 PM, Ian Campbell wrote:
On Fri, 2015-07-31 at 13:16 +0530, Manish Jaggi wrote:
Secondly, the vdev-X entry is created async by dom0 watching on
event.
So how the tools
On 31/07/15 8:26 pm, Julien Grall wrote:
On 31/07/15 15:33, Manish Jaggi wrote:
Hi Julien,
On 31/07/15 6:29 pm, Julien Grall wrote:
Hi Manish,
On 31/07/15 13:50, Manish Jaggi wrote:
Ok, i will implement the same from pciback to toolstack. I am not sure
about the complexity but will give
On 31/07/15 16:12, Manish Jaggi wrote:
Usually the time between two draft should be pretty short in order to
get sane base for discussion. For now, we are talking about small
portion of design and speculating/trying to remember what was agreed on
other sub-thread.
ok will send draft 3 with
On 31/07/15 15:33, Manish Jaggi wrote:
Hi Julien,
On 31/07/15 6:29 pm, Julien Grall wrote:
Hi Manish,
On 31/07/15 13:50, Manish Jaggi wrote:
Ok, i will implement the same from pciback to toolstack. I am not sure
about the complexity but will give it a try.
With this xen-pciback will not
On Fri, 2015-07-31 at 18:20 +0530, Manish Jaggi wrote:
On 31/07/15 4:49 pm, Ian Campbell wrote:
On Fri, 2015-07-31 at 16:37 +0530, Manish Jaggi wrote:
On Friday 31 July 2015 01:35 PM, Ian Campbell wrote:
On Fri, 2015-07-31 at 13:16 +0530, Manish Jaggi wrote:
Secondly, the vdev-X
Hi Julien,
On 31/07/15 6:29 pm, Julien Grall wrote:
Hi Manish,
On 31/07/15 13:50, Manish Jaggi wrote:
Ok, i will implement the same from pciback to toolstack. I am not sure
about the complexity but will give it a try.
With this xen-pciback will not create the vdev-X entry at all.
Can you
On Fri, 2015-07-31 at 13:16 +0530, Manish Jaggi wrote:
Secondly, the vdev-X entry is created async by dom0 watching on
event.
So how the tools could read back and call assign device again.
Perhaps by using a xenstore watch on that node to wait for the
assignment
from pciback to
On Friday 31 July 2015 01:35 PM, Ian Campbell wrote:
On Fri, 2015-07-31 at 13:16 +0530, Manish Jaggi wrote:
Secondly, the vdev-X entry is created async by dom0 watching on
event.
So how the tools could read back and call assign device again.
Perhaps by using a xenstore watch on that node to
On Fri, 2015-07-31 at 16:37 +0530, Manish Jaggi wrote:
On Friday 31 July 2015 01:35 PM, Ian Campbell wrote:
On Fri, 2015-07-31 at 13:16 +0530, Manish Jaggi wrote:
Secondly, the vdev-X entry is created async by dom0 watching on
event.
So how the tools could read back and call
On Fri, 2015-07-31 at 09:05 +0100, Ian Campbell wrote:
On Fri, 2015-07-31 at 13:16 +0530, Manish Jaggi wrote:
Secondly, the vdev-X entry is created async by dom0 watching on
event.
Stefano points out that there are, confusingly, two nodes in xenstore
relating to the virtual-SBDF.
On Thursday 30 July 2015 03:24 PM, Ian Campbell wrote:
On Wed, 2015-07-29 at 15:07 +0530, Manish Jaggi wrote:
On Monday 06 July 2015 03:50 PM, Ian Campbell wrote:
On Mon, 2015-07-06 at 15:36 +0530, Manish Jaggi wrote:
On Monday 06 July 2015 02:41 PM, Ian Campbell wrote:
On Sun, 2015-07-05
On Thu, 2015-07-30 at 18:21 +0530, Manish Jaggi wrote:
On Thursday 30 July 2015 03:24 PM, Ian Campbell wrote:
On Wed, 2015-07-29 at 15:07 +0530, Manish Jaggi wrote:
On Monday 06 July 2015 03:50 PM, Ian Campbell wrote:
On Mon, 2015-07-06 at 15:36 +0530, Manish Jaggi wrote:
On
On Wed, 2015-07-29 at 15:07 +0530, Manish Jaggi wrote:
On Monday 06 July 2015 03:50 PM, Ian Campbell wrote:
On Mon, 2015-07-06 at 15:36 +0530, Manish Jaggi wrote:
On Monday 06 July 2015 02:41 PM, Ian Campbell wrote:
On Sun, 2015-07-05 at 11:25 +0530, Manish Jaggi wrote:
On Monday
On Monday 06 July 2015 03:50 PM, Ian Campbell wrote:
On Mon, 2015-07-06 at 15:36 +0530, Manish Jaggi wrote:
On Monday 06 July 2015 02:41 PM, Ian Campbell wrote:
On Sun, 2015-07-05 at 11:25 +0530, Manish Jaggi wrote:
On Monday 29 June 2015 04:01 PM, Julien Grall wrote:
Hi Manish,
On
Hi Manish,
On 22/07/2015 06:41, Manish Jaggi wrote:
Can we keep this open and for now till there is agreement make
requesterid = bdf.
If you are ok, I will update and send Draft 3.
I think we can make an agreement on we are able to find a requesterID
based on the BDF but not that requesterID
On Tuesday 14 July 2015 11:31 PM, Stefano Stabellini wrote:
On Tue, 14 Jul 2015, Julien Grall wrote:
Hi Stefano,
On 14/07/2015 18:46, Stefano Stabellini wrote:
Linux provides a function (pci_for_each_dma_alias) which will return a
requester ID for a given PCI device. It appears that the BDF
On Tue, 7 Jul 2015, Ian Campbell wrote:
On Tue, 2015-07-07 at 14:16 +0530, Manish Jaggi wrote:
As asked you in the previous mail, can you please prove it? The
function used to get the requester ID (pci_for_each_dma_alias) is more
complex than a simple return sbdf.
I am not sure what
On Tue, 14 Jul 2015, Stefano Stabellini wrote:
On Thu, 9 Jul 2015, Julien Grall wrote:
Hi Manish,
On 09/07/2015 08:13, Manish Jaggi wrote:
If this was a domctl there might be scope for accepting an
implementation which made assumptions such as sbdf == deviceid. However
I'd
Hi Stefano,
On 14/07/2015 18:46, Stefano Stabellini wrote:
Linux provides a function (pci_for_each_dma_alias) which will return a
requester ID for a given PCI device. It appears that the BDF (the 's' of sBDF
is only internal to Linux and not part of the hardware) is equal to the
requester ID on
On Thu, 9 Jul 2015, Julien Grall wrote:
Hi Manish,
On 09/07/2015 08:13, Manish Jaggi wrote:
If this was a domctl there might be scope for accepting an
implementation which made assumptions such as sbdf == deviceid. However
I'd still like to see this topic given proper treatment in
On Tue, 14 Jul 2015, Julien Grall wrote:
Hi Stefano,
On 14/07/2015 18:46, Stefano Stabellini wrote:
Linux provides a function (pci_for_each_dma_alias) which will return a
requester ID for a given PCI device. It appears that the BDF (the 's' of
sBDF
is only internal to Linux and
On Thu, Jul 9, 2015 at 7:27 PM, Julien Grall julien.gr...@citrix.com wrote:
On 09/07/2015 12:30, Manish Jaggi wrote:
On Thursday 09 July 2015 01:38 PM, Julien Grall wrote:
On 09/07/2015 08:13, Manish Jaggi wrote:
If this was a domctl there might be scope for accepting an
implementation
On 09/07/2015 12:30, Manish Jaggi wrote:
On Thursday 09 July 2015 01:38 PM, Julien Grall wrote:
On 09/07/2015 08:13, Manish Jaggi wrote:
If this was a domctl there might be scope for accepting an
implementation which made assumptions such as sbdf == deviceid. However
I'd still like to see
On Tuesday 07 July 2015 04:54 PM, Ian Campbell wrote:
On Tue, 2015-07-07 at 14:16 +0530, Manish Jaggi wrote:
As asked you in the previous mail, can you please prove it? The
function used to get the requester ID (pci_for_each_dma_alias) is more
complex than a simple return sbdf.
I am not sure
Hi Manish,
On 09/07/2015 08:13, Manish Jaggi wrote:
If this was a domctl there might be scope for accepting an
implementation which made assumptions such as sbdf == deviceid. However
I'd still like to see this topic given proper treatment in the design
and not just glossed over with this is
On Thursday 09 July 2015 01:38 PM, Julien Grall wrote:
Hi Manish,
On 09/07/2015 08:13, Manish Jaggi wrote:
If this was a domctl there might be scope for accepting an
implementation which made assumptions such as sbdf == deviceid. However
I'd still like to see this topic given proper
On Tuesday 07 July 2015 01:48 PM, Julien Grall wrote:
Hi Manish,
On 07/07/2015 08:10, Manish Jaggi wrote:
On Monday 06 July 2015 05:15 PM, Julien Grall wrote:
On 06/07/15 12:09, Manish Jaggi wrote:
On Monday 06 July 2015 04:13 PM, Julien Grall wrote:
On 05/07/15 06:55, Manish Jaggi
On Monday 06 July 2015 05:15 PM, Julien Grall wrote:
On 06/07/15 12:09, Manish Jaggi wrote:
On Monday 06 July 2015 04:13 PM, Julien Grall wrote:
On 05/07/15 06:55, Manish Jaggi wrote:
4.3 Hypercall for bdf mapping notification to xen
---
#define
Hi Manish,
On 07/07/2015 08:10, Manish Jaggi wrote:
On Monday 06 July 2015 05:15 PM, Julien Grall wrote:
On 06/07/15 12:09, Manish Jaggi wrote:
On Monday 06 July 2015 04:13 PM, Julien Grall wrote:
On 05/07/15 06:55, Manish Jaggi wrote:
4.3 Hypercall for bdf mapping notification to xen
On Sun, Jul 05, 2015 at 11:25:25AM +0530, Manish Jaggi wrote:
On Monday 29 June 2015 04:01 PM, Julien Grall wrote:
Hi Manish,
On 28/06/15 19:38, Manish Jaggi wrote:
4.1 Holes in guest memory space
Holes are added in the guest memory space for mapping pci
On Tue, 2015-07-07 at 14:16 +0530, Manish Jaggi wrote:
As asked you in the previous mail, can you please prove it? The
function used to get the requester ID (pci_for_each_dma_alias) is more
complex than a simple return sbdf.
I am not sure what you would like me to prove.
As of ThunderX
On Tuesday 07 July 2015 02:16 PM, Manish Jaggi wrote:
On Tuesday 07 July 2015 01:48 PM, Julien Grall wrote:
Hi Manish,
On 07/07/2015 08:10, Manish Jaggi wrote:
On Monday 06 July 2015 05:15 PM, Julien Grall wrote:
On 06/07/15 12:09, Manish Jaggi wrote:
On Monday 06 July 2015 04:13 PM,
On 05/07/15 06:55, Manish Jaggi wrote:
4.3 Hypercall for bdf mapping notification to xen
---
#define PHYSDEVOP_map_sbdf 43
typedef struct {
u32 s;
u8 b;
u8 df;
u16 res;
} sbdf_t;
struct physdev_map_sbdf {
On Monday 06 July 2015 04:13 PM, Julien Grall wrote:
On 05/07/15 06:55, Manish Jaggi wrote:
4.3 Hypercall for bdf mapping notification to xen
---
#define PHYSDEVOP_map_sbdf 43
typedef struct {
u32 s;
u8 b;
u8 df;
On Monday 06 July 2015 02:41 PM, Ian Campbell wrote:
On Sun, 2015-07-05 at 11:25 +0530, Manish Jaggi wrote:
On Monday 29 June 2015 04:01 PM, Julien Grall wrote:
Hi Manish,
On 28/06/15 19:38, Manish Jaggi wrote:
4.1 Holes in guest memory space
Holes are added in
On Sun, 2015-07-05 at 11:25 +0530, Manish Jaggi wrote:
On Monday 29 June 2015 04:01 PM, Julien Grall wrote:
Hi Manish,
On 28/06/15 19:38, Manish Jaggi wrote:
4.1 Holes in guest memory space
Holes are added in the guest memory space for mapping pci
On 06/07/15 12:09, Manish Jaggi wrote:
On Monday 06 July 2015 04:13 PM, Julien Grall wrote:
On 05/07/15 06:55, Manish Jaggi wrote:
4.3 Hypercall for bdf mapping notification to xen
---
#define PHYSDEVOP_map_sbdf 43
typedef struct {
On Sunday 05 July 2015 11:25 AM, Manish Jaggi wrote:
On Monday 29 June 2015 04:01 PM, Julien Grall wrote:
Hi Manish,
On 28/06/15 19:38, Manish Jaggi wrote:
4.1 Holes in guest memory space
Holes are added in the guest memory space for mapping pci device's BAR
Ian Campbell Wrote:
On Mon, 2015-06-29 at 00:08 +0530, Manish Jaggi wrote:
PCI Pass-through in Xen ARM
--
Draft 2
Index
1. Background
2. Basic PCI Support in Xen ARM
2.1 pci_hostbridge and pci_hostbridge_ops
2.2 PHYSDEVOP_HOSTBRIDGE_ADD hypercall
3. Dom0 Access PCI
On Monday 29 June 2015 04:01 PM, Julien Grall wrote:
Hi Manish,
On 28/06/15 19:38, Manish Jaggi wrote:
4.1 Holes in guest memory space
Holes are added in the guest memory space for mapping pci device's BAR
regions.
These are defined in arch-arm.h
/* For 32bit */
On Mon, 2015-06-29 at 11:31 +0100, Julien Grall wrote:
Hi Manish,
On 28/06/15 19:38, Manish Jaggi wrote:
4.1 Holes in guest memory space
Holes are added in the guest memory space for mapping pci device's BAR
regions.
These are defined in arch-arm.h
Hi Manish,
On 28/06/15 19:38, Manish Jaggi wrote:
4.1 Holes in guest memory space
Holes are added in the guest memory space for mapping pci device's BAR
regions.
These are defined in arch-arm.h
/* For 32bit */
GUEST_MMIO_HOLE0_BASE, GUEST_MMIO_HOLE0_SIZE
On Mon, 2015-06-29 at 00:08 +0530, Manish Jaggi wrote:
PCI Pass-through in Xen ARM
--
Draft 2
Index
1. Background
2. Basic PCI Support in Xen ARM
2.1 pci_hostbridge and pci_hostbridge_ops
2.2 PHYSDEVOP_HOSTBRIDGE_ADD hypercall
3. Dom0 Access PCI devices
On 29/06/15 11:50, Ian Campbell wrote:
On Mon, 2015-06-29 at 11:31 +0100, Julien Grall wrote:
Hi Manish,
On 28/06/15 19:38, Manish Jaggi wrote:
4.1 Holes in guest memory space
Holes are added in the guest memory space for mapping pci device's BAR
regions.
45 matches
Mail list logo
