Re: [Xen-devel] [PATCH 09/28] ARM: GICv3 ITS: map device and LPIs to the ITS on physdev_op hypercall

[Jaggi, Manish]

On 1/31/2017 8:47 PM, Julien Grall wrote:
>
>
> On 31/01/17 14:08, Jaggi, Manish wrote:
>> Hi Julien,
>>
>> On 1/31/2017 7:16 PM, Julien Grall wrote:
>>> On 31/01/17 13:19, Jaggi, Manish wrote:
>>>> On 1/31/2017 6:13 PM, Julien Grall wrote:
>>>>> On 31/01/17 10:29, Jaggi, Manish wrote:
>>>>>>>
>>>>>>> From: Xen-devel <xen-devel-boun...@lists.xen.org> on behalf of Andre
>>>>>>> Przywara <andre.przyw...@arm.com>
>>>>>>> Sent: Tuesday, January 31, 2017 12:01 AM
>>>>>>> To: Stefano Stabellini; Julien Grall
>>>>>>> Cc: xen-de...@lists.xenproject.org; Vijay Kilari
>>>>>>> Subject: [Xen-devel] [PATCH 09/28] ARM: GICv3 ITS: map device and
>>>>>>> LPIs to the ITS on physdev_op hypercall
>>>>>>>
>>>>>> [snip]
>>>>>>>
>>>>>>>
>>>>>>>  int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>>>>>>  {
>>>>>>> +struct physdev_manage_pci manage;
>>>>>>> +u32 devid;
>>>>>>> +int ret;
>>>>>>> +
>>>>>>> +switch (cmd)
>>>>>>> +{ 
>>>>>>
>>>>>> You might alos need to  PHYSDEVOP_pci_device_add hypercall also.
>>>>>>
>>>>>>> +case PHYSDEVOP_manage_pci_add:
>>>>>>> +case PHYSDEVOP_manage_pci_remove:
>>>>>>> +if ( copy_from_guest(, arg, 1) != 0 )
>>>>>>> +return -EFAULT;
>>>>>>> +
>>>>>>> +devid = manage.bus << 8 | manage.devfn;
>>>>>>> +/* Allocate an ITS device table with space for 32 MSIs */
>>>>>>> +ret = gicv3_its_map_guest_device(hardware_domain,
>>>>>>> devid, devid, 5,
>>>>>>> + cmd ==
>>>>>>> PHYSDEVOP_manage_pci_add); 
>>>>>>
>>>>>> Based on 4.9 kernel, is the deivce ID plain sBDF or it is
>>>>>> returnedfrom of_msi_map_rid /  iort_msi_map_rid ?
>>>>>> I believe there needs to be set this as requirement on the calle of
>>>>>> hypercall. 
>>>>>
>>>>> The requirement of the hypercall is already defined and cannot be
>>>>> changed. So if it does not provide the correct information, then we
>>>>> need to find another way to get the DeviceID.
>>>>>
>>>> Do you think sbdf and device ID are same ? If you recollect your
>>>> comments last year sbdf != DeviceID.
>>>> for this series it has to be passed correctly otherwise ITS would be 
>>>> programmed incorrectly.
>>>> I suggest this series to include another way as well. 
>>>
>>> Thank you sherlock, if you had read my e-mail entirely you would have 
>>> noticed I never said sbdf == DeviceID and actually provided insight on the 
>>> problem and suggest solutions.
>>>
>> If you please read 4 lines above I wrote sbdf != DeviceID. 
>
> I think there is a miscommunication problem here. By "my e-mail" I was 
> referring to the e-mail on this thread 
> (4a8e35dc-57e5-e493-9a9a-4a91bb8e1...@arm.com). On your e-mail you implied I 
> was not aware of sbdf != DeviceID (see "Do you think sbdf and device ID are 
> same").
>
>
>>> I would recommend you to do the same in the future. It would help to get 
>>> the code much faster in Xen.
>>>
>>>>
>>>>> In case of ACPI, we should be able to get those informations from the
>>>>> IORT as the segment number is defined in the firmware tables. But for
>>>>> Device Tree, we would need DOM0 and Xen to agree on the segment number.
>>>>>
>>>> Is there any agreement hypercall used with this series ? 
>>>
>>> From xen/include/public/physdev.h
>>>
>>> struct physdev_manage_pci {
>>> /* IN */
>>> uint8_t bus;
>>> uint8_t devfn;
>>> };
>>>
>>> struct physdev_manage_pci_ext {
>>> /* IN */
>>> uint8_t bus;
>>> uint8_t devfn;
>>> unsigned is_extfn;
>>> unsigned is_virtfn;
>>> struct {
>>> uint8_t bus;
>>>   

Re: [Xen-devel] [PATCH 09/28] ARM: GICv3 ITS: map device and LPIs to the ITS on physdev_op hypercall

[Jaggi, Manish]

Hi Julien, 

On 1/31/2017 7:16 PM, Julien Grall wrote:
> On 31/01/17 13:19, Jaggi, Manish wrote:
>> On 1/31/2017 6:13 PM, Julien Grall wrote:
>>> On 31/01/17 10:29, Jaggi, Manish wrote:
>>>>>
>>>>> From: Xen-devel <xen-devel-boun...@lists.xen.org> on behalf of Andre
>>>>> Przywara <andre.przyw...@arm.com>
>>>>> Sent: Tuesday, January 31, 2017 12:01 AM
>>>>> To: Stefano Stabellini; Julien Grall
>>>>> Cc: xen-de...@lists.xenproject.org; Vijay Kilari
>>>>> Subject: [Xen-devel] [PATCH 09/28] ARM: GICv3 ITS: map device and
>>>>> LPIs to the ITS on physdev_op hypercall
>>>>>
>>>> [snip]
>>>>>
>>>>>
>>>>>  int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>>>>  {
>>>>> +struct physdev_manage_pci manage;
>>>>> +u32 devid;
>>>>> +int ret;
>>>>> +
>>>>> +switch (cmd)
>>>>> +{ 
>>>>
>>>> You might alos need to  PHYSDEVOP_pci_device_add hypercall also.
>>>>
>>>>> +case PHYSDEVOP_manage_pci_add:
>>>>> +case PHYSDEVOP_manage_pci_remove:
>>>>> +if ( copy_from_guest(, arg, 1) != 0 )
>>>>> +return -EFAULT;
>>>>> +
>>>>> +devid = manage.bus << 8 | manage.devfn;
>>>>> +/* Allocate an ITS device table with space for 32 MSIs */
>>>>> +ret = gicv3_its_map_guest_device(hardware_domain,
>>>>> devid, devid, 5,
>>>>> + cmd ==
>>>>> PHYSDEVOP_manage_pci_add); 
>>>>
>>>> Based on 4.9 kernel, is the deivce ID plain sBDF or it is
>>>> returnedfrom of_msi_map_rid /  iort_msi_map_rid ?
>>>> I believe there needs to be set this as requirement on the calle of
>>>> hypercall. 
>>>
>>> The requirement of the hypercall is already defined and cannot be
>>> changed. So if it does not provide the correct information, then we
>>> need to find another way to get the DeviceID.
>>>
>> Do you think sbdf and device ID are same ? If you recollect your
>> comments last year sbdf != DeviceID.
>> for this series it has to be passed correctly otherwise ITS would be 
>> programmed incorrectly.
>> I suggest this series to include another way as well. 
>
> Thank you sherlock, if you had read my e-mail entirely you would have noticed 
> I never said sbdf == DeviceID and actually provided insight on the problem 
> and suggest solutions.
>
If you please read 4 lines above I wrote sbdf != DeviceID.
> I would recommend you to do the same in the future. It would help to get the 
> code much faster in Xen.
>
>>
>>> In case of ACPI, we should be able to get those informations from the
>>> IORT as the segment number is defined in the firmware tables. But for
>>> Device Tree, we would need DOM0 and Xen to agree on the segment number.
>>>
>> Is there any agreement hypercall used with this series ? 
>
> From xen/include/public/physdev.h
>
> struct physdev_manage_pci {
> /* IN */
> uint8_t bus;
> uint8_t devfn;
> };
>
> struct physdev_manage_pci_ext {
> /* IN */
> uint8_t bus;
> uint8_t devfn;
> unsigned is_extfn;
> unsigned is_virtfn;
> struct {
> uint8_t bus;
> uint8_t devfn;
> } physfn;
> };
>
> Let me know how you could encode a DeviceID in those hypercalls.
>
If you please go back to your comment where you wrote "we need to find another 
way to get the DeviceID", I was referring that we should add that another way 
in this series so that correct DeviceID is programmed in ITS.
> Cheers,
>


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 09/28] ARM: GICv3 ITS: map device and LPIs to the ITS on physdev_op hypercall

[Jaggi, Manish]

Hi Julien,


On 1/31/2017 6:13 PM, Julien Grall wrote:
>
>
> On 31/01/17 10:29, Jaggi, Manish wrote:
>>>
>>> From: Xen-devel <xen-devel-boun...@lists.xen.org> on behalf of Andre 
>>> Przywara <andre.przyw...@arm.com>
>>> Sent: Tuesday, January 31, 2017 12:01 AM
>>> To: Stefano Stabellini; Julien Grall
>>> Cc: xen-de...@lists.xenproject.org; Vijay Kilari
>>> Subject: [Xen-devel] [PATCH 09/28] ARM: GICv3 ITS: map device and 
>>> LPIs to the ITS on physdev_op hypercall
>>>
>> [snip]
>>>
>>>
>>>  int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>>  {
>>> +struct physdev_manage_pci manage;
>>> +u32 devid;
>>> +int ret;
>>> +
>>> +switch (cmd)
>>> +{
>>
>> You might alos need to  PHYSDEVOP_pci_device_add hypercall also.
>>
>>> +case PHYSDEVOP_manage_pci_add:
>>> +case PHYSDEVOP_manage_pci_remove:
>>> +if ( copy_from_guest(, arg, 1) != 0 )
>>> +return -EFAULT;
>>> +
>>> +devid = manage.bus << 8 | manage.devfn;
>>> +/* Allocate an ITS device table with space for 32 MSIs */
>>> +ret = gicv3_its_map_guest_device(hardware_domain, 
>>> devid, devid, 5,
>>> + cmd == 
>>> PHYSDEVOP_manage_pci_add);
>>
>> Based on 4.9 kernel, is the deivce ID plain sBDF or it is 
>> returnedfrom of_msi_map_rid /  iort_msi_map_rid ?
>> I believe there needs to be set this as requirement on the calle of 
>> hypercall.
>
> The requirement of the hypercall is already defined and cannot be 
> changed. So if it does not provide the correct information, then we 
> need to find another way to get the DeviceID.
>
Do you think sbdf and device ID are same ? If you recollect your 
comments last year sbdf != DeviceID.
for this series it has to be passed correctly otherwise ITS is programmed with 
wrong deviceID.
I suggest this series to include another way as well.
> In case of ACPI, we should be able to get those informations from the 
> IORT as the segment number is defined in the firmware tables. But for 
> Device Tree, we would need DOM0 and Xen to agree on the segment number.
>
Is there any agreement hypercall used with this series ?
> However, I am not sure whether we are going to need those hypercalls 
> when Xen will gain support of PCI. There are some discussion to let 
> Xen scanning the PCI devices, and therefore the hypercalls will be used.
>
> Today, the hypercall is called by Linux on ARM, but it might not be 
> the case in the future. If we decide to implement it today, it means 
> that we will not be able to remove it from Linux from compatibility 
> reasons.
>
> So I would be more in favor of having a per-platform list of devices 
> to support for the time being. So we can get GICv3 ITS working with 
> Device Tree until Xen gain support of PCI. Stefano, Andre, any opinions?
> Cheers,
>


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 09/28] ARM: GICv3 ITS: map device and LPIs to the ITS on physdev_op hypercall

[Jaggi, Manish]

Hi Julien,


On 1/31/2017 6:13 PM, Julien Grall wrote:
>
>
> On 31/01/17 10:29, Jaggi, Manish wrote:
>>>
>>> From: Xen-devel <xen-devel-boun...@lists.xen.org> on behalf of Andre 
>>> Przywara <andre.przyw...@arm.com>
>>> Sent: Tuesday, January 31, 2017 12:01 AM
>>> To: Stefano Stabellini; Julien Grall
>>> Cc: xen-de...@lists.xenproject.org; Vijay Kilari
>>> Subject: [Xen-devel] [PATCH 09/28] ARM: GICv3 ITS: map device and 
>>> LPIs to the ITS on physdev_op hypercall
>>>
>> [snip]
>>>
>>>
>>>  int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>>  {
>>> +struct physdev_manage_pci manage;
>>> +u32 devid;
>>> +int ret;
>>> +
>>> +switch (cmd)
>>> +{
>>
>> You might alos need to  PHYSDEVOP_pci_device_add hypercall also.
>>
>>> +case PHYSDEVOP_manage_pci_add:
>>> +case PHYSDEVOP_manage_pci_remove:
>>> +if ( copy_from_guest(, arg, 1) != 0 )
>>> +return -EFAULT;
>>> +
>>> +devid = manage.bus << 8 | manage.devfn;
>>> +/* Allocate an ITS device table with space for 32 MSIs */
>>> +ret = gicv3_its_map_guest_device(hardware_domain, 
>>> devid, devid, 5,
>>> + cmd == 
>>> PHYSDEVOP_manage_pci_add);
>>
>> Based on 4.9 kernel, is the deivce ID plain sBDF or it is 
>> returnedfrom of_msi_map_rid /  iort_msi_map_rid ?
>> I believe there needs to be set this as requirement on the calle of 
>> hypercall.
>
> The requirement of the hypercall is already defined and cannot be 
> changed. So if it does not provide the correct information, then we 
> need to find another way to get the DeviceID.
>
Do you think sbdf and device ID are same ? If you recollect your 
comments last year sbdf != DeviceID.
for this series it has to be passed correctly otherwise ITS would be programmed 
incorrectly.
I suggest this series to include another way as well.

> In case of ACPI, we should be able to get those informations from the 
> IORT as the segment number is defined in the firmware tables. But for 
> Device Tree, we would need DOM0 and Xen to agree on the segment number.
>
Is there any agreement hypercall used with this series ?
> However, I am not sure whether we are going to need those hypercalls 
> when Xen will gain support of PCI. There are some discussion to let 
> Xen scanning the PCI devices, and therefore the hypercalls will be used.
>
> Today, the hypercall is called by Linux on ARM, but it might not be 
> the case in the future. If we decide to implement it today, it means 
> that we will not be able to remove it from Linux from compatibility 
> reasons.
>
> So I would be more in favor of having a per-platform list of devices 
> to support for the time being. So we can get GICv3 ITS working with 
> Device Tree until Xen gain support of PCI. Stefano, Andre, any opinions?
> Cheers,
>


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 09/28] ARM: GICv3 ITS: map device and LPIs to the ITS on physdev_op hypercall

[Jaggi, Manish]

Hi Andre,
>
>From: Xen-devel  on behalf of Andre Przywara 
>
>Sent: Tuesday, January 31, 2017 12:01 AM
>To: Stefano Stabellini; Julien Grall
>Cc: xen-de...@lists.xenproject.org; Vijay Kilari
>Subject: [Xen-devel] [PATCH 09/28] ARM: GICv3 ITS: map device and LPIs to the 
>ITS on physdev_op hypercall
>    
[snip]
> 
> 
> int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> {
>+    struct physdev_manage_pci manage;
>+    u32 devid;
>+    int ret;
>+
>+    switch (cmd)
>+    {

You might alos need to  PHYSDEVOP_pci_device_add hypercall also. 

>+    case PHYSDEVOP_manage_pci_add:
>+    case PHYSDEVOP_manage_pci_remove:
>+    if ( copy_from_guest(, arg, 1) != 0 )
>+    return -EFAULT;
>+
>+    devid = manage.bus << 8 | manage.devfn;
>+    /* Allocate an ITS device table with space for 32 MSIs */
>+    ret = gicv3_its_map_guest_device(hardware_domain, devid, devid, 5,
>+ cmd == PHYSDEVOP_manage_pci_add);

Based on 4.9 kernel, is the deivce ID plain sBDF or it is returnedfrom 
of_msi_map_rid /  iort_msi_map_rid ?
I believe there needs to be set this as requirement on the calle of hypercall. 
As sbdf and deviceID returned from msi_map calls might not be same.

>+
>+    return ret;
>+    }
>+
> gdprintk(XENLOG_DEBUG, "PHYSDEVOP cmd=%d: not implemented\n", cmd);
> return -ENOSYS;
> }
>-- 
>2.9.0
>

-Manish


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

[Jaggi, Manish]

Hi Julien,


From: Julien Grall <julien.gr...@linaro.org>
Sent: Thursday, December 29, 2016 10:33 PM
To: Jaggi, Manish; xen-devel; Stefano Stabellini
Cc: Edgar Iglesias (edgar.igles...@xilinx.com); Steve Capper; Punit Agrawal; 
Wei Chen; Campbell Sean; Shanker Donthineni; Jiandi An; Roger Pau Monné; 
alistair.fran...@xilinx.com; Kapoor, Prasun; Nair, Jayachandran
Subject: Re: [early RFC] ARM PCI Passthrough design document



On 29/12/2016 14:16, Jaggi, Manish wrote:
> Hi Julien,

Hello Manish,

>
> Wouldnt it be better if the design proposed by cavium be extended by
> discussions and comeup with an agreeable to all design.

As I mentioned in my mail, this design is a completely different
approach (emulation vs PV).
[manish] It would have been better if you had suggested in the design posted by 
me, that the following 1.2.3 points would change.
Since a design is already been posted, it makes sense to focus on that and 
reach a common understanding. And is a bit _rude_.

This is a distinct proposal because
emulation vs PV impact a lot the overall design.

[manish] There are 3 aspects
a. changes needed in Xen / Dom0 for
- registering of pci host controller driver in xen
- mapping between sdbf and streamid
- adding enumerated pci devices to xen dom0
- making devices use SMMU in dom0

b.1 How domU is assigned  a PCI device.
b.2 How a domU PCI driver reads configuration space
I think only at this point PV vs emulation matters. As of now the frontend 
backend driver allow reading PCI space.
Adding an its node in domU device tree will make traps to xen for ITS emulation.

c. DT vs ACPI
I havent seen in your design how it is captured to support both dt and acpi 
together.
A good appraoch would be to extend Draft5 with ACPI.

> I didnt see any comments on the one I posted.

Whilst I haven't commented on your design document, I have read
carefully your last version of the design. But even after 5 version and
nearly 2 years of work this is still DT and ITS focused.
[manish] Two reasons for  that
a) PCI driver in linux was evolving and only after msi-map we have a way to map 
sbdf with steamID
b) Market interest in Xen ARM64

No words about
interrupt legacy,
[Manish] At the time of Xen dev summit 2015 we agreed to keep legacy as a 
secondary item, so that we can get something in xen for PCI pt.
no words about ACPI... And as you can see in this
draft, ACPI will have an impact on the overall.

Some part of this design document is based on all the discussion we had
over last year on your design. However, most of the comments have not
been addressed despite the fact they have been repeated multiple time by
various reviewers. For example the bus number has not been added
PHYSDEVOP_pci_host_bridge_add as requested in one of the first version
of the design.
[manish] I disagree, since the same pci node is passed to dom0 and xen and it 
has a bus-nr property
there is no need for it.
Moreover this hypercall was suggested by Ian and the requirement was to only 
add segno so that xen and dom0 bind to a PCI RC.

> Putting an altogether new design without commenting on the one posted a
> month back, might not be a right approach

Speaking for myself, my bandwidth is limited and I am going to
prioritize review on series where my comments have been addressed.

[manish] All have limited bandwidth and priorities are loaded.  Your comments 
are dully taken care of in the document, espcially sbdf-streamID mapping.
I would have appreciated that you could have sent a draft 6 with your additions 
so that a good design be produced.

Regards,

--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

[Jaggi, Manish]

Hi Julien,


Wouldnt it be better if the design proposed by cavium be extended by 
discussions and comeup with an agreeable to all design.

I didnt see any comments on the one I posted.

Putting an altogether new design without commenting on the one posted a month 
back, might not be a right approach



Regards,
Manish Jaggi

From: Julien Grall <julien.gr...@linaro.org>
Sent: Thursday, December 29, 2016 7:34:15 PM
To: xen-devel; Stefano Stabellini
Cc: Edgar Iglesias (edgar.igles...@xilinx.com); Steve Capper; Punit Agrawal; 
Wei Chen; Campbell Sean; Shanker Donthineni; Jiandi An; Jaggi, Manish; Roger 
Pau Monné; alistair.fran...@xilinx.com
Subject: [early RFC] ARM PCI Passthrough design document

Hi all,

The document below is an early version of a design
proposal for PCI Passthrough in Xen. It aims to
describe from an high level perspective the interaction
with the different subsystems and how guest will be able
to discover and access PCI.

I am aware that a similar design has been posted recently
by Cavium (see [1]), however the approach to expose PCI
to guest is different. We have request to run unmodified
baremetal OS on Xen, a such guest would directly
access the devices and no PV drivers will be used.

That's why this design is based on emulating a root controller.
This also has the advantage to have the VM interface as close
as baremetal allowing the guest to use firmware tables to discover
the devices.

Currently on ARM, Xen does not have any knowledge about PCI devices.
This means that IOMMU and interrupt controller (such as ITS)
requiring specific configuration will not work with PCI even with
DOM0.

The PCI Passthrough work could be divided in 2 phases:
* Phase 1: Register all PCI devices in Xen => will allow
   to use ITS and SMMU with PCI in Xen
* Phase 2: Assign devices to guests

This document aims to describe the 2 phases, but for now only phase
1 is fully described.

I have sent the design document to start to gather feedback on
phase 1.

Cheers,

[1] https://lists.xen.org/archives/html/xen-devel/2016-12/msg00224.html


% PCI pass-through support on ARM
% Julien Grall <julien.gr...@linaro.org>
% Draft A

# Preface

This document aims to describe the components required to enable PCI
passthrough on ARM.

This is an early draft and some questions are still unanswered, when this is
the case the text will contain XXX.

# Introduction

PCI passthrough allows to give control of physical PCI devices to guest. This
means that the guest will have full and direct access to the PCI device.

ARM is supporting one kind of guest that is exploiting as much as possible
virtualization support in hardware. The guest will rely on PV driver only
for IO (e.g block, network), interrupts will come through the virtualized
interrupt controller. This means that there are no big changes required
within the kernel.

By consequence, it would be possible to replace PV drivers by assigning real
devices to the guest for I/O access. Xen on ARM would therefore be able to
run unmodified operating system.

To achieve this goal, it looks more sensible to go towards emulating the
host bridge (we will go into more details later). A guest would be able
to take advantage of the firmware tables and obviating the need for a specific
driver for Xen.

Thus in this document we follow the emulated host bridge approach.

# PCI terminologies

Each PCI device under a host bridge is uniquely identified by its Requester ID
(AKA RID). A Requester ID is a triplet of Bus number, Device number, and
Function.

When the platform has multiple host bridges, the software can add fourth
number called Segment to differentiate host bridges. A PCI device will
then uniquely by segment:bus:device:function (AKA SBDF).

So given a specific SBDF, it would be possible to find the host bridge and the
RID associated to a PCI device.

# Interaction of the PCI subsystem with other subsystems

In order to have a PCI device fully working, Xen will need to configure
other subsystems subsytems such as the SMMU and the Interrupt Controller.

The interaction expected between the PCI subsystem and the other is:
* Add a device
* Remove a device
* Assign a device to a guest
* Deassign a device from a guest

XXX: Detail the interaction when assigning/deassigning device

The following subsections will briefly describe the interaction from an
higher level perspective. Implementation details (callback, structure...)
is out of scope.

## SMMU

The SMMU will be used to isolate the PCI device when accessing the memory
(for instance DMA and MSI Doorbells). Often the SMMU will be configured using
a StreamID (SID) that can be deduced from the RID with the help of the firmware
tables (see below).

Whilst in theory all the memory transaction issued by a PCI device should
go through the SMMU, on certain platforms some of the memory transaction may
not reach t

Re: [Xen-devel] Xen: ARM: Support for mapping ECAM PCIe Config Space Specified In Static ACPI Table

[Jaggi, Manish]

Hi,

>On 16/12/2016 15:49, Julien Grall wrote:
>> On 14/12/16 08:00, Jiandi An wrote:
>>> Xen currently doesn't map ECAM space specified in static ACPI table.
>>> Seeking opinion on how this should be handled properly.
>>> Each root complex ECAM region takes up 64K 4K pages (256MB).
>>> For some platforms there might be multiple root complexes.
>>> Is the plan to map all at once?Julien has mentioned support
>>> for mapping ECAM may come when support for PCI passthrough is
>>> added, is that right? What mechanism will it be? Will Xen or
>>> dom0 be the one that parses the staic ACPI tables and map the ECAM space?
>>
>> For performance reason, each ECAM region would need to be mapped at
>> once, so the stage-2 page table could take advantage of superpage (it
>> will mostly be 2MB).
>>
>> Now, I don't think Xen should map the ECAM region in stage-2 before
>> hand. All the regions may not be described in the MCFG and I would like
>> to see a generic solution.
>>
>> Looking at the code (see pci_create_ecam_create in drivers/pci/ecam.c),
>> ioremap is used. I believe the problem is the same for the 2 other
>> threads you sent ( [1] and [2]).
>>
>> So it might be good to look at hooking up a call to
>> XENMEM_add_to_physmap_range in ioremap.
>>
>> Any opinions?
>
>I thought a bit more about it and I realized we need to be cautious on 
>how to proceed here.
>
>DOM0 will have a mix of real devices and emulated devices (e.g some part 
>of the GIC). For the emulated devices, DOM0 should not call 
>XENMEM_add_to_physmap_range. However, DOM0 is not aware what is emulated 
>or not, so even the current approach (hooking up in platform device) 
>seems fragile. We rely on Xen to say "this region cannot be mapped".
>
 Why not add support for parsing ACPI tables in Xen, from linux,  as we parse 
dt.

-manish


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4

[Jaggi, Manish]

On Thursday 10 September 2015 06:42 AM, Julien Grall wrote:
> Hi Manish,
Hi Julien, sorry for late response..
>
> On 13/08/2015 10:42, Manish Jaggi wrote:
>>   3.2.Mapping between streamID - deviceID - pci sbdf - requesterID
>> -
>>   For a simpler case all should be equal to BDF. But there are some 
>> devices
>>   that use the wrong requester ID for DMA transactions. Linux kernel has
>> PCI
>>   quirks for these. How the same be implemented in Xen or a diffrent
>> approach
>>   has to be taken is TODO here.
>>
>>   Till that time, for basic implementation it is assumed that all are 
>> equal
>>   to BDF.
>
> Back to this streamID = DeviceID = requestID = SBDF again...
>
> I've just found a patch for Linux send by one of your colleague about 
> tweaking the requesterID for thunder-X board (See [1]). The most 
> interesting bits are:
>
> static u32 pci_requester_id_ecam(struct pci_dev *dev)
> {
> return (((pci_domain_nr(dev->bus) >> 2) << 19) |
> ((pci_domain_nr(dev->bus) % 4) << 16) |
> (dev->bus->number << 8) | dev->devfn);
> }
>
> static u32 thunder_pci_requester_id(struct pci_dev *dev, u16 alias)
> {
> int ret;
>
> ret = thunder_pem_requester_id(dev);
> if (ret >= 0)
> return (u32)ret;
>
> return pci_requester_id_ecam(dev);
> }
>
> Which is then used to override the default function used by ITS to 
> find the deviceID.
>
> AFAICT, this means that you can't safely assume that DeviceID == sBDF 
> even for your platform. Is that right?
Yes.
>
> If so, I'm afraid that you have to handle DeviceID != sBDF (and so on) 
> in your design doc. I.e how do you plan to get the base requester ID.
>
Right. But on our platform the requesterId is uniquely generated from 
bdf. Adding David to confirm that.
> I can see 2 different solutions:
> 1) Let DOM0 pass the first requester ID when registering the bus
>Pros:
> * Less per-platform code in Xen
>Cons:
> * Assume that the requester ID are contiguous. (Is it really a 
> cons?)
> * Still require quirk for buggy device (i.e requester ID not 
> correct)
> 2) Do it in Xen
>Pros:
> * We are not relying on DOM0 giving the requester ID
> => Not assuming contiguous requester ID
> Cons:
> * Per PCI bridge code to handle the mapping
>
  We can have (3) that when PHYSDEVOP_pci_add_device is called the sbdf 
and requesterID both are passed in hypercall.
> Regards,
>
> [1] https://lkml.org/lkml/2015/7/15/703
>
>
>


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

Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4

[Jaggi, Manish]

How about having  a short discussion on Monday during Xen Summit to discuss on 
the points.
We have a talk tuesday morning and I would update it based on the monday 
discussion.

Regards,
Manish Jaggi


From: xen-devel-boun...@lists.xen.org xen-devel-boun...@lists.xen.org on 
behalf of Stefano Stabellini stefano.stabell...@eu.citrix.com
Sent: Friday, August 14, 2015 9:08 PM
To: Jan Beulich
Cc: prasun.kap...@cavium.com; Ian Campbell; stefano.stabell...@eu.citrix.com; 
Jaggi, Manish; Kumar, Vijaya; Julien Grall; Xen Devel
Subject: Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4

On Thu, 13 Aug 2015, Jan Beulich wrote:
 On 13.08.15 at 11:42, mja...@caviumnetworks.com wrote:
2.1pci_hostbridge and pci_hostbridge_ops

  -
The init function in the PCI host driver calls to register hostbridge
callbacks:
 
int pci_hostbridge_register(pci_hostbridge_t *pcihb);
 
struct pci_hostbridge_ops {
u32 (*pci_conf_read)(struct pci_hostbridge*, u32 bus, u32 devfn,
u32 reg, u32 bytes);
void (*pci_conf_write)(struct pci_hostbridge*, u32 bus, u32 devfn,
u32 reg, u32 bytes, u32 val);
};
 
struct pci_hostbridge{
u32 segno;
paddr_t cfg_base;
paddr_t cfg_size;
struct dt_device_node *dt_node;
struct pci_hostbridge_ops ops;
struct list_head list;
};
 
A PCI conf_read function would internally be as follows:
u32 pcihb_conf_read(u32 seg, u32 bus, u32 devfn,u32 reg, u32 bytes)
{
pci_hostbridge_t *pcihb;
list_for_each_entry(pcihb, pci_hostbridge_list, list)
{
if(pcihb-segno == seg)
return pcihb-ops.pci_conf_read(pcihb, bus, devfn, reg, bytes);
}
return -1;
}

 Which implies 1 segment per host bridge, which doesn't seem too
 nice to me: I can't see why a bridge might not cover more than one
 segment, and I also can't see why you shouldn't be able to put
 multiple bridges in the same segment when the number of busses
 they have is small.

1 segment per host bridge is an ARM IORT requirement
(http://infocenter.arm.com/help/topic/com.arm.doc.den0049a/DEN0049A_IO_Remapping_Table.pdf).
It is also pretty much in the spirit of the MCFG table, even though it
is not spelled out so clearly there. I know that we are talking about
device tree here, but I think it is safe to keep the same constraint.

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

Re: [Xen-devel] PCI Passthrough ARM Design : Draft1

[Jaggi, Manish]

Hi Ian/Stefano,
As discussed in the call I have sent the design.
Didn't got any feedback on this.

Regards,
Manish Jaggi


From: xen-devel-boun...@lists.xen.org xen-devel-boun...@lists.xen.org on 
behalf of Manish Jaggi mja...@caviumnetworks.com
Sent: Monday, June 8, 2015 12:52:55 AM
To: xen-devel@lists.xen.org; Ian Campbell; Stefano Stabellini; Vijay Kilari; 
Kulkarni, Ganapatrao; Kumar, Vijaya; Kapoor, Prasun
Subject: [Xen-devel] PCI Passthrough ARM Design : Draft1

PCI Pass-through in Xen ARM
--

Index
1. Background
2. Basic PCI Support in Xen ARM
2.1 pci_hostbridge and pci_hostbridge_ops
2.2 PHYSDEVOP_pci_host_bridge_add hypercall
3. Dom0 Access PCI devices
4. DomU assignment of PCI device
5. NUMA and PCI passthrough
6. DomU pci device attach flow

1. Background of PCI passthrough

Passthrough refers to assigning a pci device to a guest domain (domU)
such that
the guest has full control over the device.The MMIO space and interrupts
are
managed by the guest itself, close to how a bare kernel manages a device.

Device's access to guest address space needs to be isolated and
protected. SMMU
(System MMU - IOMMU in ARM) is programmed by xen hypervisor to allow device
access guest memory for data transfer and sending MSI/X interrupts. In
case of
MSI/X  the device writes to GITS (ITS address space) Interrupt Translation
Register.

2. Basic PCI Support for ARM

The apis to read write from pci configuration space are based on
segment:bdf.
How the sbdf is mapped to a physical address is under the realm of the pci
host controller.

ARM PCI support in Xen, introduces pci host controller similar to what
exists
in Linux. Each drivers registers callbacks, which are invoked on
matching the
compatible property in pci device tree node.

2.1:
The init function in the pci host driver calls to register hostbridge
callbacks:
int pci_hostbridge_register(pci_hostbridge_t *pcihb);

struct pci_hostbridge_ops {
 u32 (*pci_conf_read)(struct pci_hostbridge*, u32 bus, u32 devfn,
 u32 reg, u32 bytes);
 void (*pci_conf_write)(struct pci_hostbridge*, u32 bus, u32 devfn,
 u32 reg, u32 bytes, u32 val);
};

struct pci_hostbridge{
 u32 segno;
 paddr_t cfg_base;
 paddr_t cfg_size;
 struct dt_device_node *dt_node;
 struct pci_hostbridge_ops ops;
 struct list_head list;
};

A pci conf read function would internally be as follows:
u32 pcihb_conf_read(u32 seg, u32 bus, u32 devfn,u32 reg, u32 bytes)
{
 pci_hostbridge_t *pcihb;
 list_for_each_entry(pcihb, pci_hostbridge_list, list)
 {
 if(pcihb-segno == seg)
 return pcihb-ops.pci_conf_read(pcihb, bus, devfn, reg, bytes);
 }
 return -1;
}

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:

#define PHYSDEVOP_pci_host_bridge_add44
struct physdev_pci_host_bridge_add {
 /* IN */
 uint16_t seg;
 uint64_t cfg_base;
 uint64_t cfg_size;
};

This hypercall is invoked before dom0 invokes the PHYSDEVOP_pci_device_add
hypercall. The handler code invokes to update segment number in
pci_hostbridge:

int pci_hostbridge_setup(uint32_t segno, uint64_t cfg_base, uint64_t
cfg_size);

Subsequent calls to pci_conf_read/write are completed by the
pci_hostbridge_ops
of the respective pci_hostbridge.

3. Dom0 access PCI device
-
As per the design of xen hypervisor, dom0 enumerates the PCI devices.
For each
device the MMIO space has to be mapped in the Stage2 translation for
dom0. For
dom0 xen maps the ranges in pci nodes in stage 2 translation.

GITS_ITRANSLATER space (4k( must be programmed in Stage2 translation so
that MSI/X
must work. This is done in vits intitialization in dom0/domU.

4. DomU access / assignment PCI device
--
When a device is attached to a domU, provision has to be made such that
it can
access the MMIO space of the device and xen is able to identify the mapping
between guest bdf and system bdf. Two hypercalls are introduced

#define PHYSDEVOP_map_mmio  40
#define PHYSDEVOP_unmap_mmio41
struct physdev_map_mmio {
 /* IN */
 uint64_t addr;
 uint64_t size;
};
Xen adds the mmio space to the stage2 translation for domU. The
restrction is
that xen creates 1:1 mapping of the MMIO address.

#define PHYSDEVOP_map_sbdf  43
struct physdev_map_sbdf {
 int domain_id;
 int sbdf_s;
 int sbdf_b;
 int sbdf_d;
 int sbdf_f;

 int gsbdf_s;
 int gsbdf_b;
 

Re: [Xen-devel] [PATCH v1 3/3] xen/arm: smmu: Renaming struct iommu_domain *domain to, struct iommu_domain *iommu_domain

[Jaggi, Manish]

Hi Julien/Ian,

From: Julien Grall julien.grall@gmail.com
Sent: Tuesday, April 14, 2015 5:16 PM
To: Ian Campbell; Julien Grall
Cc: prasun.kap...@cavium.com; Stefano Stabellini; Jaggi, Manish; Julien Grall; 
Xen Devel; Kumar, Vijaya
Subject: Re: [Xen-devel] [PATCH v1 3/3] xen/arm: smmu: Renaming struct 
iommu_domain *domain to, struct iommu_domain *iommu_domain

Hi Ian,

On 14/04/15 12:15, Ian Campbell wrote:
 On Mon, 2015-04-06 at 16:15 +0200, Julien Grall wrote:
 Hi Ian,

 On 01/04/2015 10:30, Ian Campbell wrote:
 On Tue, 2015-03-31 at 17:48 +0100, Stefano Stabellini wrote:
 If it helps we could add a couple of comments on top of the structs in
 smmu.c to explain the meaning of the fields, like:


 /* iommu_domain, not to be confused with a Xen domain */

 I was going to suggest something similar but more expansive, i.e. a
 table of them all in one place (i.e. at the top of the file) for ease of
 referencing:

 Struct NameWhat Wherefrom Normally found in
 -
 iommu_domain   IOMMU ContextLinux d-arch.blah
 arch_smmu_xen_device   Device specific  Xen   device-arch.blurg

 The actual name of the structure is arm_smmu_xen_device not
 arch_smmu_xen_device. Did you suggest to rename the name?

 No, I was just suggesting someone should create such a table with actual
 current information, instead of made up filler, in it. (you'll notice
 that there is, hopefully, no field blah in d-arch either nor
 device-arch.blurg in the tree either and please don't rename the field
 to match those ;-)).

Thanks for the clarification. I wanted a confirmation because on another
thread [1], Manish said you were suggested a new name.

I think a table describing the different structure would be nice.
[manish] Table is indeed a good option, but I think changing the name of 
arm_smmu_xen_device to something like arch_smmu_device make more sense as 
arm_smmu_xen_device and arm_smmu_device are not differentiable just by name. 

Regards,

[1]
http://lists.xenproject.org/archives/html/xen-devel/2015-04/msg00473.html

--
Julien Grall

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

Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)

[Jaggi, Manish]

From: xen-devel-boun...@lists.xen.org xen-devel-boun...@lists.xen.org on 
behalf of wei.l...@citrix.com wei.l...@citrix.com
Sent: Tuesday, April 14, 2015 3:57 PM
To: xen-de...@lists.xenproject.org; edmund.h.wh...@intel.com; 
xumengpa...@gmail.com; dgol...@seas.upenn.edu; jtwea...@hawaii.edu; 
oleksandr.dmytrys...@globallogic.com; cheg...@amazon.de; 
daniel.ki...@oracle.com; george.dun...@eu.citrix.com; 
rcojoc...@bitdefender.com; chao.p.p...@linux.intel.com; feng...@intel.com; 
dario.faggi...@citrix.com; ross.lagerw...@citrix.com; 
malcolm.cross...@citrix.com; kai.hu...@linux.intel.com; tiejun.c...@intel.com; 
boris.ostrov...@oracle.com; elena.ufimts...@oracle.com; 
tamas.leng...@zentific.com; Kumar, Vijaya; parth.di...@linaro.org; 
ian.campb...@citrix.com; andrii.tseglyts...@globallogic.com; 
suravee.suthikulpa...@amd.com; julien.gr...@linaro.org; 
manishjaggi@gmail.com; vijay.kil...@gmail.com; vkuzn...@redhat.com; 
fabio.fant...@m2r.biz; ian.jack...@eu.citrix.com; dsl...@verizon.com; 
cy...@suse.com; jgr...@suse.com; o...@aepfle.de; we...@cn.fujitsu.com; 
guijianf...@cn.fujitsu.com; andrew.coop...@citrix.com; david.vra...@citrix.com; 
bob@oracle.com; yan...@cn.fujitsu.com; roger@citrix.com; 
konrad.w...@oracle.com; eshel...@pobox.com; wei.l...@citrix.com; 
eddie.d...@intel.com; julien.gr...@citrix.com; anthony.per...@citrix.com; 
tal...@gmail.com; artem.myga...@globallogic.com; robert...@intel.com; 
wei.l...@citrix.com; edgar.igles...@gmail.com; frediano.zig...@huawei.com; 
ard.biesheu...@linaro.org; quan...@intel.com; 
oleksandr.tyshche...@globallogic.com
Subject: [Xen-devel] Xen 4.6 Development Update (three months reminder)

Hi all

We are now three months into 4.6 development window. This is an email to keep
track of all the patch series I gathered. It is by no means complete and / or
acurate. Feel free to reply this email with new projects or correct my
misunderstanding.

= Timeline =

We are planning on a 9-month release cycle, but we could also release a bit
earlier if everything goes well (no blocker, no critical bug).

* Development start: 6 Jan 2015
=== We are here ===
* Feature Freeze: 10 Jul 2015
* RCs: TBD
* Release Date: 9 Oct 2015 (could release earlier)

The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable.

Bug-fixes, if Acked-by by maintainer, can go anytime before the First
RC. Later on we will need to figure out the risk of regression/reward
to eliminate the possiblity of a bug introducing another bug.

= Prognosis =

The states are: none - fair - ok - good - done

none - nothing yet
fair - still working on it, patches are prototypes or RFC
ok   - patches posted, acting on review
good - some last minute pieces
done - all done, might have bugs

= Bug Fixes =

Bug fixes can be checked in without a freeze exception throughout the
freeze, unless the maintainer thinks they are particularly high
risk.  In later RC's, we may even begin rejecting bug fixes if the
broken functionality is small and the risk to other functionality is
high.

Document changes can go in anytime if the maintainer is OK with it.

These are guidelines and principles to give you an idea where we're coming
from; if you think there's a good reason why making an exception for you will
help us make Xen better than not doing so, feel free to make your case.

== Hypervisor ==

*  Alternate p2m: support multiple copies of host p2m (ok)
  -  Ed White

*  Improve RTDS scheduler (none)
  -  Dagaen Golomb, Meng Xu

*  Credit2: introduce per-vcpu hard and soft affinity (good)
  -  Justin T. Weaver

*  sndif: add API for para-virtual sound (fair)
   v7 posted
  -  Oleksandr Dmytryshyn

*  gnttab: improve scalability (good)
   v5 posted
  -  Christoph Egger

*  Display IO topology when PXM data is available (good)
   v3 posted
  -  Boris Ostrovsky

*  Xen multiboot2-EFI support (fair)
   See http://lists.xen.org/archives/html/xen-devel/2013-05/msg02281.html
   RFC posted
  -  Daniel Kiper

*  Credit2 production ready (none)
   cpu pinning, numa affinity and cpu reservation
  -  George Dunlap

*  VM event patches (none)
   Add support for XSETBV vm_events,
   Support hybernating guests
   Support for VMCALL-based vm_events
  -  Razvan Cojocaru

=== Hypervisor X86 ===

*  Intel Cache Allocation Technology (good)
  -  Chao Peng

*  VT-d Posted-interrupt (PI) (none)
  -  Wu, Feng

*  HT enabled with credit has 7.9 per perf drop. (none)
   kernbench demonstrated it
   http://www.gossamer-threads.com/lists/xen/devel/339409
   This has existed since credit1 introduction.
  -  Dario Faggioli

*  Support controlling the max C-state sub-state (fair)
   v3 posted
   Hadn't see the patch reposted.
  -  Ross Lagerwall

*  IOMMU ABI for guests to map their DMA regions (fair)
  -  Malcolm Crossley

*  Intel PML (Page Modification Logging) for Xen (none)
   design doc posted
  -  Kai Huang

*  RMRR fix (fair)
   RFC posted
  -  Tiejun Chen

*  VPMU 

Re: [Xen-devel] [PATCH 0/2] Re-factoring passthrough/pci.c and adding place-holder code for ARM/PCI

[Jaggi, Manish]

Hi Julien,

From: Julien Grall julien.grall@gmail.com
Sent: Monday, April 13, 2015 3:49 PM
To: Jaggi, Manish; xen Devel; Stefano Stabellini; Julien Grall; Ian Campbell; 
Kumar, Vijaya; prasun.kap...@cavium.com
Subject: Re: [Xen-devel] [PATCH 0/2] Re-factoring passthrough/pci.c and adding 
place-holder code for ARM/PCI

Hi Manish,

On 13/04/15 08:37, Manish Jaggi wrote:
 Xen currently does not have PCI support for ARM builds. This patch set
 makes the code compilable for ARM PCI and adds places-holder code
 which would be replaced with PCI pass-through support patch series.

May I ask why you did send directly all the code to support PCI on ARM?

Without the rest it's hard to tell whether these patches make sense or not.
[Manish] As I have mentioned these two patches are only for refactoring msi 
specific  functions to x86 files and providing the constructs that make PCI ARM 
code compilable.

The code for PCI ARM is very basic in the patch and PCI passthrough code 
patches will follow in next series. Please let me know which code does not 
makes sense and I will modify it.

 Re-factor MSI Handling
 -
 There is a some x86 specific code which is found in common code:
 xen/drivers/passthrough/pci.c which needs to be re factored.

 MSI/X are configured and handled by dom0 or domU code on ARM64 and is not
 required to be part of common code. However there are functions which are
 used as part of common code and calls to these functions cannot be easily
 re factored like pci_cleanup_msi.

On x86, the hypervisor is taking care of MSI (enabling/disabling in the
config space) as long as doing sanity check on MSI used by a given domain.

How do you plan to handle it on ARM? IHMO, the MSI code is very useful
and would also help GIC MSI implement (ITS + V2M).

[manish] As we had discussed in Linaro Connect and over the mailing list MSIs 
(LPIs in ARMv8) are handled directly on ARM by the guest and hypervisor is only 
doing injection of the LPIs using GIVv3 emulation. 

FWIW, I've pointed out the same issue on the ITS series a couple of
weeks ago.

Regards,

--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/2] xen/arm: Make HAS_PCI compilable on ARM by adding place-holder code

[Jaggi, Manish]

Hi Julien,


From: xen-devel-boun...@lists.xen.org xen-devel-boun...@lists.xen.org on 
behalf of Julien Grall julien.gr...@citrix.com
Sent: Monday, April 13, 2015 4:12 PM
To: Jaggi, Manish; Xen Devel; Stefano Stabellini; Julien Grall; Ian Campbell; 
Kumar, Vijaya; prasun.kap...@cavium.com
Subject: Re: [Xen-devel] [PATCH 2/2] xen/arm: Make HAS_PCI compilable on ARM by 
adding place-holder code

Hi Manish,

On 13/04/15 08:48, Manish Jaggi wrote:
 Add ARM PCI Support
 ---
 a) Place holder functions are added for pci_conf_read/write calls.
 b) Macros dev_is_pci, pci_to_dev are implemented in
 drivers/passthrough/pci/arm code

 Signed-off-by: Manish Jaggi manish.ja...@caviumnetworks.com
 ---
  xen/arch/arm/Makefile|1 +
  xen/arch/arm/pci.c   |   60 +++
  xen/drivers/passthrough/arm/Makefile |1 +
  xen/drivers/passthrough/arm/pci.c|   88
 ++
  xen/drivers/passthrough/arm/smmu.c   |1 -
  xen/drivers/passthrough/pci.c|9 ++--
  xen/include/asm-arm/device.h |   33 +
  xen/include/asm-arm/domain.h |3 ++
  xen/include/asm-arm/pci.h|7 +--
  9 files changed, 186 insertions(+), 17 deletions(-)

[...]
 diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
 index 004aba9..68c292b 100644
 --- a/xen/drivers/passthrough/pci.c
 +++ b/xen/drivers/passthrough/pci.c
 @@ -1252,9 +1252,12 @@ static int assign_device(struct domain *d, u16
 seg, u8 bus, u8 devfn)
  /* Prevent device assign if mem paging or mem sharing have been
   * enabled for this domain */
  if ( unlikely(!need_iommu(d) 
 -(d-arch.hvm_domain.mem_sharing_enabled ||
 - d-mem_event-paging.ring_page ||
 - p2m_get_hostp2m(d)-global_logdirty)) )
 +(d-mem_event-paging.ring_page
 +#ifdef CONFIG_X86
 + || d-arch.hvm_domain.mem_sharing_enabled ||
 + p2m_get_hostp2m(d)-global_logdirty
 +#endif
 +)) )

Please avoid #ifdef CONFIG_* and introduce an arch macro. 
[Manish] ok
  return -EXDEV;

  if ( !spin_trylock(pcidevs_lock) )
 diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
 index a72f7c9..009ff0a 100644
 --- a/xen/include/asm-arm/device.h
 +++ b/xen/include/asm-arm/device.h
 @@ -6,6 +6,17 @@
  enum device_type
  {
  DEV_DT,
 +DEV_ENUMERATED,
 +};
 +
 +enum device_class
 +{
 +DEVICE_SERIAL,
 +DEVICE_IOMMU,
 +DEVICE_GIC,
 +DEVICE_PCI,
 +/* Use for error */
 +DEVICE_UNKNOWN,
  };

Why? It will be very unlikely that we have to create a structure device
for the IOMMU, GIC and SERIAL.

It would make more sense to add a DEV_PCI directly to device_type.
[manish] ok. 


  struct dev_archdata {
 @@ -16,28 +27,30 @@ struct dev_archdata {
  struct device
  {
  enum device_type type;
 +enum device_class class;
  #ifdef HAS_DEVICE_TREE
  struct dt_device_node *of_node; /* Used by drivers imported from
 Linux */
  #endif
  struct dev_archdata archdata;
 +#ifdef HAS_PCI
 +void *pci_dev;

This field is not necessary. I've added one for the DT for keeping
compatibility with Linux.
[Manish] pci_dev is not in struct device currently. Didn't get you
 I have added as It is required  for to_pci_dev call.

 +#endif

[..]

 +int dev_is_pci(device_t *dev);

This could easily be a macro.
[manish] ok


  struct device_desc {
  /* Device name */
 diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
 index 9e0419e..41ae847 100644
 --- a/xen/include/asm-arm/domain.h
 +++ b/xen/include/asm-arm/domain.h
 @@ -42,6 +42,8 @@ struct vtimer {
  uint64_t cval;
  };

 +#define has_arch_pdevs(d)(!list_empty((d)-arch.pdev_list))
 +
  struct arch_domain
  {
  #ifdef CONFIG_ARM_64
 @@ -56,6 +58,7 @@ struct arch_domain
  xen_pfn_t *grant_table_gpfn;

  struct io_handler io_handlers;
 +struct list_head pdev_list;
  /* Continuable domain_relinquish_resources(). */
  enum {
  RELMEM_not_started,
 diff --git a/xen/include/asm-arm/pci.h b/xen/include/asm-arm/pci.h
 index de13359..b8ec882 100644
 --- a/xen/include/asm-arm/pci.h
 +++ b/xen/include/asm-arm/pci.h
 @@ -1,7 +1,8 @@
 -#ifndef __X86_PCI_H__
 -#define __X86_PCI_H__
 +#ifndef __ARM_PCI_H__
 +#define __ARM_PCI_H__

  struct arch_pci_dev {
 +void *dev;

void * is error-prone. Why can't you use the use the real structure?

[manish]Will change it.  I believe dev_archdata structure has also a void *  
(in asm-arm/device.h). So all void * are error prone in xen ?

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v1 3/3] xen/arm: smmu: Renaming struct iommu_domain *domain to, struct iommu_domain *iommu_domain

[Jaggi, Manish]

Regards,
Manish Jaggi


From: Julien Grall julien.gr...@linaro.org
Sent: Friday, March 27, 2015 6:34 PM
To: Jaggi, Manish; Xen Devel; prasun.kap...@cavium.com; Kumar, Vijaya; Ian 
Campbell; Stefano Stabellini
Subject: Re: [PATCH v1 3/3] xen/arm: smmu: Renaming struct iommu_domain *domain 
to, struct iommu_domain *iommu_domain

Hi manish,

On 27/03/15 07:24, Manish Jaggi wrote:
 It is good for code readability as there are many structures ending with
 the name domain.
 Also a code like this one is now easy to understand with the rename
 old: dev_iommu_domain(dev) = domain;
 new: dev_iommu_domain(dev) = iommu_domain;
[manish] Did u see this line

 Also in current code struct smmu_domain pointer variable name is always
 smmu_domain.
 The change is on the same lines

You are modifying the code from Linux just for your own comprehension.
And we are trying to not diverge from a specific Linux commit in order
to easily backport patch.

[manish] please rethink on nack. There are so many data structures ending in 
_domain we need to provide proper naming.

NAcked-by: Julien Grall julien.gr...@linaro.org

Regards,

--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 1/3] xen/arm: smmu: Rename arm_smmu_xen_device with, device_iommu_info

[Jaggi, Manish]

Regards,
Manish Jaggi


From: Julien Grall julien.gr...@linaro.org
Sent: Friday, March 27, 2015 6:29 PM
To: Jaggi, Manish; Xen Devel; Stefano Stabellini; Ian Campbell; 
prasun.kap...@cavium.com; Kumar, Vijaya
Subject: Re: [PATCH v1 1/3] xen/arm: smmu: Rename arm_smmu_xen_device with, 
device_iommu_info

Hi Manish,

On 27/03/15 07:20, Manish Jaggi wrote:
 arm_smmu_xen_device is not an intuitive name for a datastructure which
 represents
 device-archdata.iommu. Rename arm_smmu_xen_device with device_iommu_info

device_iommu_info is not more intuitive... At least arm_smmu_xen_device
shows that it's a specific Xen structure and not coming from the Linux
drivers.

[manish] But that is not a valid reason for a non intuitive naming. It is 
really hard to keep us readability of the code with arm_smmu_xen_device. It is 
not clear that it is referring to a device attached to smmu or smmu itself. 
There is another data structure arm_smmu_device as well. 

Please choose another name I can take it but arm_smmu_xen_device is really 
confusing

Regards,

 Signed-off-by: Manish Jaggi manish.ja...@caviumnetworks.com
 ---
  xen/drivers/passthrough/arm/smmu.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

 diff --git a/xen/drivers/passthrough/arm/smmu.c
 b/xen/drivers/passthrough/arm/smmu.c
 index a7a7da9..ab4f7a4 100644
 --- a/xen/drivers/passthrough/arm/smmu.c
 +++ b/xen/drivers/passthrough/arm/smmu.c
 @@ -247,12 +247,12 @@ struct arm_smmu_xen_domain {
   * that would require to move some hackery (dummy iommu_group) in a
 more generic
   * place.
   * */
 -struct arm_smmu_xen_device {
 +struct device_iommu_info {
  struct iommu_domain *domain;
  struct iommu_group *group;
  };

 -#define dev_archdata(dev) ((struct arm_smmu_xen_device
 *)dev-archdata.iommu)
 +#define dev_archdata(dev) ((struct device_iommu_info
 *)dev-archdata.iommu)
  #define dev_iommu_domain(dev) (dev_archdata(dev)-domain)
  #define dev_iommu_group(dev) (dev_archdata(dev)-group)

 @@ -2574,7 +2574,7 @@ static int arm_smmu_assign_dev(struct domain *d,
 u8 devfn,
  xen_domain = domain_hvm_iommu(d)-arch.priv;

  if (!dev-archdata.iommu) {
 -dev-archdata.iommu = xzalloc(struct arm_smmu_xen_device);
 +dev-archdata.iommu = xzalloc(struct device_iommu_info);
  if (!dev-archdata.iommu)
  return -ENOMEM;
  }


--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 2/3] xen/arm: smmu: Renaming arm_smmu_xen_domain with, domain_iommu_info

[Jaggi, Manish]

Regards,
Manish Jaggi


From: Julien Grall julien.gr...@linaro.org
Sent: Friday, March 27, 2015 6:32 PM
To: Jaggi, Manish; Xen Devel; prasun.kap...@cavium.com; Kumar, Vijaya; Ian 
Campbell; Stefano Stabellini
Subject: Re: [PATCH v1 2/3] xen/arm: smmu: Renaming arm_smmu_xen_domain with, 
domain_iommu_info

Hi Manish,

On 27/03/15 07:22, Manish Jaggi wrote:
 The name arm_smmu_xen_domain was mapped to domain_hvm_iommu(d)-arch.priv.
 Also there are a lot of datastructre in smmu.c with name ending in domain

data structure.

 it is not intuitive and code is hard to understand.

Now it's more difficult to differentiate domain_iommu_info and iommu_domain.

[manish] Please see my previous mail. Also please pick any other name there are 
so many data structures which end up in domain. What is the difference between 
arm_smmu_domain and arm_smmu_xen_domain, I cannot find it based on name. 

Regards,

Regards,

--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 2/3] xen/arm: smmu: Renaming arm_smmu_xen_domain with, domain_iommu_info

[Jaggi, Manish]

Regards,
Manish Jaggi


From: Julien Grall julien.gr...@linaro.org
Sent: Friday, March 27, 2015 7:06 PM
To: Jaggi, Manish; Xen Devel; prasun.kap...@cavium.com; Kumar, Vijaya; Ian 
Campbell; Stefano Stabellini
Subject: Re: [PATCH v1 2/3] xen/arm: smmu: Renaming arm_smmu_xen_domain with, 
domain_iommu_info

On 27/03/15 13:24, Jaggi, Manish wrote:
 Now it's more difficult to differentiate domain_iommu_info and iommu_domain.

 [manish] Please see my previous mail. Also please pick any other name there 
 are so many data structures which end up in domain. What is the difference 
 between arm_smmu_domain and arm_smmu_xen_domain, I cannot find it based on 
 name.

Again, did you read the common above the structure?
[manish] yes but naming is a bit confusing and need to be fixed

How do you different domain_iommu_info vs iommu_domain?
[manish] ok lets change it to domain_iommu_priv. here domain refers to a xen VM 
domain. While iommu_domain refers to a iommu domain within a particular smmu.

Regards,


--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 3/3] xen/arm: smmu: Renaming struct iommu_domain *domain to, struct iommu_domain *iommu_domain

[Jaggi, Manish]

From: Julien Grall julien.gr...@linaro.org
Sent: Friday, March 27, 2015 7:11 PM
To: Jaggi, Manish; Xen Devel; prasun.kap...@cavium.com; Kumar, Vijaya; Ian 
Campbell; Stefano Stabellini
Subject: Re: [PATCH v1 3/3] xen/arm: smmu: Renaming struct iommu_domain *domain 
to, struct iommu_domain *iommu_domain

On 27/03/15 13:26, Jaggi, Manish wrote:
 On 27/03/15 07:24, Manish Jaggi wrote:
 It is good for code readability as there are many structures ending with
 the name domain.
 Also a code like this one is now easy to understand with the rename
 old: dev_iommu_domain(dev) = domain;
 new: dev_iommu_domain(dev) = iommu_domain;
 [manish] Did u see this line

I don't care about the new vs old stuff. What I care is keeping the code
as close as possible to the Linux code.

[manish] then you are missing a point my friend. The line mentioned old is not 
at all intuitive and is confusing. 
 I am not proposing a design change. All I am asking to add a prefix to 
iommu_domain pointers as was already done for smmu_domain pointers.

 You are modifying the code from Linux just for your own comprehension.
 And we are trying to not diverge from a specific Linux commit in order
 to easily backport patch.

 [manish] please rethink on nack. There are so many data structures ending in 
 _domain we need to provide proper naming.

We have 3 structure finishing data structures ending by _domain but the
all have a different prefix and described when necessary.

[manish] But it is hard to follow sometimes and maintaining and debugging the 
code becomes a overhead 

Only one was added for our purpose (arm_smmu_xen_domain). If you don't
like the name of the 2 others, please complain on the Linux ML.

The previous SMMU drivers was diverging from the Linux code and was hard
to backport patch. So my nack is not changed on this point.

Rgards,

--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for 4.6 13/13] xen/iommu: smmu: Add Xen specific code to be able to use the driver

[Jaggi, Manish]

___
From: Julien Grall julien.gr...@linaro.org
Sent: Wednesday, February 18, 2015 5:24 PM
To: Jaggi, Manish; xen-de...@lists.xenproject.org  xen-devel
Cc: ian.campb...@citrix.com; t...@xen.org; stefano.stabell...@citrix.com; 
Jaggi, Manish
Subject: Re: [PATCH for 4.6 13/13] xen/iommu: smmu: Add Xen specific code to be 
able to use the driver

BTW, I have sent few versions of this series since then. Please comment
on the latest series as the code may have change.

[manish] Somehow I could not find your recent revision, but I am looking at 
your den-unstable tree assuming it has your latest version.

Nonetheless, you are comment is still valid for the v3 :).

