flight 179527 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179527/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8820767fb3bad09eeedecc3030d75c9e0cd4cab7
baseline version:
ovmf
flight 179522 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179522/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-livepatch 7 xen-install fail in 179513 pass in 179522
test-amd64-i386-xl7
On Thu, Mar 09, 2023 at 10:03:23AM +0100, Jan Beulich wrote:
> On 09.03.2023 00:08, Elliott Mitchell wrote:
> >
> > As such I'm less than certain the problem is still in HEAD, though
> > Neowutran and Co working with 4.16 and the commit log being quiet
> > suggests there is a good chance.
> >
>
flight 179518 qemu-mainline real [real]
flight 179525 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/179518/
http://logs.test-lab.xenproject.org/osstest/logs/179525/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Roger Pau Monné writes:
> On Mon, Dec 12, 2022 at 01:36:48PM +0100, Roger Pau Monné wrote:
>> On Fri, Dec 02, 2022 at 12:40:05PM +0100, Roger Pau Monné wrote:
>> > On Wed, Nov 30, 2022 at 05:08:06PM -0800, Stefano Stabellini wrote:
>> > > On Wed, 30 Nov 2022, Roger Pau Monne wrote:
>> > > > The
On Thu, Mar 02, 2023 at 12:46:05PM -0800, Luis Chamberlain wrote:
> I'm happy to take these via sysctl-next [0] but since
> I don' think register_sysctl_table() will be nuked on v6.4 I think
> it's fine for each of these to go into each respective tree. I can
> pick up last stragglers on
On 09/03/2023 7:34 pm, tachyon_...@web.de wrote:
> Subject:
> [help] Xen 4.14.5 on Devuan 4.0 Chimaera
> From:
> tachyon_...@web.de
> Date:
> 09/03/2023, 7:34 pm
>
> To:
> xen-devel@lists.xenproject.org
>
>
> Hello.
>
> Following the advice of Andrew Cooper (thanks for helping out) over on
>
flight 179516 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179516/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pair25 guest-start/debian fail REGR. vs. 178042
Introduce an install target, like it's used by other tests. This
allows running the test on the installed systems, which is easier than
running it during the build phase when dealing with automated testing.
Strictly speaking the vpci test doesn't require to be run on a Xen
host currently, but
From: Andrei Cherechesu
Added support for parsing the ARM generic timer interrupts DT
node by the "interrupt-names" property, if it is available.
If not available, the usual parsing based on the expected
IRQ order is performed.
Also changed to treating returning 0 as an error case for the
From: Andrei Cherechesu
Moved implementation for the function which parses the IRQs of a DT
node by the "interrupt-names" property from the SMMU-v3 driver
to the IRQ core code and made it non-static to be used as helper.
Also changed it to receive a "struct dt_device_node*" as parameter,
like
From: Andrei Cherechesu
This 2-patch series fixes the parsing of the ARM Generic Timer
interrupts from the device tree.
If the generic timer interrupts order in the DT was different than
the expected order in Xen code, these interrupts would no longer be
correctly parsed and registered by Xen,
Hi Jason,
On mer., mars 08, 2023 at 11:26, Jason Andryuk wrote:
> On Thu, Dec 15, 2022 at 8:54 AM Mattijs Korpershoek
> wrote:
>>
>> On Fri, Dec 09, 2022 at 09:26, Jason Andryuk wrote:
>>
>> > xen kbdfront registers itself as being able to deliver *any* key since
>> > it doesn't know what
flight 179513 xen-unstable real [real]
flight 179519 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/179513/
http://logs.test-lab.xenproject.org/osstest/logs/179519/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Tue, 7 Mar 2023 at 18:27, David Woodhouse wrote:
>
> The following changes since commit 9832009d9dd2386664c15cc70f6e6bfe062be8bd:
>
> Merge tag 'pull-riscv-to-apply-20230306' of
> https://gitlab.com/palmer-dabbelt/qemu into staging (2023-03-07 12:53:00
> +)
>
> are available in the Git
Hi,
> On 9 Mar 2023, at 15:36, Andrei Cherechesu
> wrote:
>
>
>
> On 09/03/2023 15:46, Michal Orzel wrote:
>>
>>
>> On 09/03/2023 13:45, Bertrand Marquis wrote:
>>>
>>>
>>> Hi Michal,
>>>
On 9 Mar 2023, at 13:42, Michal Orzel wrote:
Hi Bertrand,
On 09/03/2023
On Thu, 2023-03-09 at 10:46 +0100, Jan Beulich wrote:
> On 08.03.2023 17:16, Oleksii wrote:
> > On Wed, 2023-03-08 at 16:17 +0100, Jan Beulich wrote:
> > > On 08.03.2023 15:54, Oleksii wrote:
> > > > Actually after my latest experiments it looks that we don't
> > > > need to
> > > > calculate that
On 09/03/2023 15:46, Michal Orzel wrote:
>
>
> On 09/03/2023 13:45, Bertrand Marquis wrote:
>>
>>
>> Hi Michal,
>>
>>> On 9 Mar 2023, at 13:42, Michal Orzel wrote:
>>>
>>> Hi Bertrand,
>>>
>>> On 09/03/2023 13:19, Bertrand Marquis wrote:
Hi Michal,
> On 9 Mar 2023, at
flight 179515 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179515/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass
test-amd64-i386-libvirt 15
On 09.03.2023 14:33, Oleksii Kurochko wrote:
> The following defines BUG_DISP_WIDTH, BUG_LINE_LO_WIDTH,
> BUG_LINE_HI_WIDTH aren't used in ARM so could be purged
> as unused.
Requested-by: Jan Beulich
or (but it's not really a bug)
Reported-by: Jan Beulich
> Signed-off-by: Oleksii Kurochko
On 09/03/2023 13:45, Bertrand Marquis wrote:
>
>
> Hi Michal,
>
>> On 9 Mar 2023, at 13:42, Michal Orzel wrote:
>>
>> Hi Bertrand,
>>
>> On 09/03/2023 13:19, Bertrand Marquis wrote:
>>>
>>>
>>> Hi Michal,
>>>
On 9 Mar 2023, at 12:35, Michal Orzel wrote:
On
A large part of the content of the bug.h is repeated among all
architectures, so it was decided to create a new config
CONFIG_GENERIC_BUG_FRAME.
The version of from x86 was taken as the base version.
The patch introduces the following stuff:
* common bug.h header
* generic implementation of
The idea of the patch is to change all to and
keep Xen compilable with adding only minimal amount of changes:
1. It was added "#include " to ARM's "" as it
uses uint_{16,32}t in 'struct bug_frame'.
2. It was added '#define BUG_FRAME_STRUCT' which means that ARM hasn't
been switched to
The following changes were made:
* make GENERIC_BUG_FRAME mandatory for ARM
* As do_bug_frame() returns -EINVAL in case something goes wrong
otherwise id of bug frame. Thereby 'if' cases where do_bug_frame() was
updated to check if the returned value is less than 0
* Switch ARM's
The following changes were made:
* Make GENERIC_BUG_FRAME mandatory for X86
* Update asm/bug.h using generic implementation in
* Update do_invalid_op using generic do_bug_frame()
* Define BUG_DEBUGGER_TRAP_FATAL to debugger_trap_fatal(X86_EXC_GP,regs)
* type of eip variable was changed to 'const
A large part of the content of the bug.h is repeated among all
architectures (especially x86 and RISCV have the same implementation), so it
was created a new config CONFIG_GENERIC_BUG_FRAME which is used to
introduce generic implementation of do_bug_frame() and move x86's
to with the following
The following defines BUG_DISP_WIDTH, BUG_LINE_LO_WIDTH,
BUG_LINE_HI_WIDTH aren't used in ARM so could be purged
as unused.
Signed-off-by: Oleksii Kurochko
---
xen/arch/arm/include/asm/bug.h | 4
1 file changed, 4 deletions(-)
diff --git a/xen/arch/arm/include/asm/bug.h
flight 179517 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179517/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a0f9628705e35c981ae95376f9ebedf877d09111
baseline version:
ovmf
Hi Michal,
> On 9 Mar 2023, at 13:42, Michal Orzel wrote:
>
> Hi Bertrand,
>
> On 09/03/2023 13:19, Bertrand Marquis wrote:
>>
>>
>> Hi Michal,
>>
>>> On 9 Mar 2023, at 12:35, Michal Orzel wrote:
>>>
>>>
>>>
>>> On 09/03/2023 11:39, Bertrand Marquis wrote:
Hi Michal,
Hi Bertrand,
On 09/03/2023 13:19, Bertrand Marquis wrote:
>
>
> Hi Michal,
>
>> On 9 Mar 2023, at 12:35, Michal Orzel wrote:
>>
>>
>>
>> On 09/03/2023 11:39, Bertrand Marquis wrote:
>>>
>>>
>>> Hi Michal,
>>>
On 9 Mar 2023, at 11:05, Michal Orzel wrote:
On 09/03/2023
Hi Michal,
> On 9 Mar 2023, at 12:35, Michal Orzel wrote:
>
>
>
> On 09/03/2023 11:39, Bertrand Marquis wrote:
>>
>>
>> Hi Michal,
>>
>>> On 9 Mar 2023, at 11:05, Michal Orzel wrote:
>>>
>>>
>>>
>>> On 09/03/2023 09:02, Bertrand Marquis wrote:
Hi Stefano,
>
On 09.03.2023 11:38, Matias Ezequiel Vara Larsen wrote:
> On Wed, Mar 08, 2023 at 03:16:05PM +0100, Jan Beulich wrote:
>> On 08.03.2023 12:54, Matias Ezequiel Vara Larsen wrote:
>>> On Tue, Mar 07, 2023 at 11:12:00AM +0100, Jan Beulich wrote:
On 06.03.2023 15:23, Matias Ezequiel Vara Larsen
On 09/03/2023 11:39, Bertrand Marquis wrote:
>
>
> Hi Michal,
>
>> On 9 Mar 2023, at 11:05, Michal Orzel wrote:
>>
>>
>>
>> On 09/03/2023 09:02, Bertrand Marquis wrote:
>>>
>>>
>>> Hi Stefano,
>>>
On 7 Mar 2023, at 22:02, Stefano Stabellini wrote:
On Tue, 7 Mar 2023,
On Tue, Mar 07, 2023 at 08:42:18AM +, David Woodhouse wrote:
> On Thu, 2023-02-02 at 10:10 +0100, Gerd Hoffmann wrote:
> > > Thanks, Kevin.
> > >
> > > I'd like to get the rest of the Xen platform support in to qemu 8.0
> > > if
> > > possible. Which is currently scheduled for March.
> > >
>
Hello,
It's been 3 months and no reply.
On Mon, Dec 12, 2022 at 01:36:48PM +0100, Roger Pau Monné wrote:
> Hello,
>
> Gentle ping regarding the locking question below.
>
> Thanks, Roger.
>
> On Fri, Dec 02, 2022 at 12:40:05PM +0100, Roger Pau Monné wrote:
> > On Wed, Nov 30, 2022 at
Hi Michal,
> On 9 Mar 2023, at 11:05, Michal Orzel wrote:
>
>
>
> On 09/03/2023 09:02, Bertrand Marquis wrote:
>>
>>
>> Hi Stefano,
>>
>>> On 7 Mar 2023, at 22:02, Stefano Stabellini wrote:
>>>
>>> On Tue, 7 Mar 2023, Bertrand Marquis wrote:
> On 7 Mar 2023, at 11:09, Andrei
On Wed, Mar 08, 2023 at 03:16:05PM +0100, Jan Beulich wrote:
> On 08.03.2023 12:54, Matias Ezequiel Vara Larsen wrote:
> > On Tue, Mar 07, 2023 at 11:12:00AM +0100, Jan Beulich wrote:
> >> On 06.03.2023 15:23, Matias Ezequiel Vara Larsen wrote:
> >>> - Xen shall use the "stats_active" field to
On 09/03/2023 09:02, Bertrand Marquis wrote:
>
>
> Hi Stefano,
>
>> On 7 Mar 2023, at 22:02, Stefano Stabellini wrote:
>>
>> On Tue, 7 Mar 2023, Bertrand Marquis wrote:
On 7 Mar 2023, at 11:09, Andrei Cherechesu (OSS)
wrote:
From: Andrei Cherechesu
Added
On 08.03.2023 18:25, Oleksii wrote:
> On Wed, 2023-03-08 at 16:27 +0100, Jan Beulich wrote:
>> On 07.03.2023 16:50, Oleksii Kurochko wrote:
>>> --- a/xen/arch/arm/include/asm/bug.h
>>> +++ b/xen/arch/arm/include/asm/bug.h
>>> @@ -1,6 +1,8 @@
>>> #ifndef __ARM_BUG_H__
>>> #define __ARM_BUG_H__
On 08.03.2023 17:16, Oleksii wrote:
> On Wed, 2023-03-08 at 16:17 +0100, Jan Beulich wrote:
>> On 08.03.2023 15:54, Oleksii wrote:
>>> Actually after my latest experiments it looks that we don't need to
>>> calculate that things at all because for RISC-V it is used
>>> everywhere
>>> PC-relative
On Tue, Mar 07, 2023 at 05:55:26PM +0100, Jan Beulich wrote:
> On 07.03.2023 15:44, Matias Ezequiel Vara Larsen wrote:
> > On Thu, Feb 23, 2023 at 01:42:08PM +0100, Jan Beulich wrote:
> >> On 23.02.2023 13:16, Matias Ezequiel Vara Larsen wrote:
> >>> On Fri, Feb 17, 2023 at 03:10:53PM +0100, Jan
On 09.03.2023 07:58, osstest service owner wrote:
> flight 179511 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/179511/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-pair25
On 09.03.2023 02:22, Volodymyr Babchuk wrote:
> Jan Beulich writes:
>> On 21.02.2023 00:13, Volodymyr Babchuk wrote:
>>> Stefano Stabellini writes:
On Wed, 31 Aug 2022, Volodymyr Babchuk wrote:
> As pci devices are refcounted now and all list that store them are
> protected by
On 09.03.2023 00:08, Elliott Mitchell wrote:
> On Wed, Mar 08, 2023 at 04:50:51PM +0100, Jan Beulich wrote:
>> On 08.03.2023 16:23, Elliott Mitchell wrote:
>>> Mostly SSIA. As originally identified by "Neowutran", appears Xen's
>>> x2apic wrapper implementation fails with current generation AMD
On 07-03-23, 11:22, Stefan Hajnoczi wrote:
> VHOST_USER_IOTLB_MSG probably isn't necessary because address
> translation is not required. It will also reduce performance by adding
> extra communication.
>
> Instead, you could change the 1 memory region : 1 mmap relationship that
> existing
The same layout is defined twice, once in "single memory region
description" and then in "memory regions description".
Separate out details of memory region from these two and reuse the same
definition later on.
While at it, also rename "memory regions description" to "multiple
memory regions
Hello,
This patchset tries to update the vhost-user protocol to make it support special
memory mapping required in case of Xen hypervisor.
The first patch is mostly cleanup and second one introduces a new xen specific
feature.
V2->V3:
- Remove the extra message and instead update the memory
The current model of memory mapping at the back-end works fine where a
standard call to mmap() (for the respective file descriptor) is enough
before the front-end can start accessing the guest memory.
There are other complex cases though where the back-end needs more
information and simple mmap()
Hi Stefano,
> On 7 Mar 2023, at 22:02, Stefano Stabellini wrote:
>
> On Tue, 7 Mar 2023, Bertrand Marquis wrote:
>>> On 7 Mar 2023, at 11:09, Andrei Cherechesu (OSS)
>>> wrote:
>>>
>>> From: Andrei Cherechesu
>>>
>>> Added support for parsing the ARM generic timer interrupts DT
>>> node by
49 matches
Mail list logo
