On 09.09.19 14:45, Julien Grall wrote:
Hi Oleksandr,
Hi, Julien
On 8/20/19 7:09 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Introduce a separate file to keep various helpers which could be used
by more than one IOMMU driver in order not to duplicate code.
The first
On 09.09.19 15:24, Julien Grall wrote:
Hi Oleksandr,
Hi, Julien
The code looks code, few comments below.
On 8/20/19 7:09 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds minimal required support to General IOMMU framework
to be able to handle a case when
On 09.09.19 15:37, Julien Grall wrote:
Hi,
Hi, all.
On 8/27/19 4:11 PM, Jan Beulich wrote:
On 27.08.2019 16:59, Oleksandr wrote:
There was a preference to introduce callback in a separate patch
[2]. Anyway, shall I fold it?
Hmm, I disagree with Julien here. I don't think we s
On 02.09.19 10:04, Yoshihiro Shimoda wrote:
Hi Oleksandr-san,
Hi, Shimoda-san
From: Oleksandr, Sent: Thursday, August 29, 2019 7:56 PM
About this hardware handling, this patch seems good to me. But, since
I'm not familiar about Xen passthrough framework, I think I cannot
a
On 09.09.19 17:36, Julien Grall wrote:
Hi Oleksandr,
Hi, Julien
On 8/20/19 7:09 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
We need to have some abstract way to add new device to the IOMMU
based on the generic IOMMU DT bindings [1] which can be used for
both DT (right
On 09.09.19 18:04, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 8/20/19 7:09 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds new iommu_add_dt_device API for adding DT device
to the IOMMU using generic IOMMU DT bindings [1] and previously
added
On 10.09.19 00:24, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 8/20/19 7:09 PM, Oleksandr Tyshchenko wrote:
diff --git a/xen/arch/arm/platforms/Kconfig
b/xen/arch/arm/platforms/Kconfig
index bc0e9cd..c93a6b2 100644
--- a/xen/arch/arm/platforms/Kconfig
+++ b/xen/arch/arm/platforms
y only mandatory
if you are using the generic bindings. So I would only check
ops->of_xlate if "iommus" exists.
Agree. Will do.
Just to clarify.
What about "ops->add_device", shall I check it if "iommus" exists a
On 10.09.19 18:11, Julien Grall wrote:
Hi Oleksandr,
Hi, Julien
On 8/23/19 8:34 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
There is a strict requirement for the IOMMU which wants to share
the P2M table with the CPU. The IOMMU's Stage-2 input size must be equal
t
On 10.09.19 17:31, Julien Grall wrote:
Hi,
Hi Julien
On 9/10/19 12:04 PM, Oleksandr wrote:
On 10.09.19 00:24, Julien Grall wrote:
---help---
Enable all the required drivers for Renesas RCar3
diff --git a/xen/drivers/passthrough/Kconfig
b/xen/drivers/passthrough/Kconfig
On 10.09.19 21:55, Julien Grall wrote:
Hi,
Hi Julien
On 9/10/19 5:24 PM, Oleksandr wrote:
On 10.09.19 18:11, Julien Grall wrote:
Hi Oleksandr,
Hi, Julien
On 8/23/19 8:34 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
There is a strict requirement for the IOMMU
Hi, Juergen
I have just pushed new version, so please update
=== ARM ===
* Renesas IPMMU-VMSA support + Linux's iommu_fwspec (V4)
- Oleksandr Tyshchenko
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-
On 16.09.19 12:53, Jan Beulich wrote:
Hi, Jan
On 13.09.2019 17:35, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -239,6 +239,16 @@ struct iommu_ops {
int __must_check (*iotlb_flush_all)(struct domain *d);
int
On 16.09.19 13:13, Jan Beulich wrote:
Hi, Jan
On 13.09.2019 17:35, Oleksandr Tyshchenko wrote:
--- a/xen/common/xmalloc_tlsf.c
+++ b/xen/common/xmalloc_tlsf.c
@@ -598,6 +598,58 @@ void *_xzalloc(unsigned long size, unsigned long align)
return p ? memset(p, 0, size) : p;
}
+void
mention about such abuse or change it to deal with real flexible
array member (ids[]). Any thoughts?
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 16.09.19 13:37, Jan Beulich wrote:
Hi, Jan
On 13.09.2019 17:35, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/xmalloc.h
+++ b/xen/include/xen/xmalloc.h
@@ -35,6 +35,15 @@
#define xzalloc_array(_type, _num) \
((_type *)_xzalloc_array(sizeof(_type), __alignof__(_type), _num
On 17.09.19 09:12, Jan Beulich wrote:
Hi, Jan
On 16.09.2019 20:08, Oleksandr wrote:
On 16.09.19 13:40, Jan Beulich wrote:
+/* per-device IOMMU instance data */
+struct iommu_fwspec {
+/* this device's IOMMU */
+struct device *iommu_dev;
+/* IOMMU driver private data for
On 19.09.19 12:44, Julien Grall wrote:
Hi Oleksandr,
Hi, Julien.
On 13/09/2019 16:35, Oleksandr Tyshchenko wrote:
diff --git a/xen/drivers/passthrough/arm/iommu.c
b/xen/drivers/passthrough/arm/iommu.c
index f219de9..555acfc 100644
--- a/xen/drivers/passthrough/arm/iommu.c
+++ b/xen
s, fwspec->num_ids + num_ids);
Julien, what do you think?
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 19.09.19 14:45, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 13/09/2019 16:35, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU)
which provides address translation and access protection functionalities
to
wspec, ids, fwspec->num_ids + num_ids);
Julien, what do you think?
I am happy with that. The first allocation would need a comment on top
explaining the reason of the "1".
Sure, will add.
--
Regards,
Oleksandr Tyshchenko
___
X
On 19.09.19 15:05, Julien Grall wrote:
Hi,
Hi Julien.
On 19/09/2019 12:58, Oleksandr wrote:
On 19.09.19 14:45, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 13/09/2019 16:35, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The IPMMU-VMSA is VMSA-compatible I/O Memory
On 19.09.19 14:35, Julien Grall wrote:
Hi Oleksandr,
Hi, Julien.
On 13/09/2019 16:35, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The main puprose of this patch is to add a way to register DT device
(which is behind the IOMMU) using the generic IOMMU DT bindings [1]
before
or other guests will postpone an error recognition to the guest domain
creation time. So, we would have non function system anyway. Wouldn't be
better to fail early instead of continue and fail anyway?
--
Regards,
Oleksandr Tyshchenko
___
X
Hi Jan
On 13.09.2019 17:35, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/xmalloc.h
+++ b/xen/include/xen/xmalloc.h
@@ -35,6 +35,15 @@
#define xzalloc_array(_type, _num) \
((_type *)_xzalloc_array(sizeof(_type), __alignof__(_type),
_num))
+/* Allocate space for a structure
On 20.09.19 03:25, Yoshihiro Shimoda wrote:
Hi Oleksandr-san,
Hi, Shimoda-san
From: Oleksandr Tyshchenko, Sent: Saturday, September 14, 2019 12:35 AM
From: Oleksandr Tyshchenko
The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU)
which provides address translation and
On 20.09.19 03:31, Stefano Stabellini wrote:
Hi, Stefano.
On Tue, 20 Aug 2019, Oleksandr wrote:
On 20.08.19 15:22, Julien Grall wrote:
Hi, Julien
-iommu_setup();
+rc = iommu_setup();
+if ( !iommu_enabled && rc != -ENODEV )
+panic("Couldn't confi
nation, sounds reasonable. Will modify patch as
you suggested.
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
rlying functions */
extern void *_xmalloc(unsigned long size, unsigned long align);
extern void *_xzalloc(unsigned long size, unsigned long align);
+extern void *_xrealloc(void *ptr, unsigned long size, unsigned long align);
static inline void *_xmalloc_array(
unsigned long size, u
nd as said, please clean up the code you move or add anew: Use casts
only where really needed, transform types to appropriate "modern" ones,
etc.
ok, will double check.
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 24.09.19 12:36, Julien Grall wrote:
Hi,
Hi, Julien
On 11/09/2019 18:59, Oleksandr Tyshchenko wrote:
---
xen/arch/arm/p2m.c | 41
xen/arch/arm/setup.c | 9 +--
xen/drivers/passthrough/arm/ipmmu
On 24.09.19 18:57, Julien Grall wrote:
Hi,
Hi Julien
On 9/24/19 4:30 PM, Oleksandr Tyshchenko wrote:
@@ -1263,15 +1264,22 @@ static int __init handle_device(struct domain
*d, struct dt_device_node *dev,
dt_dprintk("%s passthrough = %d nirq = %d naddr =
On 24.09.19 18:51, Jan Beulich wrote:
Hi, Jan
On 24.09.2019 17:30, Oleksandr Tyshchenko wrote:
Changes V4 -> V5:
- avoid possible truncation with allocations of 4GiB or above
- introduce helper functions add(strip)_padding to avoid
duplicating the code
- omit
On 24.09.19 20:21, Julien Grall wrote:
Hi Oleksandr,
Hi Julien.
[...]
int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
{
@@ -177,6 +241,13 @@ int iommu_do_dt_domctl(struct xen_domctl
*domctl, struct domain *d
mary_switched+0xc/0x2c
(XEN)
(XEN)
(XEN)
(XEN) Panic on CPU 0:
(XEN) Assertion 'unreachable' failed at
...ild-workspace/build/xen/xen/include/xen/iommu.h:72
(XEN) ****
(XEN)
--
Regards,
Oleksandr Tyshchenko
TW, I assume disabling the iommu on the xen command like will work round the
issue?
No. Disabling the iommu will lead to ASSERT in all cases.
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 25.09.19 19:10, Paul Durrant wrote:
Hi Paul
-Original Message-
From: Oleksandr
Sent: 25 September 2019 16:50
To: Paul Durrant ; 'Jan Beulich'
Cc: Petre Pircalabu ; Stefano Stabellini
; Wei Liu
; KonradRzeszutek Wilk ; Andrew Cooper
; David Scott ; Tim (Xen.org)
; Geo
d", it still denies:
Parsing config from /xt/dom.cfg/domd.cfg
ERROR: passthrough disabled but devices are specified
Looks like, correct behavior...
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
it will be under CONFIG_EXPERT when merged, so disabled by default). So,
"iommu_enabled" can be false.
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
n the IOMMU has been disabled.
Signed-off-by: Paul Durrant
Reported-by: Oleksandr
With one NIT below:
Acked-by: Julien Grall
Could you, please, change to:
Reported-by: Oleksandr Tyshchenko
You can also add if really needed:
[with IOMMU disabled on Arm]
Tested-by: Oleksandr Tys
On 26.09.19 15:22, Jan Beulich wrote:
Hi, Jan
On 26.09.2019 13:20, Oleksandr Tyshchenko wrote:
--- a/xen/drivers/passthrough/Kconfig
+++ b/xen/drivers/passthrough/Kconfig
@@ -12,6 +12,19 @@ config ARM_SMMU
Say Y here if your SoC includes an IOMMU device implementing the
On 26.09.19 15:52, Julien Grall wrote:
Hi,
Hi Julien
On 9/26/19 12:20 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The main puprose of this patch is to add a way to register DT device
(which is behind the IOMMU) using the generic IOMMU DT bindings [1]
before assigning
On 26.09.19 15:19, Jan Beulich wrote:
Hi, Jan
On 26.09.2019 13:20, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch introduces type-unsafe function which besides
re-allocation handles the following corner cases:
1. if requested size is zero, it will behave like xfree
2. if
On 26.09.19 17:56, Julien Grall wrote:
Hi,
Hi Julien
On 9/26/19 12:20 PM, Oleksandr Tyshchenko wrote:
Oleksandr Tyshchenko (8):
iommu/arm: Add iommu_helpers.c file to keep common for IOMMUs stuff
iommu/arm: Add ability to handle deferred probing request
xen/common: Introduce
On 27.09.19 13:20, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
Thank you for the respin. The code in p2m.c looks good to me know. One comment
regarding the SMMU code below.
On 24/09/2019 17:01, Oleksandr Tyshchenko wrote:
diff --git a/xen/drivers/passthrough/arm/smmu.c
b/xen/drivers
On 27.09.19 15:38, Julien Grall wrote:
On 27/09/2019 13:35, Julien Grall wrote:
Hi,
Hi Julien,
On 27/09/2019 12:57, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
There is a strict requirement for the IOMMU which wants to share
the P2M table with the CPU. The IOMMU's St
mmu,
This will break dom0less on platform without an IOMMU because setting
CDF_iommu for them will be invalid.
I also don't think this is wise to always enable the IOMMU. This should
only be done if there is a partial device-tree present (most likely it
means passthrough will be used).
On 28.09.19 02:28, Stefano Stabellini wrote:
Hi Stefano
On Fri, 27 Sep 2019, Julien Grall wrote:
Hi,
On 27/09/2019 15:40, Oleksandr wrote:
On 26.09.19 00:12, Julien Grall wrote:
On 25/09/2019 19:49, Stefano Stabellini wrote:
Scan the user provided dtb fragment at boot. For each device
Hi
On 30.09.19 13:44, Jürgen Groß wrote:
On 30.09.19 12:34, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The Arm realization should have been removed in the following commit
as redundant:
f89f555 remove late (on-demand) construction of IOMMU page tables
So, remove unused
On 07.05.19 19:02, Julien Grall wrote:
Hi,
Hi, Julien
On 5/2/19 6:00 PM, Oleksandr Tyshchenko wrote:
docs/misc/arm/early-printk.txt | 5 +
xen/arch/arm/Rules.mk | 7 +++
xen/arch/arm/arm32/debug-scif.inc | 17 +++--
3 files changed, 23 insertions
On 08.05.19 19:19, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 02/05/2019 18:00, Oleksandr Tyshchenko wrote:
Oleksandr Tyshchenko (4):
xen/arm: drivers: scif: Extend driver to handle other interfaces
xen/arm: drivers: scif: Add support for SCIFA compatible UARTs
I have merged
Hello, all
gentle reminder...
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 10.05.19 18:45, Julien Grall wrote:
Hi, Julien
On 10/05/2019 16:29, Oleksandr wrote:
Hello, all
gentle reminder...
This is on my long queue of patches to review. Any help reviewing the
on-going series will help.
Oh, I see. Fair enough.
Cheers,
--
Regards,
Oleksandr
regions(map->d, _gfn(s), size, _mfn(s));
if ( rc == 0 )
{
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
k;
+#endif
+default:
+return -EOPNOTSUPP;
If I correctly understand the code, we can't just return an error here
(domctl_lock is taken, etc). Looks like we should store an error and
modify code to execute exit part.
--
Regards,
Oleksandr Tyshchenko
___
hough R-Car H3 seems to not use PPIs for PMU, I
have tested your patch just to be sure it wouldn't skip anything by a
mistake)
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
total
(XEN) Bank 0: 0x5400->0x5700 <---
linux,lossy_decompress@5400
(XEN) Bank 1: 0x5700->0x5800 <--- linux,adsp@5700
(XEN) Bank 2: 0x5800->0x7000 <--- linux,cma@5800
(XEN) Bank 3: 0x7000->0x8000 <--
t Renesas Stout board is
supported in Xen (of course, if using PSCI-enabled U-Boot).
Next step is to update Wiki regarding Stout board.
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproj
On 20.05.19 14:03, Julien Grall wrote:
Hi,
Hi, Julien
On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Port Linux helper of_count_phandle_with_args for counting
number of phandles in a property.
Linux 5.1 uses a completely different implementation for
On 20.05.19 15:25, Julien Grall wrote:
Hi,
Hi, Julien.
On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Xen expects to see "interrupts" property when parsing host
device-tree. But, there are cases when some device nodes contain
"interrupts-ext
Hi, Julien
On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Xen expects to see "interrupts" property when parsing host
device-tree. But, there are cases when some device nodes contain
"interrupts-extended" property instead.
The good
On 29.05.19 20:44, Julien Grall wrote:
Hi Oleksandr,
Hi, Julien
On 21/05/2019 18:37, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The "interrupts-extended" property is a special form for use when
a node needs to reference multiple interrupt parents. >
According
On 10.06.19 22:45, Julien Grall wrote:
Hi,
Hi Julien
Now applied to my staging branch. It will be committed tonight.
Thank you for the patches.
Thank you for the review.
Cheers,
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing
Arm specific.
I was thinking to place it to xen/include/public/errno.h and guard with
#ifdef __XEN__ to hide from userspace, but not sure it is a good idea,
since it looks like not a POSIX one to be in that header...
--
Regards,
Oleksandr Tyshchenko
being probed
in "any" order. So, framework (drivers/passthrough/arm/iommu.c) will be
modified a bit to be able to handle -EPROBE_DEFER returning by driver.
[1]
https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg02679.html
--
Regards,
Oleks
On 01.08.19 17:31, Oleksandr wrote:
Hello,
Hi, Roger
I think it would help if you describe why such error code is needed by
Xen and how it would be used.
This is needed for the upcoming V2 of the IPMMU driver (ARM) [1]
which may request
deferred probing (returns -EPROBE_DEFER
On 01.08.19 17:34, Jan Beulich wrote:
Hi Jan
On 01.08.2019 16:31, Oleksandr wrote:
This is needed for the upcoming V2 of the IPMMU driver (ARM) [1] which may
request
deferred probing (returns -EPROBE_DEFER) depending on what device will be
probed the first
(Root device must be
On 01.08.19 18:46, Jan Beulich wrote:
On 01.08.2019 16:54, Oleksandr wrote:
On 01.08.19 17:34, Jan Beulich wrote:
On 01.08.2019 16:31, Oleksandr wrote:
This is needed for the upcoming V2 of the IPMMU driver (ARM) [1] which may
request
deferred probing (returns -EPROBE_DEFER
Hello Juergen
I would like to see this in Xen 4.13:
https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg00253.html
So, please add:
=== ARM ===
* Renesas IPMMU-VMSA support + Linux's iommu_fwspec (V2)
- Oleksandr Tyshchenko
--
Regards,
Oleksandr Tyshc
Hello, all.
Forgot to mention that an additional patch from Xen staging is needed,
otherwise Xen may crash at the early stage:
ead6b9f78355e8d366e0c80c4a73fa7fbd6d26cc
"xen/arm: cpuerrata: Align a virtual address before unmap"
--
Regards,
Oleksandr
for zero-size allocation
[1]
https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg00257.html
Thank you.
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi, Shimoda-san.
Thank you for the review.
From: Oleksandr Tyshchenko, Sent: Saturday, August 3, 2019 1:40 AM
From: Oleksandr Tyshchenko
The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU)
which provides address translation and access protection functionalities
to
Hi,
Nevertheless
I'd appreciate if the type-unsafe _xrealloc() didn't remain the
only re-allocation construct, as to avoiding people using it just
because there's no better alternative.
I got your point.
--
Regards,
Oleks
existing examples in Xen?
Jan
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
ght hit into this
fault. In this case the page table is correct and we don't need to fix
anything... Being honest, I have never seen a fault caused by
break-before-make sequence.
Cheers,
--
Regards,
Oleksandr Tyshchenko
__
w.
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 08.08.19 14:01, Roger Pau Monné wrote:
Hi, Roger.
On Thu, Aug 08, 2019 at 01:53:23PM +0300, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Don't skip IOMMU nodes when creating DT for Dom0 if IOMMU has been
forcibly disabled in bootargs (e.g. "iommu=0") in order t
is pointless. We don't really expect any other operations
with the domain which is being destroyed. No assign/deassign devices, no
flush, no map, nothing...
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi, Julien, Roger.
On Thu, Aug 08, 2019 at 01:53:23PM +0300, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Don't skip IOMMU nodes when creating DT for Dom0 if IOMMU has been
forcibly disabled in bootargs (e.g. "iommu=0") in order to let
the IOMMU be accessib
Hi
On Thu, Aug 08, 2019 at 01:53:23PM +0300, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Don't skip IOMMU nodes when creating DT for Dom0 if IOMMU has been
forcibly disabled in bootargs (e.g. "iommu=0") in order to let
the IOMMU be accessible by DOM0.
I d
s revisions (ES 3.0) this driver is supposed
to support only, are *not* affected by that errata. And *not* require
such workaround.
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
way, this should be understood why such discrepancy.
I failed to find something similar in the ML. So, probably, was not
submitted. Hope, we will be able to clarify a reason.
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi, Julien
On 02/08/2019 17:39, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Introduce a separate file to keep various helpers which could be used
by more than one IOMMU driver in order not to duplicate code.
The first condidates to be moved to the new file are SMMU driver&#
Thank you for the detailed answer. I would like to say that I have never
seen Multiple tlb hits error raised by IPMMU in Xen.
Overall, it feels to me the TLB flush is here for a different reason.
I will drop this TLB flush from interrupt handler until clarifie
On 12.08.19 14:11, Julien Grall wrote:
Hi Oleksandr,
Hi, Julien
On 02/08/2019 17:39, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds minimal required support to General IOMMU framework
to be able to handle a case when IOMMU driver requesting deferred
probing for
On 12.08.19 22:46, Julien Grall wrote:
Hi Oleksandr,
Hi, Julien
On 8/12/19 1:01 PM, Oleksandr wrote:
On 12.08.19 14:11, Julien Grall wrote:
On 02/08/2019 17:39, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds minimal required support to General IOMMU framework
On 13.08.19 15:39, Julien Grall wrote:
Hi Oleksandr,
Hi Julien.
On 8/2/19 5:39 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
We need to have some abstract way to add new device to the IOMMU
based on the generic IOMMU DT binding [1] which can be used for
both DT (right now
On 13.08.19 16:49, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 8/2/19 5:39 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds new iommu_add_dt_device API for adding DT device
to the IOMMU using generic IOMMU DT binding [1] and previously
added "iommu_f
On 13.08.19 18:28, Julien Grall wrote:
Hi,
Hi Julien
On 8/13/19 4:17 PM, Oleksandr wrote:
On 13.08.19 15:39, Julien Grall wrote:
xfree is able to deal with NULL pointer, so the check is not necessary.
Yes, the reason I left this check is to not perform an extra
operation
On 13.08.19 16:40, Julien Grall wrote:
Hi Oleksandr,
Hi Julien.
One more comment :).
On 8/2/19 5:39 PM, Oleksandr Tyshchenko wrote:
+int iommu_fwspec_init(struct device *dev, struct device *iommu_dev)
+{
+ struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+
+ if ( fwspec
On 14.08.19 20:38, Julien Grall wrote:
Hi Oleksandr,
Hi Julien.
On 02/08/2019 17:39, Oleksandr Tyshchenko wrote:
+static int ipmmu_iommu_domain_init(struct domain *d)
+{
+ struct ipmmu_vmsa_xen_domain *xen_domain;
+
+ xen_domain = xzalloc(struct ipmmu_vmsa_xen_domain);
+ if
return ( num_iommus > 0 ) ? 0 : -ENODEV;
Cheers,
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
rt_xen(unsigned long
boot_phys_offset,
setup_virt_paging();
- iommu_setup();
+ rc = iommu_setup();
+ if ( !iommu_enabled && rc != -ENODEV )
+ panic("Couldn't configure correctly all the IOMMUs.");
"\n" should be added.
--
Regards,
Oleksandr Tyshchenk
On 20.08.19 15:22, Julien Grall wrote:
Hi, Julien
-iommu_setup();
+rc = iommu_setup();
+if ( !iommu_enabled && rc != -ENODEV )
+panic("Couldn't configure correctly all the IOMMUs.");
Please add "\n"
You can add:
Tested-by:
eallocated to Xen or another domain but still present in the
IOMMU TLBs.
I haven't reproduced this issue as well.
So, my testing here is rather formal to be sure that patch doesn't break
anything.
You can add (if needed):
Tested-by: Oleksandr Tyshchenko
This patch o
;name" property in /memory#1 is
incorrect ("memory" instead of base node name)
ERROR: Input tree has errors, aborting (use -f to force output)
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
ROUNDUP_SIZE(tmp_size);
- if ( tmp_size <= curr_size ) /* fits in current block */
- return ptr;
+ if ( tmp_size <= curr_size && ((unsigned long)ptr & (align - 1)) == 0 )
+ return ptr; /* fits in current block */
p = _xmalloc(size, alig
id I get your point correct?
Yes, with those changes I think it will look ok.
Thank you.
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 22.08.19 15:46, Julien Grall wrote:
Hi Oleksandr,
Hi Julien.
Thank you for the review.
Please try to get your patch on the latest Xen before sending it. So
you can get the right people CCed. For instance, Volodymyr has not
been CCed as a reviewer.
Ooh, next time will do. Sorry
Hi Jan
On 20.08.2019 20:09, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -240,6 +240,16 @@ struct iommu_ops {
int __must_check (*iotlb_flush_all)(struct domain *d);
int (*get_reserved_device_memory)(iommu_grdm_t *, void *);
void
1 - 100 of 2067 matches
Mail list logo