[manish] There are general comments on the data structures
(a) I don't see a use case where for same domain (VM) there would be different 
context banks , so linked list may not be required. 
(b) Also iommu group may not be relevant for the same reason.
I am curious to find the use cases.


Regards,

On 18/02/2015 11:47, Julien Grall wrote:
 Hi Manish,

 On 18/02/2015 01:02, Manish wrote:

 On 17/12/14 1:38 am, Julien Grall wrote:
 The main goal is to modify as little the Linux code to be able to port
 easily new feature added in Linux repo for the driver.

 To achieve that we:
  - Add helpers to Linux function not implemented on Xen
  - Add callbacks used by Xen to do our own stuff and call Linux ones
  - Only modify when required the code which comes from Linux. If
 so a
  comment has been added with /* Xen: ... */ explaining why it's
  necessary.

 The support for PCI has been commented because it's not yet supported by
 Xen ARM and therefore won't compile.

 Signed-off-by: Julien Grall julien.gr...@linaro.org
 ---
   xen/drivers/passthrough/arm/Makefile |   1 +
   xen/drivers/passthrough/arm/smmu.c   | 668
 +++
   2 files changed, 602 insertions(+), 67 deletions(-)

 diff --git a/xen/drivers/passthrough/arm/Makefile
 b/xen/drivers/passthrough/arm/Makefile
 index 0484b79..f4cd26e 100644
 --- a/xen/drivers/passthrough/arm/Makefile
 +++ b/xen/drivers/passthrough/arm/Makefile
 @@ -1 +1,2 @@
   obj-y += iommu.o
 +obj-y += smmu.o
 diff --git a/xen/drivers/passthrough/arm/smmu.c
 b/xen/drivers/passthrough/arm/smmu.c
 index 8a6514f..3cf1773 100644
 --- a/xen/drivers/passthrough/arm/smmu.c
 +++ b/xen/drivers/passthrough/arm/smmu.c
 @@ -18,6 +18,13 @@
