rx->status is an int16_t, print it using %d rather than %u in order to
have a meaningful value when the field is negative.
Also use %u rather than %x for rx->offset.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: net...@vger.kern
SPP was used by the grant table v2 code which has been removed in
commit 438b33c7145ca8a5131a30c36d8f59bce119a19a "xen/grant-table:
remove support for V2 tables".
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
---
Cha
From: Julien Grall
Signed-off-by: Julien Grall
Acked-by: Roger Pau Monné
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
---
Changes in v2:
- Add Roger's Acked-by
---
drivers/block/xen-blkfront.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/
From: Julien Grall
Signed-off-by: Julien Grall
Cc: Stefano Stabellini
---
arch/arm/include/asm/xen/page.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 0b579b2..1bee8ca 100644
--- a/arch/arm/include/asm/xen/page.h
as we don't use it later.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Cc: Wei Liu
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
---
Changes in v2:
- Remove the cast to (char *)
- Add David's Reviewed-by
---
drivers/xen/xenbus/xenbus_client.c | 6 +++---
1
://lkml.org/lkml/2015/5/14/533
Cc: Boris Ostrovsky
Cc: David Vrabel
Cc: Ian Campbell
Cc: Konrad Rzeszutek Wilk
Cc: net...@vger.kernel.org
Cc: Roger Pau Monné
Cc: Stefano Stabellini
Cc: Wei Liu
Julien Grall (7):
xen: Include xen/page.h rather than asm/xen/page.h
xen/xenbus: client: Fix
From: Julien Grall
Make the code less confusing to read now that Linux may not have the
same page size as Xen.
Signed-off-by: Julien Grall
Acked-by: Roger Pau Monné
Cc: Konrad Rzeszutek Wilk
---
Changes in v2:
- Add Roger's Acked-by
---
drivers/block/xen-blkback/blkback.c
From: Julien Grall
Since commit b764915 "xen-blkfront: use a different scatterlist for each
request", biovec has been replaced by scatterlist when copying back the
data during a completion request.
Signed-off-by: Julien Grall
Acked-by: Roger Pau Monné
Cc: Konrad Rzeszutek Wilk
Using xen/page.h will be necessary later for using common xen page
helpers.
As xen/page.h already include asm/xen/page.h, always use the later.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
Cc: Konrad Rzeszutek Wilk
Cc: Boris
Hi,
On 23/06/15 14:25, Stefano Stabellini wrote:
> On Thu, 14 May 2015, Julien Grall wrote:
>> From: Julien Grall
>>
>> Signed-off-by: Julien Grall
>> Cc: Stefano Stabellini
>
> Reviewed-by: Stefano Stabellini
FYI, David already queued this patch
This function is PV specific and has been added few months ago just for
a stub. See comment in the code:
"/* Not used by XENFEAT_auto_translated guests */"
Any logging/BUG_ON within this function is out of scope for this series.
And I don't think this will be really useful. Feel fr
> I'll rephrase my question then: What about xen_remap_domain_mfn_array? I
> guess we don't support that use case on 64K guests? If so, I would
> appreaciate an assert and/or an error message.
See https://lkml.org/lkml/2015/5/14/563
--
Julien Grall
--
To unsubscribe from this l
On 04/06/15 17:25, Joe Perches wrote:
> On Thu, 2015-06-04 at 13:52 +0100, Julien Grall wrote:
>> On 04/06/15 13:46, David Vrabel wrote:
>>> On 04/06/15 13:45, Julien Grall wrote:
>>>> On 03/06/15 18:06, Joe Perches wrote:
>>>>> On Wed, 2015-06-03
Cc: net...@vger.kernel.org
[1] http://lkml.org/lkml/2015/5/14/533
Julien Grall (2):
net/xen-netfront: Correct printf format in xennet_get_responses
net/xen-netback: Remove unused code in xenvif_rx_action
drivers/net/xen-netback/netback.c | 5 -
drivers/net/xen-netfront.c| 2
rx->status is an int16_t, print it using %d rather than %u in order to
have a meaningful value when the field is negative.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: net...@vger.kernel.org
---
Changes in v2:
-
The variables old_req_cons and ring_slots_used are assigned but never
used since commit 1650d5455bd2dc6b5ee134bd6fc1a3236c266b5b "xen-netback:
always fully coalesce guest Rx packets".
Signed-off-by: Julien Grall
Acked-by: Wei Liu
Cc: Ian Campbell
Cc: net...@vger.kernel.org
---
On 03/06/15 18:06, Joe Perches wrote:
> On Wed, 2015-06-03 at 17:55 +0100, Julien Grall wrote:
>> rx->status is an int16_t, print it using %d rather than %u in order to
>> have a meaningful value when the field is negative.
> []
>> diff --git a/drivers/net/xen-n
On 04/06/15 13:46, David Vrabel wrote:
> On 04/06/15 13:45, Julien Grall wrote:
>> On 03/06/15 18:06, Joe Perches wrote:
>>> On Wed, 2015-06-03 at 17:55 +0100, Julien Grall wrote:
>>>> rx->status is an int16_t, print it using %d rather than %u in order to
>
Cc: net...@vger.kernel.org
[1] http://lkml.org/lkml/2015/5/14/533
Julien Grall (2):
net/xen-netfront: Correct printf format in xennet_get_responses
net/xen-netback: Remove unused code in xenvif_rx_action
drivers/net/xen-netback/netback.c | 5 -
drivers/net/xen-netfront.c| 2
The variables old_req_cons and ring_slots_used are assigned but never
used since commit 1650d5455bd2dc6b5ee134bd6fc1a3236c266b5b "xen-netback:
always fully coalesce guest Rx packets".
Signed-off-by: Julien Grall
Acked-by: Wei Liu
Cc: Ian Campbell
Cc: net...@vger.kernel.org
---
rx->status is an int16_t, print it using %d rather than %u in order to
have a meaningful value when the field is negative.
Also use %d rather than %x for rx->offset.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: net...@vger.kern
Hi David,
On 19/05/15 16:39, David Vrabel wrote:
> On 14/05/15 18:01, Julien Grall wrote:
>> The hypercall interface (as well as the toolstack) is always using 4KB
>> page granularity. When the toolstack is asking for mapping a series of
>> guest PFN in a batch, it expects
ired.
NIT: Shouldn't you use /* ... */ for multi-line comments?
Regardless that:
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
Hi Marc,
On 05/22/2018 04:06 PM, Marc Zyngier wrote:
In a heterogeneous system, we can end up with both affected and
unaffected CPUs. Let's check their status before calling into the
firmware.
Signed-off-by: Marc Zyngier
Reviewed-by: Julien Grall
Cheers,
---
arch/arm64/k
30
NIT: Could you indent 30 the same way as the other number?
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
ation permanently
on or off instead of switching it on exception entry/exit.
In any case, default to the mitigation being enabled.
Signed-off-by: Marc Zyngier
Reviewed-by: Julien Grall
Cheers,
---
Documentation/admin-guide/kernel-parameters.txt | 17
arch/arm64/include/asm/cpufeat
rc Zyngier
Reviewed-by: Julien Grall
Cheers,
---
arch/arm64/include/asm/cpufeature.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/include/asm/cpufeature.h
b/arch/arm64/include/asm/cpufeature.h
index 9bc548e22784..1bacdf57f0af 100644
--- a/arch/arm64/include/asm/cp
e doing dynamic mitigation.
Think of it as a poor man's static key...
Signed-off-by: Marc Zyngier
Reviewed-by: Julien Grall
Cheers,
---
arch/arm64/kernel/cpu_errata.c | 14 ++
arch/arm64/kernel/entry.S | 3 +++
2 files changed, 17 insertions(+)
diff --git
ine option,
let's enforce it by calling into the firmware again to disable it.
Signed-off-by: Marc Zyngier
Reviewed-by: Julien Grall
Cheers,
---
arch/arm64/include/asm/cpufeature.h | 6 ++
arch/arm64/kernel/cpu_errata.c | 8
arch/arm64/kernel/suspend.c |
get out-of-box display in guest.
Cheers,
--
Julien Grall
On 27/04/18 16:18, Suzuki K Poulose wrote:
On 26/04/18 11:58, Julien Grall wrote:
Hi Suzuki,
On 27/03/18 14:15, Suzuki K Poulose wrote:
Add a helper to convert ID_AA64MMFR0_EL1:PARange to they physical
size shift. Limit the size to the maximum supported by the kernel.
We are about to move
Hi Suzuki,
On 27/04/18 16:58, Suzuki K Poulose wrote:
On 27/04/18 16:22, Suzuki K Poulose wrote:
On 26/04/18 14:35, Julien Grall wrote:
Hi Suzuki,
On 27/03/18 14:15, Suzuki K Poulose wrote:
Right now the stage2 page table for a VM is hard coded, assuming
an IPA of 40bits. As we are about to
+ * descriptors in section D4.2.8 in ARM DDI 0487B.b.
+ *
+ * The algorithm defines the expectaions on the BaseAddress (for the page
NIT: s/expectaions/expectations/
Cheers,
--
Julien Grall
)
+{
+ unsigned max_ipa;
+
+ max_ipa = ioctl(kvm->sys_fd, KVM_ARM_GET_MAX_VM_PHYS_SHIFT);
+ if (max_ipa < 0)
Another issues spotted while doing some testing. This will always be
false because max_ipa is unsigned.
I think we want to turn max_ipa to signed.
Cheers,
--
Julien Grall
return ret;
kvm->arch.last_vcpu_ran = alloc_percpu(typeof(*kvm->arch.last_vcpu_ran));
if (!kvm->arch.last_vcpu_ran)
Cheers,
--
Julien Grall
,
--
Julien Grall
Hi Suzuki,
On 27/03/18 14:15, Suzuki K Poulose wrote:
Make pud_huge reusable for stage2 tables, independent
of the stage1 levels.
Cc: Steve Capper
Cc: Mark Rutland
Cc: Will Deacon
Cc: Catalin Marinas
Cc: Christoffer Dall
Signed-off-by: Suzuki K Poulose
Reviewed-by: Julien Grall
: Julien Grall
Cheers,
---
arch/arm64/include/asm/pgalloc.h | 34 +++
arch/arm64/include/asm/pgtable.h | 60 +---
2 files changed, 66 insertions(+), 28 deletions(-)
diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm
@@ u32 __hyp_text __init_stage2_translation(void)
write_sysreg(val, vtcr_el2);
- return parange;
+ return phys_shift;
}
--
Julien Grall
M_PHYS_SHIFT
+#define kvm_phys_size(kvm) (_AC(1, ULL) << kvm_phys_shift(kvm))
NIT: is the _AC(...) necessary? It does not look like this function is
going to be usable in assembly.
+#define kvm_phys_mask(kvm) (kvm_phys_size(kvm) - _AC(1, ULL))
Same here.
--
Julien Grall
pe other than 0. So I think
the best would be to bail out if KVM_ARM_GET_MAX_VM_PHYS_SHIFT does not
exist.
For safety, you could even check that arch.phys_shift is always 40 when
running under older Linux.
Cheers,
--
Julien Grall
Hi Dave,
On 4/16/19 12:53 PM, Dave Martin wrote:
On Fri, Apr 12, 2019 at 06:14:19PM +0100, Julien Grall wrote:
The only external user of fpsimd_save() and fpsimd_flush_cpu_state() is
the KVM FPSIMD code.
A follow-up patch will mandate hold of the FPSIMD context while
This is a bit hard to
Hi Dave,
On 16/04/2019 13:30, Dave Martin wrote:
On Fri, Apr 12, 2019 at 06:14:20PM +0100, Julien Grall wrote:
When the kernel is compiled with CONFIG_KERNEL_MODE_NEON, some part of
the kernel may be able to use FPSIMD/SVE. This is for instance the case
for crypto code.
Any use of FPSIMD/SVE
The word 'number' has been misspelt in the comment on top of
_irq_domain_alloc_irqs().
Signed-off-by: Julien Grall
---
kernel/irq/irqdomain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 9ed29e4a7dbf..a4
The word 'entirely' has been misspelt in a comment in its_msi_prepare().
Signed-off-by: Julien Grall
---
drivers/irqchip/irq-gic-v3-its.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 75
other does
not have any requirement.
This patch reworks the GICv3 ITS driver to avoid executing preemptible
code in non-preemptible context by preparing the MSI mapping when
allocating the MSI interrupt.
Signed-off-by: Julien Grall
---
drivers/irqchip/irq-gic-v3-its.c | 5 -
1 file changed, 4
Hi Dave,
On 24/04/2019 14:17, Dave Martin wrote:
On Tue, Apr 23, 2019 at 02:57:18PM +0100, Julien Grall wrote:
tent-Length: 4295
Lines: 128
The only external user of fpsimd_save() and fpsimd_flush_cpu_state() is
the KVM FPSIMD code.
A following patch will introduce a mechanism to acquire
Hi Dave,
On 24/04/2019 14:17, Dave Martin wrote:
On Tue, Apr 23, 2019 at 02:57:19PM +0100, Julien Grall wrote:
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 5313aa257be6..6168d06bbd20 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -92,7
Hi Dave,
On 25/04/2019 17:39, Dave Martin wrote:
On Thu, Apr 25, 2019 at 04:57:26PM +0100, Julien Grall wrote:
Hi Dave,
On 24/04/2019 14:17, Dave Martin wrote:
On Tue, Apr 23, 2019 at 02:57:19PM +0100, Julien Grall wrote:
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
Hi David,
On 3/12/19 5:18 PM, David Hildenbrand wrote:
On 12.03.19 18:14, Matthew Wilcox wrote:
On Tue, Mar 12, 2019 at 05:05:39PM +, Julien Grall wrote:
On 3/12/19 3:59 PM, Julien Grall wrote:
It looks like all the arm test for linus [1] and next [2] tree
are now failing. x86 seems to
ll block on the lock
until the request is done. This is okay because the user asked for a
backtrace of all active CPUs and under "normal circumstances in
production" this path should not be triggered.
Signed-off-by: Julien Grall
[bige...@linuxtronix.de: commit description]
Signed-off-by:
Hi Sebastian,
On 3/4/19 5:25 PM, Sebastian Andrzej Siewior wrote:
On 2019-02-18 15:07:51 [+], Julien Grall wrote:
Hi,
Hi,
Wouldn't this arbitrarily increase softirq latency? Unconditionally
forbidding SIMD in softirq might make more sense. It depends on how
important the use case
On 15/03/2019 10:06, Dave Martin wrote:
On Thu, Mar 14, 2019 at 06:07:19PM +, Julien Grall wrote:
Hi Sebastian,
On 3/4/19 5:25 PM, Sebastian Andrzej Siewior wrote:
[...]
It would increase the softirq latency but the question is how bad would
it be. It would continue once the SIMD
Hi John,
On 3/25/19 10:34 AM, John Ogness wrote:
On 2019-03-25, Julien Grall wrote:
[...]
[1.169151] 002: Serial: AMBA PL011 UART driver
[1.254891] 002: 7ff8.uart: ttyAMA0 at MMIO 0x7ff8 (irq = 32,
base_baud = 0) is a PL011 rev3
[1.255007] 002: printk: console [ttyAMA0
Hi Dave,
On 4/4/19 11:52 AM, Dave Martin wrote:
On Fri, Feb 08, 2019 at 04:55:13PM +, Julien Grall wrote:
I'm not sure how this patch will affect context switch overhead, so it
would be good to see hackbench numbers (or similar).
I finally have some numbers for this patch. The benc
Hi Sebastian,
On 4/5/19 4:42 PM, Sebastian Andrzej Siewior wrote:
On 2019-04-05 16:17:50 [+0100], Julien Grall wrote:
Hi,
Hi,
A per-CPU lock? It has to be a raw_spinlock_t because a normal
spin_lock() / local_lock() would allow scheduling and might be taken as
part of the context switch or
Hi Oleksandr,
On 25/02/2019 13:24, Oleksandr Andrushchenko wrote:
On 2/22/19 3:33 PM, Julien Grall wrote:
Hi,
On 22/02/2019 12:38, Oleksandr Andrushchenko wrote:
On 2/20/19 10:46 PM, Julien Grall wrote:
Discussing with my team, a solution that came up would be to introduce one
atomic field
Hi Oleksandr,
On 25/02/2019 14:08, Oleksandr Andrushchenko wrote:
On 2/25/19 3:55 PM, Julien Grall wrote:
Hi Oleksandr,
On 25/02/2019 13:24, Oleksandr Andrushchenko wrote:
On 2/22/19 3:33 PM, Julien Grall wrote:
Hi,
On 22/02/2019 12:38, Oleksandr Andrushchenko wrote:
On 2/20/19 10:46 PM
Hi Roger,
On 26/02/2019 09:44, Roger Pau Monné wrote:
On Tue, Feb 26, 2019 at 09:30:07AM +, Andrew Cooper wrote:
On 26/02/2019 09:14, Roger Pau Monné wrote:
On Mon, Feb 25, 2019 at 01:55:42PM +, Julien Grall wrote:
Hi Oleksandr,
On 25/02/2019 13:24, Oleksandr Andrushchenko wrote
Hi,
On 26/02/2019 10:17, Roger Pau Monné wrote:
On Tue, Feb 26, 2019 at 10:03:38AM +, Julien Grall wrote:
Hi Roger,
On 26/02/2019 09:44, Roger Pau Monné wrote:
On Tue, Feb 26, 2019 at 09:30:07AM +, Andrew Cooper wrote:
On 26/02/2019 09:14, Roger Pau Monné wrote:
On Mon, Feb 25
Hi,
On 2/26/19 11:02 AM, Roger Pau Monné wrote:
On Tue, Feb 26, 2019 at 10:26:21AM +, Julien Grall wrote:
On 26/02/2019 10:17, Roger Pau Monné wrote:
On Tue, Feb 26, 2019 at 10:03:38AM +, Julien Grall wrote:
Hi Roger,
On 26/02/2019 09:44, Roger Pau Monné wrote:
On Tue, Feb 26, 2019
From: Julien Grall
After Commit 3499ba8198cad ("xen: Fix event channel callback via
INTX/GSI"), xenbus_probe() will be called too early on Arm. This will
recent to a guest hang during boot.
If there hang wasn't there, we would have ended up to call
xenbus_probe() twice (the se
Hi Juergen,
On 08/02/2021 13:58, Jürgen Groß wrote:
On 08.02.21 14:09, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 12:31, Jürgen Groß wrote:
On 08.02.21 13:16, Julien Grall wrote:
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021
On 08/02/2021 14:20, Julien Grall wrote:
I believe this will be the case before our "lateeoi" handling is
becoming active (more precise: when our IRQ handler is returning to
handle_fasteoi_irq()), resulting in the possibility of the same race we
are experiencing now.
I am a bi
)
xen_destroy_contiguous_region(phys, order);
- xen_free_coherent_pages(hwdev, size, vaddr, (dma_addr_t)phys, attrs);
+ xen_free_coherent_pages(hwdev, size, vaddr, phys_to_dma(hwdev, phys),
+ attrs);
}
/*
Cheers,
--
Julien Grall
,
xen_virt_to_bus() is implemented as xen_phys_to_bus(virt_to_phys()). Can
you explain how the two are equivalent?
Cheers,
--
Julien Grall
ages(hwdev, size, vaddr, (dma_addr_t)phys, attrs);
Cheers,
--
Julien Grall
!dev_is_dma_coherent(dev));
}
Cheers,
--
Julien Grall
dma_cache_maint(dev, handle, size, GNTTAB_CACHE_INVAL);
else
- dma_cache_maint(handle, size, GNTTAB_CACHE_CLEAN);
+ dma_cache_maint(dev, handle, size, GNTTAB_CACHE_CLEAN);
}
bool xen_arch_need_swiotlb(struct device *dev,
Cheers,
--
Julien Grall
On Thu, 21 May 2020 at 21:08, Stefano Stabellini wrote:
>
> On Thu, 21 May 2020, Julien Grall wrote:
> > > @@ -97,8 +98,7 @@ bool xen_arch_need_swiotlb(struct device *dev,
> > >phys_addr_t phys,
> > >dma_addr_t dev_a
Hi Juergen,
On 15/12/2020 10:20, Jürgen Groß wrote:
On 15.12.20 08:27, Jürgen Groß wrote:
On 14.12.20 22:25, Julien Grall wrote:
Hi Juergen,
When testing Linux 5.10 dom0, I could reliably hit the following
warning with using event 2L ABI:
[ 589.591737] Interrupt for port 34, but
_t
to raw_spinlock_t
Cc: sta...@vger.kernel.org
Fixes: 25da4618af24 ("xen/events: don't unmask an event channel
when an eoi is pending")
Signed-off-by: Luca Fancellu
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
"normal" masking/unmasking from eoi related
masking/unmasking and temporary masking. The event channel should only
be able to generate an interrupt if all flags are cleared.
Cc: sta...@vger.kernel.org
Fixes: 54c9de89895e0a36047 ("xen/events: add a new late EOI evtchn framework")
Repor
t data and
call the handler only if this flag isn't set.
Cc: sta...@vger.kernel.org
Reported-by: Julien Grall
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
Hi Juergen,
On 15/12/2020 10:20, Jürgen Groß wrote:
On 15.12.20 08:27, Jürgen Groß wrote:
On 14.12.20 22:25, Julien Grall wrote:
Hi Juergen,
When testing Linux 5.10 dom0, I could reliably hit the following
warning with using event 2L ABI:
[ 589.591737] Interrupt for port 34, but
(cpu_evtchn_mask, cpu)));
The bit corresponding to the event channel can only be set on a single
CPU. Could we avoid the loop and instead clear the bit while closing the
port?
Cheers,
--
Julien Grall
On 06/02/2021 12:09, Jürgen Groß wrote:
On 06.02.21 12:20, Julien Grall wrote:
Hi Juergen,
On 06/02/2021 10:49, Juergen Gross wrote:
When creating a new event channel with 2-level events the affinity
needs to be reset initially in order to avoid using an old affinity
from earlier usage of
we may want to consider to hold evtchn_rwlock with the write
permission. Although, I am not 100% sure this is going to prevent
everything.
Does my write-up make sense to you?
Cheers,
--
Julien Grall
Hi Juergen,
On 07/02/2021 12:58, Jürgen Groß wrote:
On 06.02.21 19:46, Julien Grall wrote:
Hi Juergen,
On 06/02/2021 10:49, Juergen Gross wrote:
The first three patches are fixes for XSA-332. The avoid WARN splats
and a performance issue with interdomain events.
Thanks for helping to
On 08/02/2021 09:41, Jürgen Groß wrote:
On 08.02.21 10:11, Julien Grall wrote:
Hi Juergen,
On 07/02/2021 12:58, Jürgen Groß wrote:
On 06.02.21 19:46, Julien Grall wrote:
Hi Juergen,
On 06/02/2021 10:49, Juergen Gross wrote:
The first three patches are fixes for XSA-332. The avoid WARN
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien Grall wrote:
... I don't really see how the difference matter here. The idea is to
re-use what's already existing rather than trying to re-invent the
wheel with an extra lock (or whatever we can come
ons;
- p = u->ring_prod;
+ p = READ_ONCE(u->ring_prod);
For consistency, don't you also need the write side in
evtchn_interrupt() to use WRITE_ONCE()?
if (c != p)
break;
--
Julien Grall
or properly
aligned machine-sized stores, WRITE_ONCE() will prevent store tearing."
Cheers,
[1] https://lwn.net/Articles/793253/#Load%20Tearing
Juergen
--
Julien Grall
Hi Juergen,
On 08/02/2021 11:48, Jürgen Groß wrote:
On 08.02.21 12:40, Julien Grall wrote:
On 06/02/2021 10:49, Juergen Gross wrote:
In evtchn_read() use READ_ONCE() for reading the producer index in
order to avoid the compiler generating multiple accesses.
Signed-off-by: Juergen Gross
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien Grall wrote:
... I don't really see how the difference matter here. The idea is
to re-use what's already existing rather t
Hi Juergen,
On 08/02/2021 12:31, Jürgen Groß wrote:
On 08.02.21 13:16, Julien Grall wrote:
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien Grall wrote:
... I don't really se
enough because I haven't found anything
yet preventing a race between evtchn_2l_handle_events9) and
evtchn_2l_bind_vcpu().
So maybe we want to introduce a refcounting (if there is nothing
provided by the IRQ framework) and only unmask when the counter drop to 0.
Any opinions?
Cheers,
onstrate the
> concept?
Hello Stefano and Greg,
Sorry for the late answer. I wrote a simple patch which depend on patch #1.
Let me know if it's the right direction.
Regards,
commit ca55e82bc191678b284792d2f0d200fa1ce08e16
Author: Julien Grall
Date: Fri Mar 14 16:27:01 2014 +
Hi Stefano,
On 25/02/14 04:49, Stefano Stabellini wrote:
Julien, could you please come up with a simple patch to demonstrate the
concept?
Sure. I won't have time to write the patch next week. I will try to send
it as soon as possible.
Cheers,
--
Julien Grall
--
To unsubscribe from
c check
to know if we might need to use swiotlb-xen. The second patch is implementing
the goal of this patch series.
Regards,
Julien Grall (2):
arm/xen: Introduce need_xen_dma_ops and use it in get_dma_ops
arm/xen: Don't use xen DMA ops when the device is protected by an
IOMMU
it's only check if Linux is running as DOM0.
Signed-off-by: Julien Grall
Cc: Russell King
---
arch/arm/include/asm/dma-mapping.h |5 ++---
arch/arm/include/asm/xen/dma-mapping.h | 13 +
arch/arm/include/asm/xen/hypervisor.h |2 --
3 files changed, 15 insert
able which
contains all these devices. The hash table will be used in need_xen_dma_ops
to check if the Xen DMA ops needs to be used for the current device.
Signed-off-by: Julien Grall
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Rob Landley
Cc: Russel
then
> resend it properly if needed.
Linus has merged xen/tip yesterday and building ARM with CONFIG_XEN=y is
now broken.
Is there any plan to push this patch (without the first half of course
:)) or reverting the following commit:
commit 99c8b79d3c165f8e2a6247c14bfa1429e7efe51f
Author
On 04/04/2014 12:41 PM, Julien Grall wrote:
> Linus has merged xen/tip yesterday and building ARM with CONFIG_XEN=y is
> now broken.
My mistake, it's not because of xen/tip, but some other branches.
--
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe
rnel. IMHO, it's acceptable
because Xen on ARM is still on Tech Preview and the hypercall ABI is not yet
freezed.
Signed-off-by: Julien Grall
Cc: Roger Pau Monne
Cc: Konrad Rzeszutek Wilk
Cc: David Vrabel
Cc: Boris Ostrovsky
Cc: Ian Campbell
Cc: Stefano Stabellini
---
This patch i
On 12/03/2013 03:15 PM, Jan Beulich wrote:
>>>> On 03.12.13 at 16:09, Julien Grall wrote:
>> --- a/include/xen/interface/io/blkif.h
>> +++ b/include/xen/interface/io/blkif.h
>> @@ -146,7 +146,7 @@ struct blkif_request_segment_aligned {
>> struc
rnel. IMHO, it's acceptable
because Xen on ARM is still on Tech Preview and the hypercall ABI is not yet
freezed.
Only one architecture (x86_32) doesn't have 64-bit ABI for the block interface.
Don't add padding if Linux is compiled for this architecture.
Signed-off-by: Julien Grall
On 12/03/2013 04:00 PM, One Thousand Gnomes wrote:
> On Tue, 3 Dec 2013 15:40:37 +
> Julien Grall wrote:
>
>> On ARM (32 bits and 64 bits), the double-word is 8-bytes aligned. This will
>> result on different structure from Xen and Linux repositories.
>>
>
Hi David,
On 04/24/2014 01:22 PM, David Vrabel wrote:
> On 18/04/14 16:54, Julien Grall wrote:
>> virt_to_pfn has been defined in asm/memory.h by the commit e26a9e0 "ARM:
>> Better
>> virt_to_page() handling"
>>
>> This will result of a compilation war
The Xen ARM API is stable since Xen 4.4 and everything has been
upstreamed in Linux for ARM and ARM64. Therefore we can drop "EXPERIMENTAL"
from the Xen option in the both Kconfig.
Signed-off-by: Julien Grall
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: lin
101 - 200 of 727 matches
Mail list logo