On Fri, Nov 17, 2017 at 4:01 PM, Julien Grall wrote:
> Hi,
Hi, Julien.
>
> First of all, thank you Oleksandr for starting a thread around CPUFreq
> support.
Thank you for the valued comments.
>
> On 11/16/2017 05:04 PM, Andre Przywara wrote:
>>
>> On 16/11/17 14:
5
>
>>> What power savings can we expect from CPUFreq? Can those possible
>>> savings be transferred into a virtualized environment at all? And do
>>> those saving justify all the extra code in Xen?
>>>
>>> I think those questions need to be answered first, then we can discuss
>>> about the implementation details.
>> OK.
>>
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Thu, Nov 16, 2017 at 7:04 PM, Andre Przywara
wrote:
> Hi,
Hi Andre
Thank you for your comments!
>
> On 16/11/17 14:57, Oleksandr Tyshchenko wrote:
>> On Wed, Nov 15, 2017 at 4:28 PM, Andre Przywara
>> wrote:
>>> Hi,
>> Hi Andre, Jassi
>>
>>
On Wed, Nov 15, 2017 at 4:28 PM, Andre Przywara
wrote:
> Hi,
Hi Andre, Jassi
Thank you for your comments!
>
> On 14/11/17 20:46, Oleksandr Tyshchenko wrote:
>> On Tue, Nov 14, 2017 at 12:49 PM, Andre Przywara
>> wrote:
>>> Hi,
>> Hi Andre
>>
>&
On Tue, Nov 14, 2017 at 12:49 PM, Andre Przywara
wrote:
> Hi,
Hi Andre
>
> On 13/11/17 19:40, Oleksandr Tyshchenko wrote:
>> On Mon, Nov 13, 2017 at 5:21 PM, Andre Przywara
>> wrote:
>>> Hi,
>> Hi Andre,
>>
>>>
>>> thanks ver
On Mon, Nov 13, 2017 at 5:21 PM, Andre Przywara
wrote:
> Hi,
Hi Andre
>
> thanks very much for your work on this!
Thank you for your comments.
>
> On 09/11/17 17:09, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko
>>
>> Hi, all.
>>
>> T
On Thu, Nov 9, 2017 at 7:18 PM, Andrii Anisov wrote:
> Dear Oleksandr,
Dear Andrii
>
>
> Please consider my `Reviewed-by: Andrii Anisov ` for
> all patches.
>
> What you missed after extracting this stuff from github.
Thanks. I will add.
>
>
> On 09.11.17 19:
From: Oleksandr Tyshchenko
Signed-off-by: Oleksandr Tyshchenko
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/arm/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index d46b98c..edd12f8 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen
From: Oleksandr Tyshchenko
Modify the direct ported mailbox infrastructure to be
functional inside Xen.
Include "wrappers.h" which contains all required things the direct
ported code relies on.
Important note: the usage of dummy "wait-for-completion" based on
busy loop res
From: Oleksandr Tyshchenko
Hi, all.
The purpose of this RFC patch series is to add CPUFreq support to Xen on ARM.
Motivation of hypervisor based CPUFreq is to enable one of the main PM
use-cases in virtualized system powered by Xen hypervisor. Rationale behind
this activity is that CPU
From: Oleksandr Tyshchenko
This is a port from Linux.
Signed-off-by: Oleksandr Tyshchenko
CC: Stefano Stabellini
CC: Julien Grall
---
xen/common/device_tree.c | 27 +++
xen/include/xen/device_tree.h | 81 +++
2 files changed, 108
From: Oleksandr Tyshchenko
Signed-off-by: Oleksandr Tyshchenko
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/arm/smpboot.c| 5 +
xen/include/xen/device_tree.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index
From: Oleksandr Tyshchenko
This code is completely borrowed from the patch series for Linux
which hasn't been upstreamed yet:
[PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox
https://lkml.org/lkml/2017/7/23/129
I am very excited about the idea described it a link above.
From: Oleksandr Tyshchenko
This code is completely borrowed from the Linux. Please see:
http://elixir.free-electrons.com/linux/v4.14-rc6/source/drivers/firmware/arm_scpi.c
http://elixir.free-electrons.com/linux/v4.14-rc6/source/include/linux/scpi_protocol.h
Bindings are here:
http://elixir.free
From: Oleksandr Tyshchenko
The mailbox feature is used by the SCPI protocol for inter-processor
communication between System Control Processor(SCP) and Application
Processor(s) (AP). Existing SCPI implementation uses mailbox feature
in common with shared memory region. Actually the mailbox
From: Oleksandr Tyshchenko
Port Linux helper of_count_phandle_with_args for counting
number of phandles in a property.
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Julien Grall
---
Changes in v1:
- Add Julien's reviewed-by
Changes in v2:
-
---
xen/common/device_t
From: Oleksandr Tyshchenko
Signed-off-by: Oleksandr Tyshchenko
CC: Stefano Stabellini
CC: Julien Grall
---
xen/include/asm-arm/device.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 6734ae8..3e2f34a 100644
--- a/xen
From: Oleksandr Tyshchenko
Don't set txdone_poll flag resulting in TXDONE_BY_POLL method.
It is not optimal to use this method along with the dummy
last_tx_done(), since the controller is completely synchronous.
What is more the TXDONE_BY_POLL method is prohibited because of
involving
From: Oleksandr Tyshchenko
Signed-off-by: Oleksandr Tyshchenko
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/arm/Makefile | 1 +
xen/arch/arm/cpufreq/Makefile | 5 +
2 files changed, 6 insertions(+)
create mode 100644 xen/arch/arm/cpufreq/Makefile
diff --git a/xen/arch
Signed-off-by: Oleksandr Tyshchenko
CC: Jan Beulich
CC: Andrew Cooper
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/x86/Kconfig | 1 +
xen/drivers/cpufreq/Kconfig | 3 +++
xen/drivers/cpufreq/utility.c | 11 ++-
xen/drivers/pm/stat.c | 6 ++
xen
From: Oleksandr Tyshchenko
Don't block until data is transmitted.
As we are limited to use only two methods TXDONE_BY_IRQ and TXDONE_BY_ACK,
there are two possible scenario:
- If the mailbox controller has TX-done irq it definitely knows when
transmitted data has been sent and
From: Oleksandr Tyshchenko
This header file is intended to keep various Linux2Xen wrappers,
define-s, stubs which used by all direct ported CPUfreq components.
Signed-off-by: Oleksandr Tyshchenko
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/arm/cpufreq/wrappers.h | 239
From: Oleksandr Tyshchenko
This patch adds a CPUFreq driver for controlling CPUs DVFS feature
provided by System Control Processor (SCP) using SCPI protocol
for inter-processor communication.
The important point is that unlike Linux Xen doesn't have
clock infrastructure and clocks for the
From: Oleksandr Tyshchenko
This patch adds an interface component which performs following steps:
1. Initialize everything needed SCPI based CPUFreq driver to be functional
(SCPI Message protocol, mailbox to communicate with SCP, etc).
Also preliminary check if SCPI DVFS clock nodes
From: Oleksandr Tyshchenko
This patch is just a temp solution to highlight a problem which
should be resolved in a proper way.
set_px_pminfo() is intended to be called from platform hypercall
where "perf" argument was entirely filled in by hwdom.
But unlike x86 we don't get
From: Oleksandr Tyshchenko
Modify the direct ported ARM SMC based mailbox to be
functional inside Xen.
Include "wrappers.h" which contains all required things the direct
ported code relies on.
Signed-off-by: Oleksandr Tyshchenko
CC: Stefano Stabellini
CC: Julien Grall
CC: Andr
From: Oleksandr Tyshchenko
Signed-off-by: Oleksandr Tyshchenko
CC: Stefano Stabellini
CC: Julien Grall
---
xen/include/asm-arm/device.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 3e2f34a..e8ce338 100644
--- a/xen
From: Oleksandr Tyshchenko
This is a port from Linux.
Signed-off-by: Oleksandr Tyshchenko
CC: Stefano Stabellini
CC: Julien Grall
---
xen/common/device_tree.c | 52 +++
xen/include/xen/device_tree.h | 20 +
2 files changed, 72
From: Oleksandr Tyshchenko
This patch adds a flag which indicates if mailbox controller doesn't
need to poll for received data. It either has RX done irq for signaling
when received data are ready or received data 'appears' right after
transmitted data has been sent (synchron
From: Volodymyr Babchuk
Existing SMC wrapper call_smc() allows only 4 parameters and
returns only one value. This is enough for existing
use in PSCI code, but TEE mediator will need a call that is
fully compatible with ARM SMCCC.
This patch adds this call for both arm32 and arm64.
There was simi
-11/msg00932.html
Signed-off-by: Oleksandr Dmytryshyn
Signed-off-by: Oleksandr Tyshchenko
CC: Jan Beulich
CC: Andrew Cooper
CC: Stefano Stabellini
CC: Julien Grall
---
xen/drivers/cpufreq/cpufreq.c| 81 +---
xen/include/public/platform.h| 1 +
xen
From: Oleksandr Tyshchenko
Modify the direct ported SCPI Message Protocol driver to be
functional inside Xen.
As SCPI Message protocol driver expects mailbox to be registed,
find and initialize mailbox before probing it.
Include "wrappers.h" which contains all required things the dir
Dmytryshyn
Signed-off-by: Oleksandr Tyshchenko
CC: Jan Beulich
CC: Andrew Cooper
CC: Stefano Stabellini
CC: Julien Grall
---
MAINTAINERS | 1 +
xen/arch/x86/acpi/cpu_idle.c | 2 +-
xen/arch/x86/acpi/cpufreq/cpufreq.c | 2 +-
xen
Dmytryshyn
Signed-off-by: Oleksandr Tyshchenko
CC: Jan Beulich
CC: Andrew Cooper
CC: Stefano Stabellini
CC: Julien Grall
---
MAINTAINERS | 2 +-
xen/arch/x86/platform_hypercall.c | 2 +-
xen/include/acpi/cpufreq/processor_perf.h | 63
From: Oleksandr Tyshchenko
This is a port from Linux.
Signed-off-by: Oleksandr Tyshchenko
CC: Stefano Stabellini
CC: Julien Grall
---
xen/common/device_tree.c | 20
xen/include/xen/device_tree.h | 15 +++
2 files changed, 35 insertions(+)
diff --git a
-off-by: Oleksandr Tyshchenko
CC: Jan Beulich
CC: Andrew Cooper
CC: Stefano Stabellini
CC: Julien Grall
---
xen/drivers/pm/stat.c| 8 +++-
xen/include/xen/pmstat.h | 2 ++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/xen/drivers/pm/stat.c b/xen/drivers/pm/stat.c
index
From: Oleksandr Tyshchenko
This is a port from Linux.
Signed-off-by: Oleksandr Tyshchenko
CC: Stefano Stabellini
CC: Julien Grall
---
xen/common/device_tree.c | 18 ++
xen/include/xen/device_tree.h | 21 +
2 files changed, 39 insertions(+)
diff
Dmytryshyn
Signed-off-by: Oleksandr Tyshchenko
CC: Jan Beulich
CC: Andrew Cooper
CC: Stefano Stabellini
CC: Julien Grall
---
MAINTAINERS | 1 +
xen/arch/x86/Kconfig | 1 +
xen/common/sysctl.c | 2 +-
xen/drivers/Kconfig | 2 +
xen/drivers/Makefile
From: Oleksandr Tyshchenko
CPU frequencies are in kHz. So, correct displayed text.
Signed-off-by: Oleksandr Tyshchenko
CC: Ian Jackson
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
---
tools/misc/xenpm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools
u should press Ctrl+A six times, then you will see the
>> line like following:
>> (XEN) *** Serial input -> Xen (type 'CTRL-a' three times to
>> switch input to DOM0)
>>
>> Then you can press 'h' for seeing installed key handlers.
>>
sts.xen.org/msg115910.html
[2] [PATCH v2 13/13] [RFC] iommu: AMD-Vi: Squash map_pages/unmap_pages
with map_page/unmap_page
https://patchwork.kernel.org/patch/9862571/
>
>> From: Oleksandr Tyshchenko [mailto:olekst...@gmail.com]
>> Sent: Tuesday, September 12, 2017 10:44 PM
>&
Hi.
Gentle reminder.
On Mon, Aug 21, 2017 at 7:44 PM, Oleksandr Tyshchenko
wrote:
> Hi, all.
>
> Any comments?
>
> On Tue, Jul 25, 2017 at 8:26 PM, Oleksandr Tyshchenko
> wrote:
>> From: Oleksandr Tyshchenko
>>
>> Reduce the scope of the TODO by squashing
Hi.
Gentle reminder.
On Mon, Aug 21, 2017 at 7:44 PM, Oleksandr Tyshchenko
wrote:
> Hi, all.
>
> Any comments?
>
> On Tue, Jul 25, 2017 at 8:26 PM, Oleksandr Tyshchenko
> wrote:
>> From: Oleksandr Tyshchenko
>>
>> Reduce the scope of the TODO by squashing
VC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
2. Check that dom0 kernel doesn't disable clock for console.
BTW, could you post full Xen log, kernel config and device-tree you are using?
If you have some changes on top of Xen, post them too.
These may help people to identify what is wrong.
>
Hi Bharat
On Wed, Sep 6, 2017 at 10:01 AM, bharat gohil wrote:
> Hello Oleksandr,
>
> Thank you very much.It resolved my issue.
Sounds great!
>
> Thanks,
> Bharat
>
> On Mon, Sep 4, 2017 at 6:24 PM, Oleksandr Tyshchenko
> wrote:
>>
>> Hi Bharat
>&
ping
On Mon, Aug 28, 2017 at 8:32 PM, Oleksandr Tyshchenko
wrote:
> From: Oleksandr Tyshchenko
>
> Oleksandr Tyshchenko (2):
> xen/arm: vgic: Check for vgic handler to be initialized before
> dereferencing it
> xen/arm: p2m: Check for p2m->domain to be initial
;arm,gic-400" compatible GIC.
Can you take a look at the patch, maybe it is your case too.
>
> Thanks,
> Bharat
>
>
> On Thu, Aug 31, 2017 at 5:28 PM, Oleksandr Tyshchenko
> wrote:
>>
>> On Thu, Aug 31, 2017 at 2:13 PM, bharat gohil wrote:
>> > Hello
t;>> > (XEN) gic_dist_addr=1051
>>> > (XEN) gic_cpu_addr=1052
>>> > (XEN) gic_hyp_addr=1054
>>> > (XEN) gic_vcpu_addr=1056
>>> > (XEN) gic_maintenance_irq=25
>>> > (XEN) GICv2: 38
> (XEN) CPU 2 booted.
> (XEN) Brought up 3 CPUs
> (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
> (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
>
> Can anyone guide me how to debug this problem or what could be wrong here?
>
> It looks, writing into VTCR_E
From: Oleksandr Tyshchenko
Oleksandr Tyshchenko (2):
xen/arm: vgic: Check for vgic handler to be initialized before
dereferencing it
xen/arm: p2m: Check for p2m->domain to be initialized before releasing
resources
xen/arch/arm/p2m.c | 13 -
xen/arch/arm/vgic.c |
From: Oleksandr Tyshchenko
Since domain_vgic_free() can be called when the vgic_ops haven't been
initialised yet, always check that d->arch.vgic.handler is not a null.
Signed-off-by: Oleksandr Tyshchenko
---
xen/arch/arm/vgic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(
From: Oleksandr Tyshchenko
Since p2m_teardown() can be called when p2m_init() haven't executed yet
we might deal with unitialized list "p2m->pages" which leads to crash.
To avoid this use back pointer to domain as end-of-initialization indicator.
Signed-off-by: Oleksandr Ty
Hi, Stefano, Julien.
On Fri, Aug 25, 2017 at 11:06 PM, Stefano Stabellini
wrote:
> On Wed, 23 Aug 2017, Julien Grall wrote:
>> Hi Oleksandr,
>>
>> On 21/08/17 16:53, Oleksandr Tyshchenko wrote:
>> > On Thu, Aug 10, 2017 at 6:13 PM, Julien Grall wrote:
>&
hink you expect any
> further comments on those. As to the series as a whole - I still have
> it on my to-be-reviewed list, but there's no way I can predict when
> I would get to it.
I got it. No problem, will wait.
>
> Jan
>
>> On Thu, Aug 3, 2017 at 3:32 PM, Oleksandr
Hi, all.
Any comments?
On Tue, Jul 25, 2017 at 8:26 PM, Oleksandr Tyshchenko
wrote:
> From: Oleksandr Tyshchenko
>
> Reduce the scope of the TODO by squashing single-page stuff with
> multi-page one. Next target is to use large pages whenever possible
> in the case that hardwar
Hi, all.
Any comments?
On Tue, Jul 25, 2017 at 8:26 PM, Oleksandr Tyshchenko
wrote:
> From: Oleksandr Tyshchenko
>
> Reduce the scope of the TODO by squashing single-page stuff with
> multi-page one. Next target is to use large pages whenever possible
> in the case that hardwar
Hi, all.
Any comments?
On Tue, Jul 25, 2017 at 8:26 PM, Oleksandr Tyshchenko
wrote:
> From: Oleksandr Tyshchenko
>
> The hardware domains require IOMMU to be used in the most cases and
> a decision to use it is made at hardware domain construction time.
> But, it is not the best
Hi, all.
Any comments?
On Tue, Jul 25, 2017 at 8:26 PM, Oleksandr Tyshchenko
wrote:
> From: Oleksandr Tyshchenko
>
> The presence of this flag lets us know that the guest domain has statically
> assigned devices which will most likely be used for passthrough
> and as the resu
Hi, all.
Any comments?
On Thu, Aug 3, 2017 at 3:32 PM, Oleksandr Tyshchenko
wrote:
> Hi, Julien
>
> On Thu, Aug 3, 2017 at 2:21 PM, Julien Grall wrote:
>> Hi Oleksandr,
>>
>> On 25/07/17 18:26, Oleksandr Tyshchenko wrote:
>>>
>>> diff --git a
Hi, Julien.
Sorry for the late response.
On Thu, Aug 10, 2017 at 6:13 PM, Julien Grall wrote:
> Hi,
>
> On 10/08/17 15:27, Oleksandr Tyshchenko wrote:
>>
>> On Tue, Aug 8, 2017 at 2:34 PM, Julien Grall wrote:
>>>
>>> On 26/07/17 16:09, Oleksandr Tyshch
Hi, Julien
On Tue, Aug 8, 2017 at 2:34 PM, Julien Grall wrote:
> Hi,
>
> On 26/07/17 16:09, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> Modify the Linux IPMMU driver to be functional inside Xen.
>> All devices within a single Xen do
Hi, Julien
On Thu, Aug 3, 2017 at 3:36 PM, Julien Grall wrote:
> Hi,
>
> On 25/07/17 18:26, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> Eliminate TODO by squashing single-page stuff with multi-page one.
>>
>> Signed-off-
Hi, Julien
On Thu, Aug 3, 2017 at 2:37 PM, Julien Grall wrote:
> Hi Oleksandr,
>
>
> On 25/07/17 18:26, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> We don't passthrough IOMMU device to DOM0 even if it is not used by
>> Xen.
Hi, Julien
On Thu, Aug 3, 2017 at 2:31 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 25/07/17 18:26, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> 1. Add missing return in case if IOMMU ops have been already set.
>> 2. Add check for
Hi, Julien
On Thu, Aug 3, 2017 at 2:23 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 25/07/17 18:26, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> Not every integrated into ARM SoCs IOMMU can share page tables
>> with the CPU a
Hi, Julien
On Thu, Aug 3, 2017 at 2:21 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 25/07/17 18:26, Oleksandr Tyshchenko wrote:
>>
>> diff --git a/xen/drivers/passthrough/arm/smmu.c
>> b/xen/drivers/passthrough/arm/smmu.c
>> index 74c09b0..7c313c0 100644
>
Hi, Julien
On Thu, Aug 3, 2017 at 2:33 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 25/07/17 18:26, Oleksandr Tyshchenko wrote:
>>
>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>> index ec19310..3079bbe 100644
>> --- a/xen/arch/arm/domain
Hi, Kevin
On Wed, Aug 2, 2017 at 9:12 AM, Tian, Kevin wrote:
>> From: Oleksandr Tyshchenko [mailto:olekst...@gmail.com]
>> Sent: Tuesday, August 1, 2017 7:08 PM
>>
>> Hi, Kevin
>>
>> On Tue, Aug 1, 2017 at 6:06 AM, Tian, Kevin wrote:
>> >> From:
СС persons from all patches in current series into the cover letter.
On Tue, Aug 1, 2017 at 9:09 PM, Julien Grall wrote:
>
>
> On 01/08/17 04:06, Tian, Kevin wrote:
>>>
>>> From: Oleksandr Tyshchenko [mailto:olekst...@gmail.com]
>>> Sent: Monday, Jul
Hi, Julien
On Tue, Aug 1, 2017 at 3:27 PM, Julien Grall wrote:
> On 26/07/17 16:09, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> Hi, all.
>
>
> Hi,
>
> Please CC maintainers and any relevant person on the cover letter. This is
&
Hi, Kevin
On Tue, Aug 1, 2017 at 6:06 AM, Tian, Kevin wrote:
>> From: Oleksandr Tyshchenko [mailto:olekst...@gmail.com]
>> Sent: Monday, July 31, 2017 7:58 PM
>>
>> Hi, Kevin
>>
>> On Mon, Jul 31, 2017 at 8:57 AM, Tian, Kevin wrote:
>> >> From:
Hi, Kevin
On Mon, Jul 31, 2017 at 8:57 AM, Tian, Kevin wrote:
>> From: Oleksandr Tyshchenko
>> Sent: Wednesday, July 26, 2017 1:27 AM
>>
>> From: Oleksandr Tyshchenko
>>
>> Hi, all.
>>
>> The purpose of this patch series is to create a base for
Hi, Wei
On Fri, Jul 28, 2017 at 7:16 PM, Wei Liu wrote:
> On Tue, Jul 25, 2017 at 08:26:51PM +0300, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko
>>
>> This flag is intended to let Xen know that the guest has devices
>> which will most likely be used
x86 ===
>
>
> ... and answer on x86 category when your items look ARM specific.
>
>> I am working on XEN-70, have already posted rfc. [1]
>>
>> Also can you please add a xen-jira issue for the ITS ACPI support [2] v2
>>
From: Oleksandr Tyshchenko
Hi, all.
The purpose of this patch series is to add IPMMU-VMSA support to Xen on ARM.
It is VMSA-compatible IOMMU that integrated in the newest Renesas R-Car Gen3
SoCs (ARM).
And this IOMMU can't share the page table with the CPU since it doesn't use the
From: Oleksandr Tyshchenko
The Linux IPMMU driver which is being ported to Xen relies on this
Linux framework. Moreover, as the IPMMU is a non-shared IOMMU
we must have a way of manipulating it's page table.
So, copy it as is for now to simplify things, but we will have to find
common g
From: Oleksandr Tyshchenko
The patch was ported from RFC patch for Linux and
slightly modified in order to handle IOVA space above 32-bit.
iommu/ipmmu-vmsa: Initial R-Car Gen3 VA64 mode support
https://patchwork.kernel.org/patch/9532335/
Modifications to the original patch are:
- Increase IOVA
From: Oleksandr Tyshchenko
This is the PoC how to optimize page table deallocation sequence
by splitting it into separate chunks.
Use iommu_pt_cleanup_list to queue pages that need to be handled and
freed next time. Use free_page_table platform callback to dequeue
pages.
Signed-off-by
From: Oleksandr Tyshchenko
Modify the Linux IPMMU driver to be functional inside Xen.
All devices within a single Xen domain must use the same
IOMMU context no matter what IOMMU domains they are attached to.
This is the main difference between drivers in Linux
and Xen. Having 8 separate contexts
From: Oleksandr Tyshchenko
It is VMSA-compatible IOMMU that integrated in the
newest Renesas SoCs (ARM). Copy Linux IPMMU driver as is for now.
Next patches will show what is going on.
Linux driver was taken here:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git rcar-3.5.3
From: Oleksandr Tyshchenko
Signed-off-by: Oleksandr Tyshchenko
CC: Julien Grall
CC: Stefano Stabellini
---
xen/drivers/passthrough/arm/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/drivers/passthrough/arm/Makefile
b/xen/drivers/passthrough/arm/Makefile
index f4cd26e
From: Oleksandr Tyshchenko
Modify the Linux framework to be functional inside Xen.
It's mostly about differences between memory manipulations
in Xen and Linux.
Also wrap following code in #if 0:
- All DMA related stuff
- Stage-2 related things
- Self test
Signed-off-by: Oleksandr Tyshc
From: Oleksandr Tyshchenko
Replace existing single-page stuff (IOMMU APIs and platform callbacks)
with the multi-page one followed by modifications of all related parts.
These new map_pages/unmap_pages APIs do almost the same thing
as old map_page/unmap_page ones except the formers have extra
From: Oleksandr Tyshchenko
The presence of this flag lets us know that the guest domain has statically
assigned devices which will most likely be used for passthrough
and as the result the IOMMU is expected to be used for this domain.
Taking into the account this hint when dealing with non
From: Oleksandr Tyshchenko
Reduce the scope of the TODO by squashing single-page stuff with
multi-page one. Next target is to use large pages whenever possible
in the case that hardware supports them.
Signed-off-by: Oleksandr Tyshchenko
CC: Jan Beulich
CC: Suravee Suthikulpanit
From: Oleksandr Tyshchenko
Update IOMMU mapping if the IOMMU doesn't share page table with the CPU.
The best place to do so on ARM is __p2m_set_entry(). Use mfn as an indicator
of the required action. If mfn is valid call iommu_map_pages(),
otherwise - iommu_unmap_pages().
Signed-o
From: Oleksandr Tyshchenko
Not every integrated into ARM SoCs IOMMU can share page tables
with the CPU and as the result the iommu_use_hap_pt(d) mustn't
always be true.
Reuse x86's iommu_hap_pt_share flag to indicate whether the IOMMU
page table is shared or not.
As P2M table must
From: Oleksandr Tyshchenko
This flag is intended to let Xen know that the guest has devices
which will most likely be used for passthrough and as the result
the IOMMU is expected to be used for this domain.
The primary aim of this knowledge is to help the IOMMUs that don't
share page t
From: Oleksandr Tyshchenko
The helper has the same purpose as existing for x86 one.
It is used for choosing IOMMU mapping attribute according to
the memory type.
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Julien Grall
---
Changes in v1:
- Add Julien's reviewed-by
Ch
From: Oleksandr Tyshchenko
1. Add missing return in case if IOMMU ops have been already set.
2. Add check for shared IOMMU before returning an error.
Signed-off-by: Oleksandr Tyshchenko
CC: Julien Grall
---
Changes in V1:
-
Changes in V2:
-
---
xen/drivers/passthrough/arm
From: Oleksandr Tyshchenko
The hardware domains require IOMMU to be used in the most cases and
a decision to use it is made at hardware domain construction time.
But, it is not the best moment for the non-shared IOMMUs due to
the necessity of retrieving all mapping which could happen in a period
From: Oleksandr Tyshchenko
Eliminate TODO by squashing single-page stuff with multi-page one.
Signed-off-by: Oleksandr Tyshchenko
CC: Julien Grall
---
Changes in v1:
-
Changes in v2:
-
---
xen/drivers/passthrough/arm/smmu.c | 48 +-
1
From: Oleksandr Tyshchenko
We don't passthrough IOMMU device to DOM0 even if it is not used by
Xen. Therefore exposing the properties that describe relationship
between master devices and IOMMUs does not make any sense.
According to the:
1. Documentation/devicetree/bindings/iommu/iommu.
From: Oleksandr Tyshchenko
Port Linux helper of_count_phandle_with_args for counting
number of phandles in a property.
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Julien Grall
---
Changes in v1:
- Add Julien's reviewed-by
Changes in v2:
-
---
xen/common/device_t
From: Oleksandr Tyshchenko
Reduce the scope of the TODO by squashing single-page stuff with
multi-page one. Next target is to use large pages whenever possible
in the case that hardware supports them.
Signed-off-by: Oleksandr Tyshchenko
CC: Jan Beulich
CC: Kevin Tian
---
Changes in v1
From: Oleksandr Tyshchenko
Hi, all.
The purpose of this patch series is to create a base for porting
any "Non-shared" IOMMUs to Xen on ARM. Saying "Non-shared" IOMMU I mean
the IOMMU that can't share the page table with the CPU.
Primarily, we are interested in IPMMU-VMS
gt;> iommu_hwdom_init() code that goes through the list of page and tries
>> to retrieve mapping could be just dropped
>> instead of moving it to the arch-specific part.
>
> And again, careful here: There are three command line options
> influencing which pages do actually get m
Hi, all.
On Thu, May 18, 2017 at 11:53 AM, Jan Beulich wrote:
>>>> On 17.05.17 at 22:30, wrote:
>> On 05/17/2017 07:51 PM, Oleksandr Tyshchenko wrote:
>>> On Wed, May 17, 2017 at 7:01 PM, Jan Beulich wrote:
>>>> Well, if the ARM maintainers insist on baki
Hi, all.
On Thu, May 18, 2017 at 11:38 AM, Jan Beulich wrote:
>>>> On 17.05.17 at 21:52, wrote:
>> On 05/12/2017 03:31 PM, Jan Beulich wrote:
>>>>>> On 10.05.17 at 16:03, wrote:
>>>> From: Oleksandr Tyshchenko
>>>>
>>>>
maintain) code crosses a boundary, and I'm simply
>>> wondering whether we aren't at that point.
>>
>> Is the lack of M2P support on ARM a blocker for this patch to be accepted?
>
> Well, if the ARM maintainers insist on baking their own thing every
> time we'd use the M2P if it was there, I think I can't reasonably
> block this patch. Otoh I'd prefer to not see the non-x86-specific
> code move to x86/, so perhaps the whole patch wants
> re-structuring using either a manifest definition in the ARM headers
> or e.g. CONFIG_M2P (which x86 would select, but ARM wouldn't).
Jan, I am afraid but I didn't get what you meant here:
"manifest definition in the ARM headers"
Julien, Stefano what do you think in general?
>
>> This patch I think is only prevents us from possible bugs in a future.
>> Please correct me if I am wrong.
>
> Avoiding possible bugs in the future I didn't connect to this patch so
> far.
>
> Jan
>
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
1 - 100 of 244 matches
Mail list logo