*
* Author: Will Deacon will.dea...@arm.com
*
 + * Based on Linux drivers/iommu/arm-smmu.c
 + *= commit e6b5be2be4e30037eb551e0ed09dd97bd00d85d3
 + *
 + * Xen modification:
 + * Julien Grall julien.gr...@linaro.org
 + * Copyright (C) 2014 Linaro Limited.
 + *
* This driver currently supports:
*- SMMUv1 and v2 implementations
*- Stream-matching and stream-indexing
 @@ -28,26 +35,154 @@
*- Context fault reporting
*/

 snip 

 +/* Xen: Dummy iommu_domain */
 +struct iommu_domain
 +{
 +struct arm_smmu_domain*priv;
 +
 +/* Used to link domain contexts for a same domain */
 +struct list_headlist;
 +};
 +
 +/* Xen: Describes informations required for a Xen domain */
 +struct arm_smmu_xen_domain {
 +spinlock_tlock;
 +/* List of context (i.e iommu_domain) associated to this domain */
 +struct list_headcontexts;
 +};
 +
 +/* Xen: Information about each device stored in dev-archdata.iommu */
 +struct arm_smmu_xen_device {
 +struct iommu_domain *domain;
 +struct iommu_group *group;
 +};
 +
 +#define dev_archdata(dev) ((struct arm_smmu_xen_device
 *)dev-archdata.iommu)
 +#define dev_iommu_domain(dev) (dev_archdata(dev)-domain)
 +#define dev_iommu_group(dev) (dev_archdata(dev)-group)
 +
 +/* Xen: Dummy iommu_group */
 +struct iommu_group
 +{
 +struct arm_smmu_master_cfg *cfg;
 +
 +atomic_t ref;
 +};
 +
 The naming needs to be revisited in this patch. Original driver from
 Will has arm_smmu_domain. This patch adds  iommu_domain,
 arm_smmu_xen_domain, iommu_group.

 I can't change the naming of the structure. iommu_domain and iommu_group
 are from Linux. As we don't have it on Xen, I have to add dummy
 structure for it.

 Could you please add some description about the relation and hierarchy
 of these data structures.

 Good point, I will try to add more comment and explain why we have to do
 it.

 Regards,


