On 11.12.20 08:24, Jan Beulich wrote:
On 11.12.2020 08:02, Jürgen Groß wrote:
On 10.12.20 21:51, Julien Grall wrote:
Hi Jan,
On 09/12/2020 14:29, Jan Beulich wrote:
On 09.12.2020 13:11, Julien Grall wrote:
On 26/11/2020 11:20, Jan Beulich wrote:
On 26.11.2020 09:03, Juergen Gross wrote:
Wh
On 11.12.2020 08:02, Jürgen Groß wrote:
> On 10.12.20 21:51, Julien Grall wrote:
>> Hi Jan,
>>
>> On 09/12/2020 14:29, Jan Beulich wrote:
>>> On 09.12.2020 13:11, Julien Grall wrote:
On 26/11/2020 11:20, Jan Beulich wrote:
> On 26.11.2020 09:03, Juergen Gross wrote:
>> When the host cr
flight 157410 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157410/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 157345
build-i386
On 10.12.20 21:51, Julien Grall wrote:
Hi Jan,
On 09/12/2020 14:29, Jan Beulich wrote:
On 09.12.2020 13:11, Julien Grall wrote:
On 26/11/2020 11:20, Jan Beulich wrote:
On 26.11.2020 09:03, Juergen Gross wrote:
When the host crashes it would sometimes be nice to have additional
debug data ava
flight 157392 qemu-mainline real [real]
flight 157405 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157392/
http://logs.test-lab.xenproject.org/osstest/logs/157405/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 11.12.20 00:20, boris.ostrov...@oracle.com wrote:
On 12/10/20 2:26 PM, Thomas Gleixner wrote:
All event channel setups bind the interrupt on CPU0 or the target CPU for
percpu interrupts and overwrite the affinity mask with the corresponding
cpumask. That does not make sense.
The XEN impleme
flight 157406 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157406/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 157345
build-i386
On 10.12.20 21:15, Thomas Gleixner wrote:
Mark tripped over the creative irqflags handling in the IO-APIC timer
delivery check which ends up doing:
local_irq_save(flags);
local_irq_enable();
local_irq_restore(flags);
which triggered a new consistency check he's working
On Thu, Dec 10, 2020 at 08:25:49PM +0100, Thomas Gleixner wrote:
> Nothing uses the result and nothing should ever use it in driver code.
>
> Signed-off-by: Thomas Gleixner
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Pankaj Bharadiy
On Thu, Dec 10, 2020 at 08:25:48PM +0100, Thomas Gleixner wrote:
> The irq descriptor is already there, no need to look it up again.
>
> Signed-off-by: Thomas Gleixner
> Cc: Christian Borntraeger
> Cc: Heiko Carstens
> Cc: linux-s...@vger.kernel.org
> ---
> arch/s390/kernel/irq.c |2 +-
>
flight 157402 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157402/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 157345
build-i386
flight 157399 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157399/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 157345
build-i386
flight 157394 ovmf real [real]
flight 157397 ovmf real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157394/
http://logs.test-lab.xenproject.org/osstest/logs/157397/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-
On Thu, 10 Dec 2020, Luca Fancellu wrote:
> On the Cortex A53, when executing in AArch64 state, a load or store
> instruction
> which uses the result of an ADRP instruction as a base register, or which uses
> a base register written by an instruction immediately after an ADRP to the
> same registe
On Thu, 10 Dec 2020, Rahul Singh wrote:
> Remove code that is related to below functionality :
> 1. struct io_pgtable_ops
> 2. struct io_pgtable_cfg
> 3. struct iommu_flush_ops,
> 4. struct iommu_ops
> 5. module_param_named, MODULE_PARM_DESC, module_platform_driver,
> MODULE_*
> 6. IOMMU
On Thu, 10 Dec 2020, Rahul Singh wrote:
> Replace all Linux compatible device tree handling function with the XEN
> functions.
>
> Replace all Linux ktime function with the XEN time functions.
>
> Signed-off-by: Rahul Singh
Reviewed-by: Stefano Stabellini
> ---
> Changes in v3:
> - This pat
On Thu, 10 Dec 2020, Rahul Singh wrote:
> Add support for ARM architected SMMUv3 implementation. It is based on
> the Linux SMMUv3 driver.
>
> Driver is currently supported as Tech Preview.
>
> Major differences with regard to Linux driver are as follows:
> 2. Only Stage-2 translation is supporte
On Thu, 10 Dec 2020, Rahul Singh wrote:
> Import the Linux helper of_property_match_string. This function searches
> a string list property and returns the index of a specific string value.
>
> Signed-off-by: Rahul Singh
Reviewed-by: Stefano Stabellini
> ---
> Changes in v3:
> - This patch i
On Thu, 10 Dec 2020, Rahul Singh wrote:
> @@ -2087,29 +1693,8 @@ static int arm_smmu_domain_finalise(struct
> iommu_domain *domain,
> }
>
> /* Restrict the stage to what we can actually support */
> - if (!(smmu->features & ARM_SMMU_FEAT_TRANS_S1))
> - smmu_domain->st
On Thu, 10 Dec 2020, Rahul Singh wrote:
> XArray is not implemented in XEN revert the patch that introduce the
> XArray code in SMMUv3 driver.
>
> XArray is added in preparation for sharing some ASIDs with the CPU,
>
> As XEN support only Stage-2 translation, ASID is used for Stage-1
> translatio
On Thu, 10 Dec 2020, Rahul Singh wrote:
> Based on tag Linux 5.8.18 commit ab435ce49bd1d02e33dfec24f76955dc1196970b
>
> Directory structure change for the SMMUv3 driver starting from
> Linux 5.9, to revert the patches smoothly using the "git revert" command
> we decided to choose Linux 5.8.18.
>
On Thu, 10 Dec 2020, Rahul Singh wrote:
> Linux SMMUv3 code implements the commands-queue insertion based on
> atomic operations implemented in Linux. Atomic functions used by the
> commands-queue insertion are not implemented in XEN therefore revert the
> patch that implemented the commands-queue
On Thu, 10 Dec 2020, Julien Grall wrote:
> On 10/12/2020 02:30, Stefano Stabellini wrote:
> > On Mon, 30 Nov 2020, Oleksandr Tyshchenko wrote:
> > > From: Oleksandr Tyshchenko
> > >
> > > We need to send mapcache invalidation request to qemu/demu everytime
> > > the page gets removed from a guest
On Thu, Dec 10 2020 at 18:20, boris ostrovsky wrote:
> On 12/10/20 2:26 PM, Thomas Gleixner wrote:
>> All event channel setups bind the interrupt on CPU0 or the target CPU for
>> percpu interrupts and overwrite the affinity mask with the corresponding
>> cpumask. That does not make sense.
>>
>> The
On Thu, Dec 10 2020 at 18:19, boris ostrovsky wrote:
> On 12/10/20 2:26 PM, Thomas Gleixner wrote:
>> -EXPORT_SYMBOL_GPL(bind_evtchn_to_irq_lateeoi);
>
> include/xen/events.h also needs to be updated (and in the next patch for
> xen_set_affinity_evtchn() as well).
Darn, I lost that.
On 12/10/20 2:26 PM, Thomas Gleixner wrote:
> All event channel setups bind the interrupt on CPU0 or the target CPU for
> percpu interrupts and overwrite the affinity mask with the corresponding
> cpumask. That does not make sense.
>
> The XEN implementation of irqchip::irq_set_affinity() already
On 12/10/20 2:26 PM, Thomas Gleixner wrote:
> Signed-off-by: Thomas Gleixner
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: Stefano Stabellini
> Cc: xen-devel@lists.xenproject.org
> ---
> drivers/xen/events/events_base.c |6 --
> 1 file changed, 6 deletions(-)
>
> --- a/drivers/xen/
On Thu, Dec 10, 2020 at 1:42 PM Thomas Gleixner wrote:
>
> Going through a full irq descriptor lookup instead of just using the proper
> helper function which provides direct access is suboptimal.
>
> In fact it _is_ wrong because the chip callback needs to get the chip data
> which is relevant fo
On Thu, Dec 10, 2020 at 1:42 PM Thomas Gleixner wrote:
>
> Going through a full irq descriptor lookup instead of just using the proper
> helper function which provides direct access is suboptimal.
>
> In fact it _is_ wrong because the chip callback needs to get the chip data
> which is relevant fo
On Thu, 10 Dec 2020, Bertrand Marquis wrote:
> > On 9 Dec 2020, at 19:54, Stefano Stabellini wrote:
> >
> > On Wed, 9 Dec 2020, Bertrand Marquis wrote:
> >> Add support for emulation of cp15 based ID registers (on arm32 or when
> >> running a 32bit guest on arm64).
> >> The handlers are returning
On Thu, 10 Dec 2020, Bertrand Marquis wrote:
> Hi Stefano,
>
> > On 9 Dec 2020, at 19:38, Stefano Stabellini wrote:
> >
> > On Wed, 9 Dec 2020, Bertrand Marquis wrote:
> >> Add vsysreg emulation for registers trapped when TID3 bit is activated
> >> in HSR.
> >> The emulation is returning the val
flight 157386 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157386/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-qem
flight 157390 ovmf real [real]
flight 157393 ovmf real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157390/
http://logs.test-lab.xenproject.org/osstest/logs/157393/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-
Hi Doug,
After chatting with Wei on IRC, it became obvious that the issue is that
gitlab-docker-machine-oyster failed, see its grey status here under
"Runners":
https://gitlab.com/xen-project/patchew/xen/-/settings/ci_cd
Maybe it is just a matter of rebooting the VM? Doug, could you give it a
tr
On 10/12/2020 17:35, Manuel Bouyer wrote:
> On Thu, Dec 10, 2020 at 05:18:39PM +, Andrew Cooper wrote:
>> However, Xen finds the mapping not-present when trying to demand-map it,
>> hence why the #PF is forwarded to the kernel.
>>
>> The way we pull guest virtual addresses was altered by XSA-28
Hi Jan,
On 09/12/2020 14:29, Jan Beulich wrote:
On 09.12.2020 13:11, Julien Grall wrote:
On 26/11/2020 11:20, Jan Beulich wrote:
On 26.11.2020 09:03, Juergen Gross wrote:
When the host crashes it would sometimes be nice to have additional
debug data available which could be produced via debug
Mark tripped over the creative irqflags handling in the IO-APIC timer
delivery check which ends up doing:
local_irq_save(flags);
local_irq_enable();
local_irq_restore(flags);
which triggered a new consistency check he's working on required for
replacing the POPF based rest
flight 157376 qemu-mainline real [real]
flight 157389 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157376/
http://logs.test-lab.xenproject.org/osstest/logs/157389/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
No driver has any business with the internals of an interrupt
descriptor. Storing a pointer to it just to use yet another helper at the
actual usage site to retrieve the affinity mask is creative at best. Just
because C does not allow encapsulation does not mean that the kernel has no
limits.
Retr
This function can only ever work when the event channels:
- are already established
- interrupts assigned to them
- the affinity has been set by user space already
because any newly set up event channel is forced to be bound to CPU0 and
the affinity mask of the interrupt is forced to contai
Going through a full irq descriptor lookup instead of just using the proper
helper function which provides direct access is suboptimal.
In fact it _is_ wrong because the chip callback needs to get the chip data
which is relevant for the chip while using the irq descriptor variant
returns the irq c
No more (ab)use in modules finally. Remove the export so there won't come
new ones.
Signed-off-by: Thomas Gleixner
---
kernel/irq/irqdesc.c |1 -
1 file changed, 1 deletion(-)
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -352,7 +352,6 @@ struct irq_desc *irq_to_desc(unsigned in
Let the core code do the fiddling with irq_desc.
Signed-off-by: Thomas Gleixner
Cc: Linus Walleij
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-g...@vger.kernel.org
---
drivers/pinctrl/nomadik/pinctrl-nomadik.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/pinct
Use the proper core function.
Signed-off-by: Thomas Gleixner
Cc: Jon Mason
Cc: Dave Jiang
Cc: Allen Hubbe
Cc: linux-...@googlegroups.com
---
drivers/ntb/msi.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/ntb/msi.c
+++ b/drivers/ntb/msi.c
@@ -282,15 +282,13 @@ int
There is absolutely no reason to mimic the x86 deferred affinity
setting. This mechanism is required to handle the hardware induced issues
of IO/APIC and MSI and is not in use when the interrupts are remapped.
XEN does not need this and can simply change the affinity from the calling
context. The
Keep track of the assignments of event channels to CPUs and select the
online CPU with the least assigned channels in the affinity mask which is
handed to irq_chip::irq_set_affinity() from the core code.
Signed-off-by: Thomas Gleixner
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Using the interrupt affinity mask for checking locality is not really
working well on architectures which support effective affinity masks.
The affinity mask is either the system wide default or set by user space,
but the architecture can or even must reduce the mask to the effective set,
which me
Using the interrupt affinity mask for checking locality is not really
working well on architectures which support effective affinity masks.
The affinity mask is either the system wide default or set by user space,
but the architecture can or even must reduce the mask to the effective set,
which me
Going through a full irq descriptor lookup instead of just using the proper
helper function which provides direct access is suboptimal.
In fact it _is_ wrong because the chip callback needs to get the chip data
which is relevant for the chip while using the irq descriptor variant
returns the irq c
No driver has any business with the internals of an interrupt
descriptor. Storing a pointer to it just to use yet another helper at the
actual usage site to retrieve the affinity mask is creative at best. Just
because C does not allow encapsulation does not mean that the kernel has no
limits.
Retr
To prepare for interrupt spreading reduce the storage size of
irq_info::spurious_cnt to u8 so the required flag for the spreading logic
will not increase the storage size.
Protect the usage site against overruns.
Signed-off-by: Thomas Gleixner
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano
Signed-off-by: Thomas Gleixner
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-devel@lists.xenproject.org
---
drivers/xen/events/events_base.c |6 --
1 file changed, 6 deletions(-)
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -1
All event channel setups bind the interrupt on CPU0 or the target CPU for
percpu interrupts and overwrite the affinity mask with the corresponding
cpumask. That does not make sense.
The XEN implementation of irqchip::irq_set_affinity() already picks a
single target CPU out of the affinity mask and
Nothing uses the result and nothing should ever use it in driver code.
Signed-off-by: Thomas Gleixner
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: David Airlie
Cc: Daniel Vetter
Cc: Pankaj Bharadiya
Cc: Chris Wilson
Cc: Wambui Karuga
Cc: intel-...@lists.freedesktop.org
Cc: dri
The irq descriptor is already there, no need to look it up again.
Signed-off-by: Thomas Gleixner
Cc: Christian Borntraeger
Cc: Heiko Carstens
Cc: linux-s...@vger.kernel.org
---
arch/s390/kernel/irq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/s390/kernel/irq.c
+++ b/a
No more users outside the core code.
Signed-off-by: Thomas Gleixner
---
include/linux/kernel_stat.h |1 -
kernel/irq/irqdesc.c| 19 ++-
2 files changed, 6 insertions(+), 14 deletions(-)
--- a/include/linux/kernel_stat.h
+++ b/include/linux/kernel_stat.h
@@ -67,7 +6
Driver code has no business with the internals of the irq descriptor.
Aside of that the count is per interrupt line and therefore takes
interrupts from other devices into account which share the interrupt line
and are not handled by the graphics driver.
Replace it with a pmu private count which o
First of all drivers have absolutely no business to dig into the internals
of an irq descriptor. That's core code and subject to change. All of this
information is readily available to /proc/interrupts in a safe and race
free way.
Remove the inspection code which is a blatant violation of subsyste
The irq descriptor is already there, no need to look it up again.
Signed-off-by: Thomas Gleixner
Cc: Marc Zyngier
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm/kernel/smp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/kernel/smp.c
+++ b/arch
This function uses irq_to_desc() and is going to be used by modules to
replace the open coded irq_to_desc() (ab)usage. The final goal is to remove
the export of irq_to_desc() so driver cannot fiddle with it anymore.
Move it into the core code and fixup the usage sites to include the proper
header.
The irq descriptor is already there, no need to look it up again.
Signed-off-by: Thomas Gleixner
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: afzal mohammed
Cc: linux-par...@vger.kernel.org
---
arch/parisc/kernel/irq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/pa
irq_set_lockdep_class() is used from modules and requires irq_to_desc() to
be exported. Move it into the core code which lifts another requirement for
the export.
Signed-off-by: Thomas Gleixner
---
include/linux/irqdesc.h | 10 --
kernel/irq/irqdesc.c| 14 ++
2 files
A recent request to export kstat_irqs() pointed to a copy of the same in
the i915 code, which made me look for further usage of irq descriptors in
drivers.
The usage in drivers ranges from creative to broken in all colours.
irqdesc.h clearly says that this is core functionality and the fact C doe
Both the per cpu stats and the accumulated count are accessed lockless and
can be concurrently modified. That's intentional and the stats are a rough
estimate anyway. Annotate them with data_race().
Signed-off-by: Thomas Gleixner
---
kernel/irq/irqdesc.c |4 ++--
kernel/irq/proc.c|5
The SMP variant works perfectly fine on UP as well.
Signed-off-by: Thomas Gleixner
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: afzal mohammed
Cc: linux-par...@vger.kernel.org
---
arch/parisc/kernel/irq.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/arch/parisc/kerne
The irq descriptor is already there, no need to look it up again.
Signed-off-by: Thomas Gleixner
Cc: Mark Rutland
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Marc Zyngier
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm64/kernel/smp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Provide an accessor to the effective interrupt affinity mask. Going to be
used to replace open coded fiddling with the irq descriptor.
Signed-off-by: Thomas Gleixner
---
include/linux/irq.h |7 +++
1 file changed, 7 insertions(+)
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -9
Most users of kstat_irqs_cpu() have the irq descriptor already. No point in
calling into the core code and looking it up once more.
Use it in per_cpu_count_show() to start with.
Signed-off-by: Thomas Gleixner
---
include/linux/irqdesc.h |6 ++
kernel/irq/irqdesc.c|4 ++--
2 file
These checks are used by modules and prevent the removal of the export of
irq_to_desc(). Move the accessor into the core.
Signed-off-by: Thomas Gleixner
---
include/linux/irqdesc.h | 17 +
kernel/irq/manage.c | 17 +
2 files changed, 22 insertions(+), 12 d
Hi Stefano,
On 10/12/2020 02:30, Stefano Stabellini wrote:
On Mon, 30 Nov 2020, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
We need to send mapcache invalidation request to qemu/demu everytime
the page gets removed from a guest.
At the moment, the Arm code doesn't explicitely remo
flight 157383 ovmf real [real]
flight 157387 ovmf real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157383/
http://logs.test-lab.xenproject.org/osstest/logs/157387/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-
On Wed, Dec 09, 2020 at 01:22:24PM +0100, Jürgen Groß wrote:
> Lets take the spin_unlock() case. With patch 11 of the series this is
>
> PVOP_ALT_VCALLEE1(lock.queued_spin_unlock, lock,
> "movb $0, (%%" _ASM_ARG1 ");",
> X86_FEATURE_NO_PVUNLOCK);
>
> which boil
On Thu, Dec 10, 2020 at 05:18:39PM +, Andrew Cooper wrote:
> The debugging earlier shows that MMUEXT_SET_LDT has indeed been called.
> Presumably 0xbd00a000 is a plausible virtual address for NetBSD
> to position the LDT?
Yes, it is.
>
> However, Xen finds the mapping not-present w
On 10/12/2020 17:03, Manuel Bouyer wrote:
> On Thu, Dec 10, 2020 at 03:51:46PM +, Andrew Cooper wrote:
>>> [ 7.6617663] cs 0x47 ds 0x23 es 0x23 fs gs ss 0x3f
>>> [ 7.7345663] fsbase 00 gsbase 00
>>>
>>> so it looks like something resets %fs to
On Thu, Dec 10, 2020 at 03:51:46PM +, Andrew Cooper wrote:
> > [ 7.6617663] cs 0x47 ds 0x23 es 0x23 fs gs ss 0x3f
> > [ 7.7345663] fsbase 00 gsbase 00
> >
> > so it looks like something resets %fs to 0 ...
> >
> > Anyway the fault address 0xfff
Add support for ARM architected SMMUv3 implementation. It is based on
the Linux SMMUv3 driver.
Driver is currently supported as Tech Preview.
Major differences with regard to Linux driver are as follows:
2. Only Stage-2 translation is supported as compared to the Linux driver
that supports bot
Replace all Linux compatible device tree handling function with the XEN
functions.
Replace all Linux ktime function with the XEN time functions.
Signed-off-by: Rahul Singh
---
Changes in v3:
- This patch is introduce in this version.
---
xen/drivers/passthrough/arm/smmu-v3.c | 32 +++-
Remove code that is related to below functionality :
1. struct io_pgtable_ops
2. struct io_pgtable_cfg
3. struct iommu_flush_ops,
4. struct iommu_ops
5. module_param_named, MODULE_PARM_DESC, module_platform_driver,
MODULE_*
6. IOMMU domain-types
7. arm_smmu_set_bus_ops
8. iommu_device_s
Import the Linux helper of_property_match_string. This function searches
a string list property and returns the index of a specific string value.
Signed-off-by: Rahul Singh
---
Changes in v3:
- This patch is introduce in this verison.
---
xen/common/device_tree.c | 27
Linux SMMUv3 driver supports both Stage-1 and Stage-2 translations.
As of now only Stage-2 translation support has been tested.
Once Stage-1 translation support is tested this patch can be added.
Signed-off-by: Rahul Singh
---
Changes in v3:
- No change from previous version.
---
xen/drivers/
XArray is not implemented in XEN revert the patch that introduce the
XArray code in SMMUv3 driver.
XArray is added in preparation for sharing some ASIDs with the CPU,
As XEN support only Stage-2 translation, ASID is used for Stage-1
translation there is no consequences of reverting this patch for
Linux SMMUv3 code implements the commands-queue insertion based on
atomic operations implemented in Linux. Atomic functions used by the
commands-queue insertion are not implemented in XEN therefore revert the
patch that implemented the commands-queue insertion based on atomic
operations.
Reverted
Based on tag Linux 5.8.18 commit ab435ce49bd1d02e33dfec24f76955dc1196970b
Directory structure change for the SMMUv3 driver starting from
Linux 5.9, to revert the patches smoothly using the "git revert" command
we decided to choose Linux 5.8.18.
Only difference between latest stable Linux 5.9.12 a
On 10.12.20 10:38, Paul Durrant wrote:
Hi Paul.
-Original Message-
From: Oleksandr
Sent: 09 December 2020 20:36
To: p...@xen.org
Cc: 'Jan Beulich' ; 'Oleksandr Tyshchenko'
;
'Stefano Stabellini' ; 'Julien Grall' ;
'Volodymyr Babchuk'
; 'Andrew Cooper' ;
'George Dunlap'
; 'Ian Jack
This patch series is v3 of the work to add support for the SMMUv3 driver.
Approach taken is to first merge the Linux copy of the SMMUv3 driver
(tag v5.8.18) and then modify the driver to build on XEN.
MSI and PCI ATS functionality are not supported. Code is not tested and
compiled. Code is guarde
Hi Luca,
> On 10 Dec 2020, at 10:42, Luca Fancellu wrote:
>
> On the Cortex A53, when executing in AArch64 state, a load or store
> instruction
> which uses the result of an ADRP instruction as a base register, or which uses
> a base register written by an instruction immediately after an ADRP
Hi Julien,
> On 10 Dec 2020, at 16:30, Julien Grall wrote:
>
>
>
> On 10/12/2020 16:17, Bertrand Marquis wrote:
>> Hi Julien,
>
> Hi Bertrand,
>
>>> On 10 Dec 2020, at 16:05, Julien Grall wrote:
>>>
>>>
>>>
>>> On 10/12/2020 15:48, Bertrand Marquis wrote:
Hi Julien,
> On 9 Dec 2
On 10/12/2020 16:17, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 10 Dec 2020, at 16:05, Julien Grall wrote:
On 10/12/2020 15:48, Bertrand Marquis wrote:
Hi Julien,
On 9 Dec 2020, at 23:09, Julien Grall wrote:
Hi Bertand,
On 09/12/2020 16:30, Bertrand Marquis wrote:
Create
Hi Julien,
> On 10 Dec 2020, at 16:05, Julien Grall wrote:
>
>
>
> On 10/12/2020 15:48, Bertrand Marquis wrote:
>> Hi Julien,
>>> On 9 Dec 2020, at 23:09, Julien Grall wrote:
>>>
>>> Hi Bertand,
>>>
>>> On 09/12/2020 16:30, Bertrand Marquis wrote:
Create a cpuinfo structure for guest a
On 10/12/2020 15:48, Bertrand Marquis wrote:
Hi Julien,
On 9 Dec 2020, at 23:09, Julien Grall wrote:
Hi Bertand,
On 09/12/2020 16:30, Bertrand Marquis wrote:
Create a cpuinfo structure for guest and mask into it the features that
we do not support in Xen or that we do not want to publish
Hi,
> On 10 Dec 2020, at 15:46, Julien Grall wrote:
>
>
>
> On 10/12/2020 02:30, Stefano Stabellini wrote:
>> On Wed, 9 Dec 2020, Julien Grall wrote:
>>> Hi Bertrand,
>>>
>>> On 09/12/2020 16:30, Bertrand Marquis wrote:
Add coprocessor registers definitions for all ID registers trapped
>
Hi,
> On 10 Dec 2020, at 15:45, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 10/12/2020 15:14, Bertrand Marquis wrote:
>> Hi Julien,
>>> On 9 Dec 2020, at 23:03, Julien Grall wrote:
>>>
>>> Hi Bertrand,
>>>
>>> On 09/12/2020 16:30, Bertrand Marquis wrote:
Add definition and entries in cp
On Wed, Dec 09, 2020 at 06:41:03PM -0800, Stefano Stabellini wrote:
> On Wed, 9 Dec 2020, Stefano Stabellini wrote:
> > On Wed, 9 Dec 2020, Wei Liu wrote:
> > > On Tue, Dec 08, 2020 at 05:02:50PM -0800, Stefano Stabellini wrote:
> > > > The pipeline failed because the "fedora-gcc-debug" build faile
On Thu, 2020-12-10 at 14:37 +0100, Jan Beulich wrote:
> On 10.12.2020 14:09, Hongyan Xia wrote:
> > On Mon, 2020-09-28 at 12:44 +0200, Jan Beulich wrote:
> > > Plus finally there's no point sending the request for the local
> > > domain
> > > when the domain acted upon is a different one. If anythi
On 10/12/2020 09:51, Manuel Bouyer wrote:
> On Wed, Dec 09, 2020 at 07:08:41PM +, Andrew Cooper wrote:
>> Oh of course - we don't follow the exit-to-guest path on the way out here.
>>
>> As a gross hack to check that we've at least diagnosed the issue
>> appropriately, could you modify NetBSD t
Hi,
> On 9 Dec 2020, at 23:22, Julien Grall wrote:
>
> Hi,
>
> On 09/12/2020 16:30, Bertrand Marquis wrote:
>> +/* Disable MPAM as xen does not support it */
>
> I am going to be picky :). I think we want to say "hide" rather than
> "disable" because the latter is done differently via the
Hi Julien,
> On 9 Dec 2020, at 23:09, Julien Grall wrote:
>
> Hi Bertand,
>
> On 09/12/2020 16:30, Bertrand Marquis wrote:
>> Create a cpuinfo structure for guest and mask into it the features that
>> we do not support in Xen or that we do not want to publish to guests.
>> Modify some values in
On 10/12/2020 02:30, Stefano Stabellini wrote:
On Wed, 9 Dec 2020, Julien Grall wrote:
Hi Bertrand,
On 09/12/2020 16:30, Bertrand Marquis wrote:
Add coprocessor registers definitions for all ID registers trapped
through the TID3 bit of HSR.
Those are the one that will be emulated in Xen to
Hi Bertrand,
On 10/12/2020 15:14, Bertrand Marquis wrote:
Hi Julien,
On 9 Dec 2020, at 23:03, Julien Grall wrote:
Hi Bertrand,
On 09/12/2020 16:30, Bertrand Marquis wrote:
Add definition and entries in cpuinfo for ID registers introduced in
newer Arm Architecture reference manual:
- ID_PFR
Hi Julien,
> On 9 Dec 2020, at 23:17, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 09/12/2020 16:31, Bertrand Marquis wrote:
>> Activate TID3 bit in HSR register when starting a guest.
>
> s/HSR/HCR/
>
Right, I did it a lot thanks for the review.
I will fix that in V4.
>> This will trap all
1 - 100 of 158 matches
Mail list logo
