flight 156316 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156316/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8cadcaa13d882816052ad4dec77faddd44a1c108
baseline version:
ovmf
On Sat, Oct 31, 2020 at 04:27:58AM +0100, Dario Faggioli wrote:
> On Sat, 2020-10-31 at 03:54 +0100, marma...@invisiblethingslab.com
> wrote:
> > On Sat, Oct 31, 2020 at 02:34:32AM +, Dario Faggioli wrote:
> > (XEN) *** Dumping CPU7 host state: ***
> > (XEN) Xen call trace:
> > (XEN) [] R
On Sat, 2020-10-31 at 03:54 +0100, marma...@invisiblethingslab.com
wrote:
> On Sat, Oct 31, 2020 at 02:34:32AM +, Dario Faggioli wrote:
> (XEN) *** Dumping CPU7 host state: ***
> (XEN) Xen call trace:
> (XEN) [] R _spin_lock+0x35/0x40
> (XEN) [] S on_selected_cpus+0x1d/0xc0
> (XEN) []
On Sat, Oct 31, 2020 at 02:34:32AM +, Dario Faggioli wrote:
> On Tue, 2020-10-27 at 17:06 +0100, Frédéric Pierret wrote:
> >
> > Ok the server got frozen just few minutes after my mail and I got
> > now:
> > 'r': https://gist.github.com/fepitre/78541f555902275d906d627de2420571
> >
> From the
flight 156313 qemu-mainline real [real]
flight 156325 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156313/
http://logs.test-lab.xenproject.org/osstest/logs/156325/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
On Tue, 2020-10-27 at 17:06 +0100, Frédéric Pierret wrote:
>
> Ok the server got frozen just few minutes after my mail and I got
> now:
> 'r': https://gist.github.com/fepitre/78541f555902275d906d627de2420571
>
From the scheduler point of view, things seems fine:
(XEN) sched_smt_power_savings:
On Wed, 2020-10-28 at 08:45 +0100, Jan Beulich wrote:
> On 28.10.2020 03:04, Michał Leszczyński wrote:
>
>
> I have to admit that the log makes me wonder whether this isn't a
> Dom0 internal issue:
>
> > [ 338.968676] watchdog: BUG: soft lockup - CPU#5 stuck for 22s!
> > [sshd:5991]
> > [
A recent thread [1] has exposed a couple of issues with our current way
of handling EXPERT.
1) It is not obvious that "Configure standard Xen features (expert
users)" is actually the famous EXPERT we keep talking about on xen-devel
2) It is not obvious when we need to enable EXPERT to get a
flight 156322 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156322/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 156309 xen-4.12-testing real [real]
flight 156323 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156309/
http://logs.test-lab.xenproject.org/osstest/logs/156323/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
On Thu, 29 Oct 2020, Elliott Mitchell wrote:
> On Wed, Oct 28, 2020 at 05:37:02PM -0700, Stefano Stabellini wrote:
> > On Tue, 27 Oct 2020, Elliott Mitchell wrote:
> > > On Mon, Oct 26, 2020 at 06:44:27PM +, Julien Grall wrote:
> > > > On 26/10/2020 16:03, Elliott Mitchell wrote:
> > > > > On
Hi Stefano,
I just realized the title says "gic-v2" when I also modified "gic-v3". I
will update the title on the next version.
On 24/10/2020 01:45, Stefano Stabellini wrote:
On Fri, 23 Oct 2020, Stefano Stabellini wrote:
On Fri, 23 Oct 2020, Julien Grall wrote:
From: Julien Grall
The
[Cc-ing George as it's often useful having him in the loop when doing
all this math on credits]
On Wed, 2020-10-28 at 03:04 +0100, Michał Leszczyński wrote:
> - 23 paź, 2020 o 6:47, Jürgen Groß jgr...@suse.com napisał(a):
> As I've said before, I'm using RELEASE-4.14.0, this is DELL
Hi Stefano,
On 24/10/2020 01:32, Stefano Stabellini wrote:
On Fri, 23 Oct 2020, Julien Grall wrote:
From: Julien Grall
Imported from Linux commit b6cfb277378ef831c0fa84bcff5049307294adc6:
The BAD_MADT_ENTRY() macro is designed to work for all of the subtables
of the MADT. In the
On Fri, 30 Oct 2020, Julien Grall wrote:
> Hi,
>
> On 30/10/2020 18:28, Stefano Stabellini wrote:
> > On Fri, 30 Oct 2020, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 24/10/2020 01:16, Stefano Stabellini wrote:
> > > > On Fri, 23 Oct 2020, Julien Grall wrote:
> > > > >bool
Hi,
On 30/10/2020 18:28, Stefano Stabellini wrote:
On Fri, 30 Oct 2020, Julien Grall wrote:
Hi Stefano,
On 24/10/2020 01:16, Stefano Stabellini wrote:
On Fri, 23 Oct 2020, Julien Grall wrote:
bool __acpi_unmap_table(const void *ptr, unsigned long size)
{
vaddr_t vaddr =
On Fri, 30 Oct 2020, Julien Grall wrote:
> Hi Stefano,
>
> On 24/10/2020 01:16, Stefano Stabellini wrote:
> > On Fri, 23 Oct 2020, Julien Grall wrote:
> > > bool __acpi_unmap_table(const void *ptr, unsigned long size)
> > > {
> > > vaddr_t vaddr = (vaddr_t)ptr;
> > > +unsigned int
Hi Stefano,
On 24/10/2020 01:16, Stefano Stabellini wrote:
On Fri, 23 Oct 2020, Julien Grall wrote:
bool __acpi_unmap_table(const void *ptr, unsigned long size)
{
vaddr_t vaddr = (vaddr_t)ptr;
+unsigned int idx;
+
+/* We are only handling fixmap address in the arch code */
+
On 29/10/20 23:12, David Laight wrote:
>> https://godbolt.org/z/4dzPbM
>>
>> With -fno-strict-aliasing, the compiler reloads the pointer if you write
>> to the start of what it points to, but not if you write to later
>> elements.
> I guess it assumes that global data doesn't overlap.
Yeah,
flight 156301 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156301/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 151544
test-armhf-armhf-libvirt
flight 156314 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156314/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On Fri, 30 Oct 2020, Takahiro Akashi wrote:
> Hi Stefano,
>
> On Thu, Oct 29, 2020 at 07:03:28PM -0700, Stefano Stabellini wrote:
> > + xen-devel and libxl maintainers
> >
> > In short, there is a regression in libxl with the ARM vuart introduced
> > by moving ARM guests to the PVH build.
> >
>
Hi Oleksandr,
On 30/10/2020 10:44, Oleksandr Andrushchenko wrote:
On 10/20/20 6:25 PM, Rahul Singh wrote:
Add support for ARM architected SMMUv3 implementations. It is based on
the Linux SMMUv3 driver.
Major differences between the Linux driver are as follows:
1. Only Stage-2 translation is
On 30/10/20 12:35, Eduardo Habkost wrote:
>
> What is necessary to make sure we have a CONFIG_XEN=y job in
> gitlab CI? Maybe just including xen-devel in some of the
> container images is enough?
Fedora already has it, but build-system-fedora does not include
x86_64-softmmu.
Paolo
On 05.10.2020 11:49, Paul Durrant wrote:
Just two nits, in case the op is really needed:
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -515,6 +515,14 @@ static int iommu_ctl(
>
> switch ( ctl->op )
> {
> +case
On 05.10.2020 11:49, Paul Durrant wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -2304,7 +2304,9 @@ int domain_relinquish_resources(struct domain *d)
>
> PROGRESS(iommu_pagetables):
>
> -ret = iommu_free_pgtables(d);
> +iommu_free_pgtables(d);
> +
flight 156319 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156319/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 156296 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156296/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
On 05.10.2020 11:49, Paul Durrant wrote:
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -174,15 +174,6 @@ int iommu_domain_init(struct domain *d, unsigned int
> opts)
> hd->node = NUMA_NO_NODE;
> #endif
>
> -ret = arch_iommu_domain_init(d);
> -
Hi Oleksandr,
> On 30 Oct 2020, at 15:02, Oleksandr Andrushchenko
> wrote:
>
> Hi,
>
> On 10/30/20 4:47 PM, Rahul Singh wrote:
>> Hello Oleksandr,
>>
>>> On 30 Oct 2020, at 10:44 am, Oleksandr Andrushchenko
>>> wrote:
>>>
>>> Hi, Rahul!
>>>
>>> On 10/20/20 6:25 PM, Rahul Singh wrote:
On 30.10.20 16:13, Jürgen Groß wrote:
On 30.10.20 16:10, Jan Beulich wrote:
On 30.10.2020 15:25, Juergen Gross wrote:
--- a/xen/include/xen/rwlock.h
+++ b/xen/include/xen/rwlock.h
@@ -65,7 +65,11 @@ static inline int _read_trylock(rwlock_t *lock)
* arch_lock_acquire_barrier().
On 30.10.20 16:10, Jan Beulich wrote:
On 30.10.2020 15:25, Juergen Gross wrote:
--- a/xen/include/xen/rwlock.h
+++ b/xen/include/xen/rwlock.h
@@ -65,7 +65,11 @@ static inline int _read_trylock(rwlock_t *lock)
* arch_lock_acquire_barrier().
*/
if (
On 30.10.2020 15:25, Juergen Gross wrote:
> --- a/xen/include/xen/rwlock.h
> +++ b/xen/include/xen/rwlock.h
> @@ -65,7 +65,11 @@ static inline int _read_trylock(rwlock_t *lock)
> * arch_lock_acquire_barrier().
> */
> if ( likely(_can_read_lock(cnts)) )
> +{
> +
Hi,
On 10/30/20 4:47 PM, Rahul Singh wrote:
> Hello Oleksandr,
>
>> On 30 Oct 2020, at 10:44 am, Oleksandr Andrushchenko
>> wrote:
>>
>> Hi, Rahul!
>>
>> On 10/20/20 6:25 PM, Rahul Singh wrote:
>>> Add support for ARM architected SMMUv3 implementations. It is based on
>>> the Linux SMMUv3
On 30.10.20 15:59, Jan Beulich wrote:
On 30.10.2020 15:24, Juergen Gross wrote:
Even if a spinlock was taken with interrupts on before calling
spin_trylock() with interrupts off is fine, as it can't block.
Add a bool parameter "try" to check_lock() for handling this case.
Remove the call of
On 30.10.2020 15:24, Juergen Gross wrote:
> Even if a spinlock was taken with interrupts on before calling
> spin_trylock() with interrupts off is fine, as it can't block.
>
> Add a bool parameter "try" to check_lock() for handling this case.
>
> Remove the call of check_lock() from
Since we support PKU for HVM guests, the respective insns should also be
recognized by the emulator.
In emul_test_read_cr() instead of further extending the comment to
explain the hex numbers, switch to using X86_CR4_* values.
Signed-off-by: Jan Beulich
---
Hi all,
The proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/k-0Aj+Sxb5SliLWrFRBwx49V/ and you can edit
to add items. Alternatively, you can reply to this mail directly.
Agenda items appreciated a few days before the call: please put your name
besides items if you edit the
Hello Oleksandr,
> On 30 Oct 2020, at 10:44 am, Oleksandr Andrushchenko
> wrote:
>
> Hi, Rahul!
>
> On 10/20/20 6:25 PM, Rahul Singh wrote:
>> Add support for ARM architected SMMUv3 implementations. It is based on
>> the Linux SMMUv3 driver.
>>
>> Major differences between the Linux driver
Even if a spinlock was taken with interrupts on before calling
spin_trylock() with interrupts off is fine, as it can't block.
Add a bool parameter "try" to check_lock() for handling this case.
Remove the call of check_lock() from _spin_is_locked(), as it really
serves no purpose and it can even
Checking whether a lock is consistently used regarding interrupts on
or off is beneficial for rwlocks, too.
So add check_lock() calls to rwlock functions. For this purpose make
check_lock() globally accessible.
Signed-off-by: Juergen Gross
---
xen/common/spinlock.c | 3 +--
This small series fixes two issues with spinlock debug code and adds
lock debug code to rwlocks in order to catch IRQ violations.
Juergen Gross (2):
xen/spinlocks: spin_trylock with interrupts off is always fine
xen/rwlock: add check_lock() handling to rwlocks
xen/common/spinlock.c |
From: Arnd Bergmann
There are hundreds of warnings in a W=2 build about a local
variable shadowing the global 'apic' definition:
arch/x86/kvm/lapic.h:149:65: warning: declaration of 'apic' shadows a global
declaration [-Wshadow]
Avoid this by renaming the global 'apic' variable to the more
Hello Jan,
> On 29 Oct 2020, at 5:16 pm, Jan Beulich wrote:
>
> On 29.10.2020 17:58, Rahul Singh wrote:
>>> On 28 Oct 2020, at 3:13 pm, Rahul Singh wrote:
On 28 Oct 2020, at 11:56 am, Jan Beulich wrote:
On 26.10.2020 18:17, Rahul Singh wrote:
> ---
On Fri, Oct 30, 2020 at 01:30:08PM +, Andrew Cooper wrote:
> On 30/10/2020 12:48, Jan Beulich wrote:
> > On 30.10.2020 13:23, Marek Marczykowski-Górecki wrote:
> >> On Fri, Oct 30, 2020 at 01:08:44PM +0100, Jan Beulich wrote:
> >>> On 30.10.2020 13:03, Frédéric Pierret (fepitre) wrote:
> >>>
>
On 30.10.20 14:38, Jan Beulich wrote:
On 30.10.2020 14:02, Jürgen Groß wrote:
On 30.10.20 13:52, Jan Beulich wrote:
On 30.10.2020 13:27, Jürgen Groß wrote:
On 30.10.20 12:55, Jan Beulich wrote:
On 30.10.2020 12:15, Jürgen Groß wrote:
On 30.10.20 11:57, Julien Grall wrote:
On 30/10/2020
On 30/10/2020 11:33, Rahul Singh wrote:
Hello Julien,
Hi,
On 30 Oct 2020, at 10:05 am, Julien Grall wrote:
On 30/10/2020 09:45, Rahul Singh wrote:
Hello Julien,
On 30 Oct 2020, at 9:21 am, Julien Grall wrote:
Hi,
On 30/10/2020 08:46, Rahul Singh wrote:
Ok Yes when I ported the
On 30.10.2020 14:02, Jürgen Groß wrote:
> On 30.10.20 13:52, Jan Beulich wrote:
>> On 30.10.2020 13:27, Jürgen Groß wrote:
>>> On 30.10.20 12:55, Jan Beulich wrote:
On 30.10.2020 12:15, Jürgen Groß wrote:
> On 30.10.20 11:57, Julien Grall wrote:
>> On 30/10/2020 10:49, Jan Beulich
On 30/10/2020 12:48, Jan Beulich wrote:
> On 30.10.2020 13:23, Marek Marczykowski-Górecki wrote:
>> On Fri, Oct 30, 2020 at 01:08:44PM +0100, Jan Beulich wrote:
>>> On 30.10.2020 13:03, Frédéric Pierret (fepitre) wrote:
>>>
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@
On 30.10.20 13:52, Jan Beulich wrote:
On 30.10.2020 13:27, Jürgen Groß wrote:
On 30.10.20 12:55, Jan Beulich wrote:
On 30.10.2020 12:15, Jürgen Groß wrote:
On 30.10.20 11:57, Julien Grall wrote:
On 30/10/2020 10:49, Jan Beulich wrote:
On 30.10.2020 11:38, Julien Grall wrote:
I think we
On 30.10.2020 13:27, Jürgen Groß wrote:
> On 30.10.20 12:55, Jan Beulich wrote:
>> On 30.10.2020 12:15, Jürgen Groß wrote:
>>> On 30.10.20 11:57, Julien Grall wrote:
On 30/10/2020 10:49, Jan Beulich wrote:
> On 30.10.2020 11:38, Julien Grall wrote:
>> I think we should consider
On 30.10.2020 13:23, Marek Marczykowski-Górecki wrote:
> On Fri, Oct 30, 2020 at 01:08:44PM +0100, Jan Beulich wrote:
>> On 30.10.2020 13:03, Frédéric Pierret (fepitre) wrote:
>>
>>> --- a/xen/arch/x86/Makefile
>>> +++ b/xen/arch/x86/Makefile
>>> @@ -170,6 +170,7 @@ EFI_LDFLAGS +=
On 30/10/2020 12:25, Jan Beulich wrote:
On 30.10.2020 13:08, Julien Grall wrote:
On 30/10/2020 12:00, Jan Beulich wrote:
On 30.10.2020 11:57, Julien Grall wrote:
On 20/10/2020 15:10, Jan Beulich wrote:
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -449,6 +449,13 @@
On 30.10.20 12:55, Jan Beulich wrote:
On 30.10.2020 12:15, Jürgen Groß wrote:
On 30.10.20 11:57, Julien Grall wrote:
On 30/10/2020 10:49, Jan Beulich wrote:
On 30.10.2020 11:38, Julien Grall wrote:
On 22/10/2020 17:17, Jan Beulich wrote:
On 22.10.2020 18:00, Roger Pau Monné wrote:
On
On 30.10.2020 13:08, Julien Grall wrote:
> On 30/10/2020 12:00, Jan Beulich wrote:
>> On 30.10.2020 11:57, Julien Grall wrote:
>>> On 20/10/2020 15:10, Jan Beulich wrote:
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -449,6 +449,13 @@ int
On Fri, Oct 30, 2020 at 01:08:44PM +0100, Jan Beulich wrote:
> On 30.10.2020 13:03, Frédéric Pierret (fepitre) wrote:
>
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -170,6 +170,7 @@ EFI_LDFLAGS += --major-image-version=$(XEN_VERSION)
> > EFI_LDFLAGS +=
On 30.10.2020 13:03, Frédéric Pierret (fepitre) wrote:
> This is for improving reproducible builds.
>
> Signed-off-by: Frédéric Pierret (fepitre)
Acked-by: Jan Beulich
Albeit I'd like to ask for the title to actually mention whose
gzip time stamp it is that gets squashed. Perhaps "xen: don't
On 30.10.2020 13:03, Frédéric Pierret (fepitre) wrote:
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -170,6 +170,7 @@ EFI_LDFLAGS += --major-image-version=$(XEN_VERSION)
> EFI_LDFLAGS += --minor-image-version=$(XEN_SUBVERSION)
> EFI_LDFLAGS += --major-os-version=2
On 30/10/2020 12:00, Jan Beulich wrote:
On 30.10.2020 11:57, Julien Grall wrote:
On 20/10/2020 15:10, Jan Beulich wrote:
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -449,6 +449,13 @@ int evtchn_bind_virq(evtchn_bind_virq_t
spin_unlock_irqrestore(>lock,
This is for improving reproducible builds.
Signed-off-by: Frédéric Pierret (fepitre)
---
xen/common/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 06881d023c..32cd650ba8 100644
--- a/xen/common/Makefile
+++
This is for improving reproducible builds.
Signed-off-by: Frédéric Pierret (fepitre)
---
xen/arch/x86/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index b388861679..f5a529afd5 100644
--- a/xen/arch/x86/Makefile
+++
This two fixes improve reproducibility of resulting Xen binaries
Frédéric Pierret (fepitre) (2):
No insert of the build timestamp into the x86 xen efi binary
xen/common/makefile: remove gzip timestamp
xen/arch/x86/Makefile | 1 +
xen/common/Makefile | 2 +-
2 files changed, 2
flight 156293 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156293/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 155963
test-amd64-i386-xl-qemut-win7-amd64 19
On 30.10.2020 11:57, Julien Grall wrote:
> On 20/10/2020 15:10, Jan Beulich wrote:
>> --- a/xen/common/event_channel.c
>> +++ b/xen/common/event_channel.c
>> @@ -449,6 +449,13 @@ int evtchn_bind_virq(evtchn_bind_virq_t
>>
>> spin_unlock_irqrestore(>lock, flags);
>>
>> +/*
>> +
On 30.10.2020 12:15, Jürgen Groß wrote:
> On 30.10.20 11:57, Julien Grall wrote:
>>
>>
>> On 30/10/2020 10:49, Jan Beulich wrote:
>>> On 30.10.2020 11:38, Julien Grall wrote:
On 22/10/2020 17:17, Jan Beulich wrote:
> On 22.10.2020 18:00, Roger Pau Monné wrote:
>> On Tue, Oct 20, 2020
On Fri, Oct 30, 2020 at 11:29:25AM +0400, Marc-André Lureau wrote:
> On Fri, Oct 30, 2020 at 2:07 AM Eduardo Habkost wrote:
>
> > Make the code more generic and not specific to TYPE_DEVICE.
> >
> > Signed-off-by: Eduardo Habkost
> >
>
> Nice cleanup!, but fails to build atm
>
>
Hi Oleksandr,
2020年10月30日(金) 6:14 Oleksandr Tyshchenko :
>
> Hi Stefano
>
> [sorry for the possible format issue]
>
> On Thu, Oct 29, 2020 at 9:53 PM Stefano Stabellini
> wrote:
>>
>> On Thu, 29 Oct 2020, Oleksandr Tyshchenko wrote:
>> > On Thu, Oct 29, 2020 at 9:42 AM Masami Hiramatsu
>> >
Hello Julien,
> On 30 Oct 2020, at 10:05 am, Julien Grall wrote:
>
>
>
> On 30/10/2020 09:45, Rahul Singh wrote:
>> Hello Julien,
>>> On 30 Oct 2020, at 9:21 am, Julien Grall wrote:
>>>
>>> Hi,
>>>
>>> On 30/10/2020 08:46, Rahul Singh wrote:
Ok Yes when I ported the driver I port the
On 30.10.20 11:57, Julien Grall wrote:
On 30/10/2020 10:49, Jan Beulich wrote:
On 30.10.2020 11:38, Julien Grall wrote:
On 22/10/2020 17:17, Jan Beulich wrote:
On 22.10.2020 18:00, Roger Pau Monné wrote:
On Tue, Oct 20, 2020 at 04:10:09PM +0200, Jan Beulich wrote:
---
Hi Jan,
On 20/10/2020 15:10, Jan Beulich wrote:
There's no need to serialize all sending of vIRQ-s; all that's needed
is serialization against the closing of the respective event channels
(so far by means of a barrier). To facilitate the conversion, switch to
an ordinary write locked region in
On 30/10/2020 10:49, Jan Beulich wrote:
On 30.10.2020 11:38, Julien Grall wrote:
On 22/10/2020 17:17, Jan Beulich wrote:
On 22.10.2020 18:00, Roger Pau Monné wrote:
On Tue, Oct 20, 2020 at 04:10:09PM +0200, Jan Beulich wrote:
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@
On 30.10.2020 11:38, Julien Grall wrote:
> On 22/10/2020 17:17, Jan Beulich wrote:
>> On 22.10.2020 18:00, Roger Pau Monné wrote:
>>> On Tue, Oct 20, 2020 at 04:10:09PM +0200, Jan Beulich wrote:
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -177,9 +177,16 @@ int
Hi, Rahul!
On 10/20/20 6:25 PM, Rahul Singh wrote:
> Add support for ARM architected SMMUv3 implementations. It is based on
> the Linux SMMUv3 driver.
>
> Major differences between the Linux driver are as follows:
> 1. Only Stage-2 translation is supported as compared to the Linux driver
>
On 30/10/2020 10:42, Jan Beulich wrote:
On 30.10.2020 11:21, Julien Grall wrote:
On 20/10/2020 15:08, Jan Beulich wrote:
Having a FIFO specific header is not (or at least no longer) warranted
with just three function declarations left there. Introduce a private
header instead, moving there
On 30.10.2020 11:21, Julien Grall wrote:
> On 20/10/2020 15:08, Jan Beulich wrote:
>> Having a FIFO specific header is not (or at least no longer) warranted
>> with just three function declarations left there. Introduce a private
>> header instead, moving there some further items from xen/event.h.
flight 156294 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156294/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c26e291375d1808a0ec5af9002dd0ebca5959020
baseline version:
ovmf
Hi Jan,
On 22/10/2020 17:17, Jan Beulich wrote:
On 22.10.2020 18:00, Roger Pau Monné wrote:
On Tue, Oct 20, 2020 at 04:10:09PM +0200, Jan Beulich wrote:
The per-vCPU virq_lock, which is being held anyway, together with there
not being any call to evtchn_port_set_pending() when
On 30/10/2020 07:40, Mauro Carvalho Chehab wrote:
Several entries at the stable ABI files won't parse if we pass
them directly to the ReST output.
Adjust them, in order to allow adding their contents as-is at
the stable ABI book.
Signed-off-by: Mauro Carvalho Chehab
---
Hi Jan,
On 20/10/2020 15:08, Jan Beulich wrote:
Having a FIFO specific header is not (or at least no longer) warranted
with just three function declarations left there. Introduce a private
header instead, moving there some further items from xen/event.h.
Signed-off-by: Jan Beulich
Acked-by:
Hi Jan,
On 20/10/2020 15:08, Jan Beulich wrote:
There's no global lock around the updating of this global piece of data.
Make use of cmpxchgptr() to avoid two entities racing with their
updates.
While touching the functionality, mark xen_consumers[] read-mostly (or
else the if() condition
Em Fri, 30 Oct 2020 10:19:12 +0100
Fabrice Gasnier escreveu:
> Hi Mauro,
>
> [...]
>
> >
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_count_quadrature_mode_available
> > +KernelVersion: 4.12
> > +Contact: benjamin.gaign...@st.com
> > +Description:
> > +
On 30/10/2020 09:45, Rahul Singh wrote:
Hello Julien,
On 30 Oct 2020, at 9:21 am, Julien Grall wrote:
Hi,
On 30/10/2020 08:46, Rahul Singh wrote:
Ok Yes when I ported the driver I port the command queue operation from the
previous commit where atomic operations is not used and rest all
Hello Julien,
> On 30 Oct 2020, at 9:21 am, Julien Grall wrote:
>
> Hi,
>
> On 30/10/2020 08:46, Rahul Singh wrote:
>> Ok Yes when I ported the driver I port the command queue operation from the
>> previous commit where atomic operations is not used and rest all the code is
>> from the
flight 156291 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156291/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 156254
On 10/30/20 8:40 AM, Mauro Carvalho Chehab wrote:
> Some files over there won't parse well by Sphinx.
>
> Fix them.
>
> Acked-by: Jonathan Cameron # for IIO
> Signed-off-by: Mauro Carvalho Chehab
> ---
> .../ABI/testing/configfs-spear-pcie-gadget| 36 +--
>
Hi,
On 30/10/2020 08:46, Rahul Singh wrote:
Ok Yes when I ported the driver I port the command queue operation from the
previous commit where atomic operations is not used and rest all the code is
from the latest code. I will again make sure that any bug that is fixed in
Linux should be
Hello Stefano,
> On 29 Oct 2020, at 8:17 pm, Stefano Stabellini wrote:
>
> On Thu, 29 Oct 2020, Bertrand Marquis wrote:
>>> On 28 Oct 2020, at 19:12, Julien Grall wrote:
>>> On 26/10/2020 11:03, Rahul Singh wrote:
Hello Julien,
> On 23 Oct 2020, at 4:19 pm, Julien Grall wrote:
>
HI Stefano,
> On 29 Oct 2020, at 20:17, Stefano Stabellini wrote:
>
> On Thu, 29 Oct 2020, Bertrand Marquis wrote:
>>> On 28 Oct 2020, at 19:12, Julien Grall wrote:
>>> On 26/10/2020 11:03, Rahul Singh wrote:
Hello Julien,
> On 23 Oct 2020, at 4:19 pm, Julien Grall wrote:
> On
> On 29 Oct 2020, at 23:32, Stefano Stabellini wrote:
>
> On Thu, 29 Oct 2020, Bertrand Marquis wrote:
>> Hi Julien,
>>
>>> On 28 Oct 2020, at 18:39, Julien Grall wrote:
>>>
>>> Hi Bertrand,
>>>
>>> On 26/10/2020 16:21, Bertrand Marquis wrote:
When a Cortex A57 processor is affected
On Fri, Oct 30, 2020 at 2:10 AM Eduardo Habkost wrote:
> Every single qdev property setter function manually checks
> dev->realized. We can just check dev->realized inside
> qdev_property_set() instead.
>
> The check is being added as a separate function
> (qdev_prop_allow_set()) because it
Several entries at the stable ABI files won't parse if we pass
them directly to the ReST output.
Adjust them, in order to allow adding their contents as-is at
the stable ABI book.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/stable/firewire-cdev| 4 +
On Fri, Oct 30, 2020 at 11:29 AM Marc-André Lureau <
marcandre.lur...@gmail.com> wrote:
>
>
> On Fri, Oct 30, 2020 at 2:07 AM Eduardo Habkost
> wrote:
>
>> Make the code more generic and not specific to TYPE_DEVICE.
>>
>> Signed-off-by: Eduardo Habkost
>>
>
> Nice cleanup!, but fails to build
On Fri, Oct 30, 2020 at 2:07 AM Eduardo Habkost wrote:
> Make the code more generic and not specific to TYPE_DEVICE.
>
> Signed-off-by: Eduardo Habkost
>
Nice cleanup!, but fails to build atm
../hw/block/xen-block.c:403:9: error: ‘dev’ undeclared (first use in this
function); did you mean
Em Thu, 29 Oct 2020 14:49:12 +
Jonathan Cameron escreveu:
> On Wed, 28 Oct 2020 15:23:18 +0100
> Mauro Carvalho Chehab wrote:
>
> > From: Mauro Carvalho Chehab
> >
> > Some files over there won't parse well by Sphinx.
> >
> > Fix them.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> >
94 matches
Mail list logo