--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Using Libvirtd with virt-manager on aarch64

[Jaggi, Manish]

From: Clark Laughlin clark.laugh...@linaro.org
Sent: Tuesday, January 20, 2015 6:57 PM
To: Jaggi, Manish
Cc: Stefano Stabellini; jfeh...@suse.com; Kiarie Kahurani; Kumar, Vijaya; 
anthony.per...@citrix.com; Ian Campbell; xen-de...@lists.xensource.com
Subject: Re: Using Libvirtd with virt-manager on aarch64

I will check and see if I still have it, but I have moved on to other work and 
have already destroyed that build/test environment.

[Manish] Please it would really help

I would love to give you a link to Linaro-generated build output, but we are 
still in the process of getting that setup and running as well.

If you follow the steps in the document (or the steps in the script), you end 
up having to build both xen and xen tools.  You can not use any of the 
distro-provided packages.

[Manish] I have built the tools and my ubuntu is used as dom0.

You will also need to build libvirt, as the libvirt in the distro packages does 
not have xen support enabled.
[Manish] The build fails with trivial errors like test c code does not have 
main. It appears that something is missing in my setup and I need to spend more 
time on it, which at the moment I don't have.

What version of Ubuntu are you using?
[Manish] Using the  link given on the linaro devstack page. Only difference is 
I used the rootfs.

