On Wed, Apr 19, 2017 at 8:31 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi, Julien
>
>
> On 15/03/17 20:05, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> Extend the IOMMU code with new APIs and platform callbacks.
>> These new map_page
On Wed, Apr 19, 2017 at 8:28 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi, Julien
>
> On 15/03/17 20:05, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> The helper has the same purpose as existing for x86 one.
>> It is used for choosi
On Wed, Apr 19, 2017 at 9:09 PM, Julien Grall wrote:
> Hi,
Hi, Julien.
>
> Sorry for the late answer.
>
> On 23/03/17 12:40, Oleksandr Tyshchenko wrote:
>>
>> On Thu, Mar 23, 2017 at 11:08 AM, Jan Beulich wrote:
>>>>>>
>>>>>> On 22
On Wed, Apr 19, 2017 at 8:46 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi, Julien
>
> On 15/03/17 20:05, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> Update IOMMU mapping if the IOMMU doesn't share page table with the CPU.
>> The
On Wed, Apr 19, 2017 at 9:26 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi, Julien
>
> Please CC the appropriate maintainers for all the components you modify.
Sorry, sure.
>
>
> On 15/03/17 20:05, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
On Fri, Apr 21, 2017 at 7:27 PM, Julien Grall wrote:
>
>
> On 21/04/17 15:18, Oleksandr Tyshchenko wrote:
>>
>> On Wed, Apr 19, 2017 at 8:46 PM, Julien Grall
>> wrote:
>>>
>>> Hi Oleksandr,
>>
>> Hi, Julien
>
>
> Hi Oleksandr,
Hi,
On Mon, Apr 24, 2017 at 2:41 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi, Julien
>
> On 21/04/17 19:44, Oleksandr Tyshchenko wrote:
>>
>> On Fri, Apr 21, 2017 at 7:27 PM, Julien Grall
>> wrote:
>>>
>>> On 21/04/17 15:18, Oleksandr Tyshchenko wrote:
&
Hi, Wei
On Tue, Apr 25, 2017 at 6:23 PM, Wei Liu wrote:
> On Wed, Apr 19, 2017 at 07:26:44PM +0100, Julien Grall wrote:
>> Hi Oleksandr,
>>
>> Please CC the appropriate maintainers for all the components you modify.
>>
>> On 15/03/17 20:05, Oleksandr Tyshc
Hi, Ian
On Wed, Apr 26, 2017 at 1:05 PM, Ian Jackson wrote:
> Oleksandr Tyshchenko writes ("Re: [RFC PATCH 9/9] xen: Add use_iommu flag to
> createdomain domctl"):
>> On Tue, Apr 25, 2017 at 6:23 PM, Wei Liu wrote:
>> > Let me explain where I'm coming from
Hi, Jan.
There are the questions I would like to clarify.
On Thu, Mar 23, 2017 at 2:47 PM, Oleksandr Tyshchenko
wrote:
> On Thu, Mar 23, 2017 at 11:07 AM, Jan Beulich wrote:
>>>>> On 22.03.17 at 19:01, wrote:
>>> Hi Jan
>>>
>>> On Wed, Mar 22, 20
> the function the code is in, I wouldn't have had a need at all to go
> look up the context.
Sorry for that. Next time I will provide more detailed snippet.
>
> > P.S. As for using "order" parameter instead of page_count.
> > There are *few* places where "
; > (iommu_map_pages(d,gfn,mfn,1U << (order),flags))
>>>
>>> I'd prefer if you didn't. In no case should this be an identifier
>>> starting with an underscore.
>> I got it. I proposed because I had seen analogy w
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
for x86, but confirmation is needed.
You can find patch series here.
repo: https://github.com/otyshchenko1/xen.git branch: non_shared_iommu_v1
Thank you.
[1] [RFC PATCH 0/9] "Non-shared" IOMMU support on ARM
https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg01905.html
Olek
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
---
From: Oleksandr Tyshchenko
We don't passthrough IOMMU device to DOM0 even if it is not used by
Xen. Therefore exposing the property that describes the IOMMU
master interfaces of the device does not make any sense.
Signed-off-by: Oleksandr Tyshchenko
---
xen/arch/arm/domain_build.c | 4 ++
From: Oleksandr Tyshchenko
The alloc_page_table callback is a mandatory thing
for the IOMMUs that don't share page table with the CPU on ARM.
The non-shared IOMMUs have to perform all required actions here
to be ready to handle IOMMU mapping updates right after completing it.
From: Oleksandr Tyshchenko
The presence of this flag lets us know that the guest
has devices which will most likely be used for passthrough
and as the result the use of IOMMU is expected for this domain.
In that case we have to call iommu_construct(), actually
what the real assign_device call
From: Oleksandr Tyshchenko
The "retrieving mapping" code has never executed since
iommu_use_hap_pt(d) always returned true on ARM so far. But, with
introducing the non-shared IOMMU patch series we can no longer keep
this code as is due to the lack of M2P support.
In order to retain t
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
---
xen/common/device_tree.c | 7 +++
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 use of IOMMU is expected for this domain.
The primary aim of this knowledge is to help the IOMMUs that don't
share page tables wit
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 result the iommu_use_hap_pt(d) is not always true.
Reuse x86's iommu_hap_pt_share flag to indicate whether the IOMMU
page table is shared or not.
Now all IOMMU drivers on ARM are
Hi, Jan, all.
On Wed, May 10, 2017 at 5:50 PM, Jan Beulich wrote:
>>>> On 10.05.17 at 16:03, wrote:
>> From: Oleksandr Tyshchenko
>>
>> Port Linux helper of_count_phandle_with_args for counting
>> number of phandles in a property.
>>
>> Sig
On Thu, May 11, 2017 at 2:38 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi, Julien
>
> On 10/05/17 15:03, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> The alloc_page_table callback is a mandatory thing
>> for the IOMMUs that don't
On Thu, May 11, 2017 at 2:42 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi Julien
>
>
> On 10/05/17 15:03, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> This flag is intended to let Xen know that the guest has devices
>> which will
On Thu, May 11, 2017 at 2:58 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi Julien
>
> On 10/05/17 15:03, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> We don't passthrough IOMMU device to DOM0 even if it is not used by
>> Xen. Theref
On Thu, May 11, 2017 at 2:24 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi Julien
>
> On 10/05/17 15:03, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> Update IOMMU mapping if the IOMMU doesn't share page table with the CPU.
>> The b
On Thu, May 11, 2017 at 2:28 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi Julien
>
> On 10/05/17 15:03, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> Not every integrated into ARM SoCs IOMMU can share page tables
>> with the CPU and a
On Thu, May 11, 2017 at 9:07 PM, Julien Grall wrote:
>
>
> On 11/05/17 15:15, Oleksandr Tyshchenko wrote:
>>
>> On Thu, May 11, 2017 at 2:58 PM, Julien Grall
>> wrote:
>>>
>>> Hi Oleksandr,
>>
>> Hi Julien
>
>
> Hi,
>
>
&g
On Thu, May 11, 2017 at 8:58 PM, Julien Grall wrote:
>
>
> On 11/05/17 15:38, Oleksandr Tyshchenko wrote:
>>
>> On Thu, May 11, 2017 at 2:28 PM, Julien Grall
>> wrote:
>>>
>>> Hi Oleksandr,
>>
>> Hi Julien
>
>
> Hi Ol
On Thu, May 11, 2017 at 9:06 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi Julien
>
>
> On 11/05/17 15:00, Oleksandr Tyshchenko wrote:
>>
>> On Thu, May 11, 2017 at 2:38 PM, Julien Grall
>> wrote:
>>>
>>> Hi Oleksandr,
>>
>> Hi, Jul
>> is already set and the IOMMU is non-shared.
>>
>> So, the logic on ARM was changed a bit, but no functional change for x86.
>>
>> Signed-off-by: Oleksandr Tyshchenko
>> CC: Jan Beulich
>> CC: Julien Grall
>>
>> ---
>>Changes
claration(s) and statement(s) please.
ok
>
> x86 and generic iommu parts (and _only_ those, so please don't
> convert this into a blanket R-b)
> Reviewed-by: Jan Beulich
Thank you. Sure. I won't put your R-b until I get R-b from ARM folks.
>
> Jan
>
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
ries it doesn't look like
>>> you're eliminating this TODO later. While I appreciate this not
>>> being done in the already large patch, I don't think such a TODO
>>> should be left around. If need be (e.g. because you can't test
>>> the c
Hi, Jan.
On Fri, May 12, 2017 at 5:31 PM, Jan Beulich wrote:
>>>> On 10.05.17 at 16:03, wrote:
>> From: Oleksandr Tyshchenko
>>
>> The presence of this flag lets us know that the guest
>> has devices which will most likely be used for passthrough
>
s change
properly, so this is not only the question of testing the code, but rather
having it written.
3. Please correct me if I'm wrong, but these are all *optimizations* which
I am mentioning in that TODO, not something that breaks x86 or affects it
in any way.
That being said, can we post
d all by yourself, but there should be a clear plan
> on getting these items addressed. We shouldn't ship several
> releases with them still present. I'm sorry this hits you, but we've
> had too bad experience in the past with people leaving todo or
> fixme notes in the code, perhaps even promising to address them
> without ever doing so.
I see. You are right about leaving TODO)
Don't mind to get these items addressed *within current patch series*
as separate patch or patches.
So, we have to address for three IOMMUs: Intel/AMD and SMMU. I will
leave SMMU for myself.
Could you, please, provide me with some hints how these TODO should be
properly implemented?
Or
I was thinking I can even just squash *pages with *page and send you a
draft as we need to start from somewhere.
What do you think?
>
> Jan
>
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
xen/drivers/passthrough/amd/iommu_map.c
3. a/xen/drivers/passthrough/arm/smmu.c
And the *optimization* which I mentioned in that TODO is same for all
three files.
+/* TODO: Optimize by squashing map_pages/unmap_pages with
map_page/unmap_page */
I think that I could try to address this TODO by myself as I imagine
it should be addressed and send you a draft or post RFC patch.
As the result of this RFC patch we would have map_pages/unmap_pages
callbacks only, but still iterate 4K pages.
We need to start from somewhere and this patch would be a base point
for continue optimizing.
What do you think? Or you have another opinion?
>
> Jan
>
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
ntroduced. Quite a few we've
> had the discussion of saving a few Mb here or there, and I've almost
> always been the one to ask for not wasting memory even if we have
> plenty, so I'm all with you on that aspect. Nevertheless there is a
> point where the trade-off betwe
sible. Being honest I am interested in adding
IPMMU support
on ARM and this kind of IOMMU does support super pages. And as we
don't want to keep
separate single-page and multi-page stuff together it was decided to
rename existing APIs/callbacks
and add order argument.
In order not to brake existing x86-specific drivers (to retain current behavior)
I had to introduce additional helpers inside them and leave some TODO
which describe that
some optimization is needed.
I can try to reduce the scope of these TODO (to have
map_pages/unmap_pages callbacks only,
but still iterate 4K pages even if hardware supports large pages), but
I am sure that I won't be able to eliminate them completely
(to use large pages in the case that hardware supports them) due to
the several reasons.
I am neither familiar with x86 nor even have x86 boards, excuse me,
but I don't even know support these hardware super pages or not.
I want this patch to be accepted, so some common ground should be
found on getting these items addressed. Maybe you already have
some plan regarding adding such support?
>
> Jan
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
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
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
>>>>
>>>>
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
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, 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, 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, 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 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
>
> 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
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, 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:
>&
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
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
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 |
> (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
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
;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
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
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
>&
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.
>
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
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
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
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
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/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
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
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 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
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
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
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
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
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:
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 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 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 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
>>
>>
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
1 - 100 of 244 matches
Mail list logo
