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
> > S
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 ‘vde
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 at
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 +
Documentation/ABI/st
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 will
> 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 b
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 23/
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:
> O
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 fixed
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 +--
> Documentation/ABI/testing/confi
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
test-amd64-amd64-xl-qemuu-win7-amd64
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 latest
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
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:
> > + Rea
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 could
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:
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
---
Documentation/ABI/
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 v->virq_to_evtch
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 3b87d728742fe58f427f4
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.
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 s
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
> tha
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 evtc
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
@@ -
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 e
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:
--- a/xen/include/xen/eve
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 c
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
>> > wr
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
>
> ../hw/block/xen
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 a
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(&chn->lock, flags);
>>
>> +/*
>> +
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
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 insertions(+)
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
+++ b/xen/commo
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
+++ b/xen/arch/x86/Make
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 --minor-os-v
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(&chn->lock
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
h
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 += --minor-image-vers
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 evtchn_bind_virq(evtch
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 Tue,
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 @@ i
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 += --major-image-ver
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 Juergen
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 shou
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.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 wrot
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 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 10:4
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:
> --- a/xen/drivers/passthrough/pci.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 des
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 l
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 +--
xen/include/xe
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 | 17
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 document.
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 ar
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
--- a/tools/tests/x86_emulator/test_x86_e
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 _spin_is_lock
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 ch
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 driver
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)) )
> +{
> +
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 ( likely(_can_read
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().
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 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);
> -
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
test-amd64-i386-xl-
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 1
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);
> +
>
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 XEN_DOMCTL_IOMMU_SET_ALLOCATION:
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
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 su
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.
> >
>
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
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
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, settin
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 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 id
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 = (vaddr_t
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 __acpi_unm
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 A
[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 PowerEdg
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 len
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 M
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
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 1
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 speci
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]
> > [ 346.
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: dis
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 be
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 s
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 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 _s
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 c26e291375d1808a0ec5a
94 matches
Mail list logo