- Clark


On Tuesday, January 20, 2015, Jaggi, Manish 
manish.ja...@caviumnetworks.commailto:manish.ja...@caviumnetworks.com wrote:



From: Stefano Stabellini stefano.stabell...@eu.citrix.com
Sent: Tuesday, January 20, 2015 5:04 AM
To: Jaggi, Manish
Cc: Stefano Stabellini; clark.laugh...@linaro.org; jfeh...@suse.com; Kiarie 
Kahurani; Kumar, Vijaya; anthony.per...@citrix.com; Ian Campbell; 
xen-de...@lists.xensource.com
Subject: Re: Using Libvirtd with virt-manager on aarch64

On Mon, 19 Jan 2015, Jaggi, Manish wrote:
 (B) solved, it was a small copy.
 (A) Still not able to fix.

 
 From: Jaggi, Manish
 Sent: Tuesday, January 20, 2015 12:39 AM
 To: Stefano Stabellini; clark.laugh...@linaro.org
 Cc: jfeh...@suse.com; Kiarie Kahurani; Kumar, Vijaya; 
 anthony.per...@citrix.com; Ian Campbell; xen-de...@lists.xensource.com
 Subject: Re: Using Libvirtd with virt-manager on aarch64

 Hi Stefano / Clark,

 I thought ubuntu dom0 is the better way to get libvirt working, so following 
 the steps,
 (A) there is a build error, if you can help with

 root@manish-thunder-dev:/build/libvirt-upstream/libvirt# debuild -us -uc -i -I
 Fatal Python error: Failed to open /dev/urandom
 Aborted (core dumped)

