On 18.01.2024 18:45, Roger Pau Monné wrote:
> On Mon, Jan 15, 2024 at 03:34:56PM +0100, Jan Beulich wrote:
>> @@ -625,7 +627,7 @@ ENTRY(dom_crash_sync_extable)
>>
>> /* No special register assumptions. */
>> #ifdef CONFIG_PV
>> -ENTRY(continue_pv_domain)
>> +FUNC(continue_pv_domain)
>>
Hi Anthony,
On 18/01/2024 18:37, Anthony PERARD wrote:
>
>
> On Thu, Jan 18, 2024 at 02:12:21PM +0100, Jan Beulich wrote:
>> On 18.01.2024 13:06, Michal Orzel wrote:
>>> At the moment, trying to run xencov read/reset (calling SYSCTL_coverage_op
>>> under the hood) results in a crash. This is due
On Thu, 2024-01-18 at 12:03 +0100, Jan Beulich wrote:
> On 22.12.2023 16:12, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-generic/bitops/bitops-bits.h
> > @@ -0,0 +1,10 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef _ASM_GENERIC_BITOPS_BITS_H_
> > +#define _ASM_G
On 19.01.2024 10:09, Oleksii wrote:
> On Thu, 2024-01-18 at 12:03 +0100, Jan Beulich wrote:
>> On 22.12.2023 16:12, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/include/asm-generic/bitops/bitops-bits.h
>>> @@ -0,0 +1,10 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +#ifndef _ASM_GEN
On Thu, 2024-01-18 at 12:01 +0100, Jan Beulich wrote:
> On 18.01.2024 10:43, Oleksii wrote:
> > On Wed, 2024-01-17 at 14:42 +0100, Jan Beulich wrote:
> > > On 17.01.2024 12:37, Oleksii wrote:
> > > > > > >
> > > > > > > > > Also you want to make sure asm-generic/bitops/bitops-
> > > > > > > > > bi
On 19.01.2024 10:16, Oleksii wrote:
> On Thu, 2024-01-18 at 12:01 +0100, Jan Beulich wrote:
>> On 18.01.2024 10:43, Oleksii wrote:
>>> On Wed, 2024-01-17 at 14:42 +0100, Jan Beulich wrote:
On 17.01.2024 12:37, Oleksii wrote:
>> Also you want to make sure asm-generic/bitops/bit
On Fri, 2024-01-19 at 10:14 +0100, Jan Beulich wrote:
> On 19.01.2024 10:09, Oleksii wrote:
> > On Thu, 2024-01-18 at 12:03 +0100, Jan Beulich wrote:
> > > On 22.12.2023 16:12, Oleksii Kurochko wrote:
> > > > --- /dev/null
> > > > +++ b/xen/include/asm-generic/bitops/bitops-bits.h
> > > > @@ -0,0 +
flight 184403 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184403/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0223bdd4e40975c427616761fb13c9454461b64d
baseline version:
ovmf 9d3fe85fcc8ff386ee081
On Mon, Jan 15, 2024 at 03:34:56PM +0100, Jan Beulich wrote:
> Use the generic framework in xen/linkage.h.
>
> For switch_to_kernel() and restore_all_guest() so far implicit alignment
> (from being first in their respective sections) is being made explicit
> (as in: using FUNC() without 2nd argume
flight 184398 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184398/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail blocked in
184388
test-amd64-amd64-xl-qemuu-win7-am
On Fri, Jan 19, 2024 at 03:44:35PM +0800, Patrick Plenefisch wrote:
>On Thu, Jan 18, 2024 at 7:41 AM Roger Pau Monné
><[1]roger@citrix.com> wrote:
>
> From that environment (PVH dom0) can you see if you can dump the
> contents of the VFCT table? I don't have a system with th
On Mon, Jan 15, 2024 at 03:40:19PM +0100, Jan Beulich wrote:
> Leverage the new infrastructure in xen/linkage.h to also switch to per-
> function sections (when configured), deriving the specific name from the
> "base" section in use at the time FUNC() is invoked.
>
> Signed-off-by: Jan Beulich
>
> kasprintf() returns a pointer to dynamically allocated memory
> which can be NULL upon failure. Ensure the allocation was successful
> by checking the pointer validity.
…
> ---
> Changes in v3:
> - Remove rc initialization
> - Simply error paths by adding a new label 'fail_mem'
…
I becam
On Fri, Jan 19, 2024 at 02:44:35AM -0500, Patrick Plenefisch wrote:
> On Thu, Jan 18, 2024 at 7:41 AM Roger Pau Monné
> wrote:
>
> >
> > From that environment (PVH dom0) can you see if you can dump the
> > contents of the VFCT table? I don't have a system with that table, so
> > not sure if this
Tracing DPRINTFs to stderr might not be desired. A developer that relies
on tracepoints should be able to opt-in to each tracepoint and rely on
QEMU's log redirection, instead of stderr by default.
This commit converts DPRINTFs in this file that are used for tracing
into tracepoints.
Signed-off-b
According to the QEMU Coding Style document:
> Do not use printf(), fprintf() or monitor_printf(). Instead, use
> error_report() or error_vreport() from error-report.h. This ensures the
> error is reported in the right place (current monitor or stderr), and in
> a uniform format.
> Use error_print
Tracing DPRINTFs to stderr might not be desired. A developer that relies
on tracepoints should be able to opt-in to each tracepoint and rely on
QEMU's log redirection, instead of stderr by default.
This commit converts DPRINTFs in this file that are used for tracing
into tracepoints.
Signed-off-b
On Thu, Jan 18, 2024 at 01:23:56AM -0500, Patrick Plenefisch wrote:
> On Wed, Jan 17, 2024 at 3:46 AM Jan Beulich wrote:
> > On 17.01.2024 07:12, Patrick Plenefisch wrote:
> > > As someone who hasn't built a kernel in over a decade, should I figure
> > out
> > > how to do a kernel build with CONFI
On Mon, Jan 15, 2024 at 02:43:08PM -0500, Stewart Hildebrand wrote:
> From: Oleksandr Andrushchenko
>
> Use the per-domain PCI read/write lock to protect the presence of the
> pci device vpci field. This lock can be used (and in a few cases is used
> right away) so that vpci removal can be perfor
On Tue, Jan 16, 2024 at 10:01:24PM -0500, Stewart Hildebrand wrote:
> On 1/15/24 14:44, Stewart Hildebrand wrote:
> > diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> > index feccd070ddd0..8483404c5e91 100644
> > --- a/xen/drivers/vpci/header.c
> > +++ b/xen/drivers/vpci/header.
On 19.01.2024 14:40, Marek Marczykowski-Górecki wrote:
> On Thu, Jan 18, 2024 at 01:23:56AM -0500, Patrick Plenefisch wrote:
>> On Wed, Jan 17, 2024 at 3:46 AM Jan Beulich wrote:
>>> On 17.01.2024 07:12, Patrick Plenefisch wrote:
As someone who hasn't built a kernel in over a decade, should I
flight 184401 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184401/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184389
test-armhf-armhf-libvirt-qcow2 15 saveres
From: Oleksandr Andrushchenko
Take into account guest's BAR view and program its p2m accordingly:
gfn is guest's view of the BAR and mfn is the physical BAR value.
This way hardware domain sees physical BAR values and guest sees
emulated ones.
Hardware domain continues getting the BARs identity
On Fri, Jan 19, 2024 at 02:50:38PM +0100, Jan Beulich wrote:
> On 19.01.2024 14:40, Marek Marczykowski-Górecki wrote:
> > On Thu, Jan 18, 2024 at 01:23:56AM -0500, Patrick Plenefisch wrote:
> >> On Wed, Jan 17, 2024 at 3:46 AM Jan Beulich wrote:
> >>> On 17.01.2024 07:12, Patrick Plenefisch wrote:
On Fri, Jan 19, 2024 at 09:43:30AM +0100, Michal Orzel wrote:
> Is my understanding correct that by switching from extra-y to targets we are
> preventing these objects to
> appear in non-init-objects (and thus having COV_FLAGS appended) while
> retaining the proper if_changed behavior?
>
> Accor
[Public]
> -Original Message-
> From: Huang, Ray
> Sent: Friday, January 19, 2024 4:55 AM
> To: Patrick Plenefisch
> Cc: Roger Pau Monné ; Jan Beulich
> ; xen-devel@lists.xenproject.org; Juergen Gross
> ; Chen, Jiqian ; Deucher,
> Alexander
> Subject: Re: ACPI VFCT table too short on PV
On Tue, Jan 9, 2024 at 11:28 PM Roger Pau Monné wrote:
>
> On Tue, Jan 09, 2024 at 12:13:04PM +0100, Niklas Hallqvist wrote:
> > > On 14 Dec 2022, at 07:16, G.R. wrote:
...
> > > Hi Roger,
> > > Just another query of the latest status. It'll be great if you can
> > > share a link to the upstream
Hi Yann,
See my reply below
On Thu, Jan 18, 2024 at 10:09 AM Yann Dirson wrote:
> Hi all,
>
> On 1/17/24 18:10, Kelly Choi wrote:
> > Hi everyone,
> >
> > I've spent a bit of time talking to various individuals and the advisory
> > board about setting up a new Community Process Group.
> >
> > A
On 19/1/24 14:24, Manos Pitsidianakis wrote:
According to the QEMU Coding Style document:
Do not use printf(), fprintf() or monitor_printf(). Instead, use
error_report() or error_vreport() from error-report.h. This ensures the
error is reported in the right place (current monitor or stderr), an
On Tue, 2024-01-16 at 17:48 +0100, Jan Beulich wrote:
> (reducing Cc list)
>
> On 16.01.2024 17:32, Oleksii wrote:
> > Please reply with items you would like to see in 4.19 so that
> > people
> > know what is happening and prioritize accordingly.
> > You're welcome to provide a description and use
flight 184402 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184402/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184396
test-amd64-amd64-xl-qemut-win7-amd64
On Sun, Jan 14, 2024 at 10:54:24PM +0100, Paul Leiber wrote:
>
> Am 22.10.2023 um 07:42 schrieb Paul Leiber:
> > Am 13.10.2023 um 20:56 schrieb Paul Leiber:
> >> Hi Xen developers list,
> >>
> >> TL;DR:
> >> --
> >>
> >> Causing certain web server traffic on a secondary VLAN on Raspberry Pi
>
flight 184404 xen-unstable real [real]
flight 184406 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184404/
http://logs.test-lab.xenproject.org/osstest/logs/184406/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armh
flight 184405 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184405/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184402
test-amd64-amd64-xl-qemut-win7-amd64
flight 184408 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184408/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5d016fe0a061647ed29562c9f161e454b0f7f9dd
baseline version:
ovmf 0223bdd4e40975c427616
35 matches
Mail list logo