/dev/urandom is a common Linux device for pseudo-randomness, see
http://en.wikipedia.org/?title=/dev/random. It is not Xen specific or
board specific. I don't know why you don't have it in your installation.

Have you tried creating it?

mknod -m 444 /dev/urandom c 1 9

[manish] I am running in chroot environment so it could be an issue.
Btw Is it possible to get the libvirtd deb so that i can just test it out if it 
works as desired. Clark can you please fwd.


 (B) Also, I was using opensuse image which I believe had xencomons xenstored 
 etc.
 How do i get them ? Do i need to do apt-get install xen-tools

 I am stuck on these two points.

 -Regards
 Manish

 
 From: Stefano Stabellini stefano.stabell...@eu.citrix.com
 Sent: Monday, January 19, 2015 4:01 PM
 To: Jaggi, Manish
 Cc: Stefano Stabellini; clark.laugh...@linaro.org; jfeh...@suse.com; Kiarie 
 Kahurani; Kumar, Vijaya; anthony.per...@citrix.com; Ian Campbell; 
 xen-de...@lists.xensource.com
 Subject: Re: Using Libvirtd with virt-manager on aarch64

 On Fri, 16 Jan 2015, Jaggi, Manish wrote:
  Hi Stefano /clark,
  Thanks for sharing the link. For dom0 I am using openSuse.
  I have followed the steps listed on 
  the(https://libvirt.org/compiling.html#building) to build and install. I 
  believe build-librvit-deb would be doing the same steps or I need to create 
  libvirt-xen.spec.inhttp://libvirt-xen.spec.in ?

 You are right: at the end of build-librvit-deb, the script calls
 debuild, that is not going to work on opensuse.

 I suggest you avoid build-librvit-deb and build libvirt by hand, as from
 the webpage you linked.



  I need some pointers on what could be wrong in my setup because of which I 
  am getting virsh list empty.
  One thing I noted that virsh is able to connect to xen:/// after 
  /etc/init.d/xencommons start is done.
  I am using xen 4.5 rc1.
 
  Is virsh list working in your setup?

 virsh is supposed to be working correctly. Have you tried creating any
 guests via virsh?



  -Regards
  Manish
 
  
  From: Stefano Stabellini stefano.stabell...@eu.citrix.com
  Sent: Friday, January 16, 2015 8:44 PM
  To: Jaggi, Manish
  Cc: jfeh...@suse.com; Kiarie Kahurani; Stefano Stabellini; Kumar, Vijaya; 
  anthony.per...@citrix.com; Ian Campbell; xen-de

Re: [Xen-devel] Using Libvirtd with virt-manager on aarch64

[Jaggi, Manish]

From: Stefano Stabellini stefano.stabell...@eu.citrix.com
Sent: Tuesday, January 20, 2015 5:04 AM
To: Jaggi, Manish
Cc: Stefano Stabellini; clark.laugh...@linaro.org; jfeh...@suse.com; Kiarie 
Kahurani; Kumar, Vijaya; anthony.per...@citrix.com; Ian Campbell; 
xen-de...@lists.xensource.com
Subject: Re: Using Libvirtd with virt-manager on aarch64

On Mon, 19 Jan 2015, Jaggi, Manish wrote:
 (B) solved, it was a small copy.
 (A) Still not able to fix.

 
 From: Jaggi, Manish
 Sent: Tuesday, January 20, 2015 12:39 AM
 To: Stefano Stabellini; clark.laugh...@linaro.org
 Cc: jfeh...@suse.com; Kiarie Kahurani; Kumar, Vijaya; 
 anthony.per...@citrix.com; Ian Campbell; xen-de...@lists.xensource.com
 Subject: Re: Using Libvirtd with virt-manager on aarch64

 Hi Stefano / Clark,

 I thought ubuntu dom0 is the better way to get libvirt working, so following 
 the steps,
 (A) there is a build error, if you can help with

 root@manish-thunder-dev:/build/libvirt-upstream/libvirt# debuild -us -uc -i -I
 Fatal Python error: Failed to open /dev/urandom
 Aborted (core dumped)

/dev/urandom is a common Linux device for pseudo-randomness, see
http://en.wikipedia.org/?title=/dev/random. It is not Xen specific or
board specific. I don't know why you don't have it in your installation.

Have you tried creating it?

mknod -m 444 /dev/urandom c 1 9

[manish] I am running in chroot environment so it could be an issue. 
Btw Is it possible to get the libvirtd deb so that i can just test it out if it 
works as desired. Clark can you please fwd.


 (B) Also, I was using opensuse image which I believe had xencomons xenstored 
 etc.
 How do i get them ? Do i need to do apt-get install xen-tools

 I am stuck on these two points.

 -Regards
 Manish

 
 From: Stefano Stabellini stefano.stabell...@eu.citrix.com
 Sent: Monday, January 19, 2015 4:01 PM
 To: Jaggi, Manish
 Cc: Stefano Stabellini; clark.laugh...@linaro.org; jfeh...@suse.com; Kiarie 
 Kahurani; Kumar, Vijaya; anthony.per...@citrix.com; Ian Campbell; 
 xen-de...@lists.xensource.com
 Subject: Re: Using Libvirtd with virt-manager on aarch64

 On Fri, 16 Jan 2015, Jaggi, Manish wrote:
  Hi Stefano /clark,
  Thanks for sharing the link. For dom0 I am using openSuse.
  I have followed the steps listed on 
  the(https://libvirt.org/compiling.html#building) to build and install. I 
  believe build-librvit-deb would be doing the same steps or I need to create 
  libvirt-xen.spec.in ?

 You are right: at the end of build-librvit-deb, the script calls
 debuild, that is not going to work on opensuse.

 I suggest you avoid build-librvit-deb and build libvirt by hand, as from
 the webpage you linked.



  I need some pointers on what could be wrong in my setup because of which I 
  am getting virsh list empty.
  One thing I noted that virsh is able to connect to xen:/// after 
  /etc/init.d/xencommons start is done.
  I am using xen 4.5 rc1.
 
  Is virsh list working in your setup?

 virsh is supposed to be working correctly. Have you tried creating any
 guests via virsh?



  -Regards
  Manish
 
  
  From: Stefano Stabellini stefano.stabell...@eu.citrix.com
  Sent: Friday, January 16, 2015 8:44 PM
  To: Jaggi, Manish
  Cc: jfeh...@suse.com; Kiarie Kahurani; Stefano Stabellini; Kumar, Vijaya; 
  anthony.per...@citrix.com; Ian Campbell; xen-de...@lists.xensource.com; 
  clark.laugh...@linaro.org
  Subject: Re: Using Libvirtd with virt-manager on aarch64
 
  Hello Manish,
  recently Clark Laughlin (CC'ed) got OpenStack, libvirt and Xen all
  working together on ARM.  He wrote the following wiki page:
 
  https://wiki.linaro.org/OpenStack/DevstackOnXenARM
 
  Cheers,
 
  Stefano
 
  On Fri, 16 Jan 2015, Jaggi, Manish wrote:
   Hi Jim,
  
  
   I am trying to run libvirtd / virsh / virt-manager on aarch64 platform 
   (Cavium thunderX).
  
   Am able to build from the git and able to connect virsh with xen:/// but 
   am not able to get the output of list.
  
   vish nodeinfo command is working.
  
  
   ​Saw  patches in the git log
   - Add support for parsing/formating Xen XL config
   - tests: Tests for the xen-xl parser
  
   Could you please help with the steps / pointers to run virsh / 
   virt-manager with libvirtd.
   ​-Regards
   Manish
  
  
 

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

Re: [Xen-devel] Using Libvirtd with virt-manager on aarch64

[Jaggi, Manish]

(B) solved, it was a small copy.
(A) Still not able to fix.


From: Jaggi, Manish
Sent: Tuesday, January 20, 2015 12:39 AM
To: Stefano Stabellini; clark.laugh...@linaro.org
Cc: jfeh...@suse.com; Kiarie Kahurani; Kumar, Vijaya; 
anthony.per...@citrix.com; Ian Campbell; xen-de...@lists.xensource.com
Subject: Re: Using Libvirtd with virt-manager on aarch64

Hi Stefano / Clark,

I thought ubuntu dom0 is the better way to get libvirt working, so following 
the steps,
(A) there is a build error, if you can help with

root@manish-thunder-dev:/build/libvirt-upstream/libvirt# debuild -us -uc -i -I
Fatal Python error: Failed to open /dev/urandom
Aborted (core dumped)

(B) Also, I was using opensuse image which I believe had xencomons xenstored 
etc.
How do i get them ? Do i need to do apt-get install xen-tools

I am stuck on these two points.

-Regards
Manish


From: Stefano Stabellini stefano.stabell...@eu.citrix.com
Sent: Monday, January 19, 2015 4:01 PM
To: Jaggi, Manish
Cc: Stefano Stabellini; clark.laugh...@linaro.org; jfeh...@suse.com; Kiarie 
Kahurani; Kumar, Vijaya; anthony.per...@citrix.com; Ian Campbell; 
xen-de...@lists.xensource.com
Subject: Re: Using Libvirtd with virt-manager on aarch64

On Fri, 16 Jan 2015, Jaggi, Manish wrote:
 Hi Stefano /clark,
 Thanks for sharing the link. For dom0 I am using openSuse.
 I have followed the steps listed on 
 the(https://libvirt.org/compiling.html#building) to build and install. I 
 believe build-librvit-deb would be doing the same steps or I need to create 
 libvirt-xen.spec.in ?

You are right: at the end of build-librvit-deb, the script calls
debuild, that is not going to work on opensuse.

I suggest you avoid build-librvit-deb and build libvirt by hand, as from
the webpage you linked.



 I need some pointers on what could be wrong in my setup because of which I am 
 getting virsh list empty.
 One thing I noted that virsh is able to connect to xen:/// after 
 /etc/init.d/xencommons start is done.
 I am using xen 4.5 rc1.

 Is virsh list working in your setup?

virsh is supposed to be working correctly. Have you tried creating any
guests via virsh?



 -Regards
 Manish

 
 From: Stefano Stabellini stefano.stabell...@eu.citrix.com
 Sent: Friday, January 16, 2015 8:44 PM
 To: Jaggi, Manish
 Cc: jfeh...@suse.com; Kiarie Kahurani; Stefano Stabellini; Kumar, Vijaya; 
 anthony.per...@citrix.com; Ian Campbell; xen-de...@lists.xensource.com; 
 clark.laugh...@linaro.org
 Subject: Re: Using Libvirtd with virt-manager on aarch64

 Hello Manish,
 recently Clark Laughlin (CC'ed) got OpenStack, libvirt and Xen all
 working together on ARM.  He wrote the following wiki page:

 https://wiki.linaro.org/OpenStack/DevstackOnXenARM

 Cheers,

 Stefano

 On Fri, 16 Jan 2015, Jaggi, Manish wrote:
  Hi Jim,
 
 
  I am trying to run libvirtd / virsh / virt-manager on aarch64 platform 
  (Cavium thunderX).
 
  Am able to build from the git and able to connect virsh with xen:/// but am 
  not able to get the output of list.
 
  vish nodeinfo command is working.
 
 
  ​Saw  patches in the git log
  - Add support for parsing/formating Xen XL config
  - tests: Tests for the xen-xl parser
 
  Could you please help with the steps / pointers to run virsh / virt-manager 
  with libvirtd.
  ​-Regards
  Manish
 
 

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

Re: [Xen-devel] Using Libvirtd with virt-manager on aarch64

[Jaggi, Manish]

Hi Stefano /clark,
Thanks for sharing the link. For dom0 I am using openSuse.
I have followed the steps listed on 
the(https://libvirt.org/compiling.html#building) to build and install. I 
believe build-librvit-deb would be doing the same steps or I need to create 
libvirt-xen.spec.in ?

I need some pointers on what could be wrong in my setup because of which I am 
getting virsh list empty.
One thing I noted that virsh is able to connect to xen:/// after 
/etc/init.d/xencommons start is done.
I am using xen 4.5 rc1.

Is virsh list working in your setup?

-Regards
Manish


From: Stefano Stabellini stefano.stabell...@eu.citrix.com
Sent: Friday, January 16, 2015 8:44 PM
To: Jaggi, Manish
Cc: jfeh...@suse.com; Kiarie Kahurani; Stefano Stabellini; Kumar, Vijaya; 
anthony.per...@citrix.com; Ian Campbell; xen-de...@lists.xensource.com; 
clark.laugh...@linaro.org
Subject: Re: Using Libvirtd with virt-manager on aarch64

Hello Manish,
recently Clark Laughlin (CC'ed) got OpenStack, libvirt and Xen all
working together on ARM.  He wrote the following wiki page:

https://wiki.linaro.org/OpenStack/DevstackOnXenARM

Cheers,

Stefano

On Fri, 16 Jan 2015, Jaggi, Manish wrote:
 Hi Jim,


 I am trying to run libvirtd / virsh / virt-manager on aarch64 platform 
 (Cavium thunderX).

 Am able to build from the git and able to connect virsh with xen:/// but am 
 not able to get the output of list.

 vish nodeinfo command is working.


 ​Saw  patches in the git log
 - Add support for parsing/formating Xen XL config
 - tests: Tests for the xen-xl parser

 Could you please help with the steps / pointers to run virsh / virt-manager 
 with libvirtd.
 ​-Regards
 Manish


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