On 20.05.2022 01:22, Demi Marie Obenour wrote:
> It is well known that mapping and unmapping grants is expensive, which
> is why blkback has persistent grants. Could this cost be mitigated by
> batching, and if it was, would it affect the tradeoff of memcpy() vs
> grant table operations?
Which ba
On 19.05.2022 17:09, Demi Marie Obenour wrote:
> On Thu, May 19, 2022 at 04:55:10PM +0200, Jan Beulich wrote:
>> On 19.05.2022 16:45, Demi Marie Obenour wrote:
>>> On Thu, May 19, 2022 at 12:32:33PM +0200, Jan Beulich wrote:
On 18.05.2022 19:32, Demi Marie Obenour wrote:
> +/*
> +
flight 170590 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170590/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 20.05.2022 06:43, Chuck Zmudzinski wrote:
> On 5/4/22 5:14 AM, Juergen Gross wrote:
>> On 04.05.22 10:31, Jan Beulich wrote:
>>> On 03.05.2022 15:22, Juergen Gross wrote:
Some drivers are using pat_enabled() in order to test availability of
special caching modes (WC and UC-). This will
On 5/20/22 12:43 AM, Chuck Zmudzinski wrote:
On 5/4/22 5:14 AM, Juergen Gross wrote:
On 04.05.22 10:31, Jan Beulich wrote:
On 03.05.2022 15:22, Juergen Gross wrote:
Some drivers are using pat_enabled() in order to test availability of
special caching modes (WC and UC-). This will lead to false
flight 170581 linux-linus real [real]
flight 170591 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/170581/
http://logs.test-lab.xenproject.org/osstest/logs/170591/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
On 5/4/22 5:14 AM, Juergen Gross wrote:
On 04.05.22 10:31, Jan Beulich wrote:
On 03.05.2022 15:22, Juergen Gross wrote:
Some drivers are using pat_enabled() in order to test availability of
special caching modes (WC and UC-). This will lead to false negatives
in case the system was booted e.g.
flight 170588 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170588/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170587 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170587/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170578 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170578/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-xsm 7 xen-install fail like 170561
test-amd64-amd64-xl-qemuu-win7-amd6
flight 170585 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170585/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 5/19/22 10:15 PM, Chuck Zmudzinski wrote:
On 5/3/22 9:22 AM, Juergen Gross wrote:
Some drivers are using pat_enabled() in order to test availability of
special caching modes (WC and UC-). This will lead to false negatives
in case the system was booted e.g. with the "nopat" variant and the
BIO
On 5/3/22 9:22 AM, Juergen Gross wrote:
Some drivers are using pat_enabled() in order to test availability of
special caching modes (WC and UC-). This will lead to false negatives
in case the system was booted e.g. with the "nopat" variant and the
BIOS did setup the PAT MSR supporting the queried
flight 170584 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170584/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
> From: Jan Beulich
> Sent: Wednesday, May 18, 2022 6:26 PM
>
> On 10.05.2022 16:30, Roger Pau Monné wrote:
> > On Mon, Apr 25, 2022 at 10:42:50AM +0200, Jan Beulich wrote:
> >> When a page table ends up with no present entries left, it can be
> >> replaced by a non-present entry at the next highe
> From: Tamas K Lengyel
> Sent: Wednesday, May 18, 2022 11:02 PM
>
> On Thu, May 12, 2022 at 9:47 AM Tamas K Lengyel
> wrote:
> >
> > On Wed, May 4, 2022 at 9:12 AM Tamas K Lengyel
> wrote:
> > >
> > > On Wed, Apr 27, 2022 at 11:51 AM Tamas K Lengyel
> > > wrote:
> > > >
> > > > Add monitor ev
> From: Jan Beulich
> Sent: Thursday, May 19, 2022 8:20 PM
>
> On 22.04.2022 11:58, Jan Beulich wrote:
> > EPT is of no interest when !HVM. While I'm observing gcc11 to fully
> > eliminate the function, older gcc's DCE looks to not be as good. Aid the
> > compiler in eliminating the accesses of o
flight 170583 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170583/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 05/15/22 at 07:47pm, Guilherme G. Piccoli wrote:
> On 12/05/2022 11:03, Petr Mladek wrote:
..
> > OK, the question is how to make it better. Let's start with
> > a clear picture of the problem:
> >
> > 1. panic() has basically two funtions:
> >
> > + show/store debug information (op
It is well known that mapping and unmapping grants is expensive, which
is why blkback has persistent grants. Could this cost be mitigated by
batching, and if it was, would it affect the tradeoff of memcpy() vs
grant table operations?
Alternatively, would there be any interest in an “unsafe” mode
flight 170582 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170582/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170580 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170580/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170566 linux-linus real [real]
flight 170579 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/170566/
http://logs.test-lab.xenproject.org/osstest/logs/170579/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
flight 170577 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170577/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170576 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170576/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170563 xen-unstable real [real]
flight 170575 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/170563/
http://logs.test-lab.xenproject.org/osstest/logs/170575/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On 2022-05-19 05:19, Guilherme G. Piccoli wrote:
On 18/05/2022 19:17, Scott Branden wrote:
Hi Guilherme,
+Desmond
[...]
I'm afraid it breaks kdump if this device is not reset beforehand - it's
a doorbell write, so not high risk I think...
But in case the not-reset device can be probed norma
flight 170574 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170574/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Mon, May 16, 2022 at 08:48:17AM +0200, Juergen Gross wrote:
> On 14.05.22 17:55, Demi Marie Obenour wrote:
> > In https://github.com/QubesOS/qubes-issues/issues/7481, a user reported
> > that Xorg locked up when resizing a VM window. While I do not have the
> > same hardware the user does and t
flight 170573 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170573/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170561 qemu-mainline real [real]
flight 170571 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/170561/
http://logs.test-lab.xenproject.org/osstest/logs/170571/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
flight 170572 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170572/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Make the do_memory_op function accessible to tools linking with libxc.
Similar functions are already available for both domctl and sysctl. As part
of this patch we also change the input 'cmd' to be unsigned int to accurately
reflect what the hypervisor expects.
Signed-off-by: Tamas K Lengyel
---
On 18.05.22 14:05, Anthony PERARD wrote:
Hello Anthony
On Tue, May 03, 2022 at 08:26:03PM +0300, Oleksandr Tyshchenko wrote:
From: Julien Grall
This patch introduces helpers to allocate Virtio MMIO params
(IRQ and memory region) and create specific device node in
the Guest device-tree wit
flight 170570 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170570/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Mon, May 16, 2022 at 10:00:07AM -0400, Demi Marie Obenour wrote:
> On Mon, May 16, 2022 at 08:48:17AM +0200, Juergen Gross wrote:
> > On 14.05.22 17:55, Demi Marie Obenour wrote:
> > > In https://github.com/QubesOS/qubes-issues/issues/7481, a user reported
> > > that Xorg locked up when resizing
flight 170569 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170569/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Wed, May 18, 2022 at 2:10 PM Stefan Hajnoczi wrote:
>
> Commit 1b7fd729559c ("block: rename buffer_alignment to
> guest_block_size") noted:
>
> At this point, the field is set by the device emulation, but completely
> ignored by the block layer.
>
> The last time the value of buffer_alignme
On Thu, May 19, 2022 at 04:55:10PM +0200, Jan Beulich wrote:
> On 19.05.2022 16:45, Demi Marie Obenour wrote:
> > On Thu, May 19, 2022 at 12:32:33PM +0200, Jan Beulich wrote:
> >> On 18.05.2022 19:32, Demi Marie Obenour wrote:
> >>> +/*
> >>> + * The specification requires EfiBootServicesDa
On 04.05.22 17:57, Juergen Gross wrote:
Instead of using arch_has_restricted_virtio_memory_access() together
with CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS, replace those
with platform_has() and a new platform feature
PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS.
Signed-off-by: Juergen Gross
C
> -Original Message-
> From: Juergen Gross
> Sent: Thursday, May 19, 2022 10:31 AM
> To: Lengyel, Tamas ; xen-
> de...@lists.xenproject.org
> Cc: Wei Liu ; Anthony PERARD ;
> Cooper, Andrew
> Subject: Re: [PATCH] tools/libs/ctrl: add and export xc_memory_op
>
> On 19.05.22 15:59, Lengy
On 19.05.2022 16:45, Demi Marie Obenour wrote:
> On Thu, May 19, 2022 at 12:32:33PM +0200, Jan Beulich wrote:
>> On 18.05.2022 19:32, Demi Marie Obenour wrote:
>>> +/*
>>> + * The specification requires EfiBootServicesData, but accept
>>> + * EfiRuntimeServicesData, which is a more logi
On Thu, May 19, 2022 at 12:32:33PM +0200, Jan Beulich wrote:
> On 18.05.2022 19:32, Demi Marie Obenour wrote:
> > @@ -567,6 +587,39 @@ static int __init efi_check_dt_boot(const
> > EFI_LOADED_IMAGE *loaded_image)
> > }
> > #endif
> >
> > +static UINTN __initdata esrt = EFI_INVALID_TABLE_ADDR;
On Thu, May 19, 2022 at 12:10:24AM +, Andrew Cooper wrote:
> On 17/05/2022 14:21, Roger Pau Monne wrote:
> > Under certain conditions guests can get the CPU stuck in an infinite
> > loop without the possibility of an interrupt window to occur.
>
> instruction boundary.
>
> It's trivial to cre
On Fri, May 13, 2022 at 08:09:57PM +0200, Bernhard Beschow wrote:
> This function was declared in a generic and public header, implemented
> in a device-specific source file but only used in xen_platform. Given its
> 'aux' parameter, this function is more xen-specific than piix-specific.
> Also, th
On Fri, May 13, 2022 at 08:09:56PM +0200, Bernhard Beschow wrote:
> The comment is based on commit message
> ae4d2eb273b167dad748ea4249720319240b1ac2 'xen-platform: add missing disk
> unplug option'. Since it seems to describe design decisions and
> limitations that still apply it seems worth havin
On 19.05.22 15:59, Lengyel, Tamas wrote:
-Original Message-
From: Xen-devel On Behalf Of
Juergen Gross
Sent: Thursday, May 19, 2022 9:33 AM
To: Lengyel, Tamas ; xen-devel@lists.xenproject.org
Cc: Wei Liu ; Anthony PERARD ;
Cooper, Andrew
Subject: Re: [PATCH] tools/libs/ctrl: add and
On Fri, May 13, 2022 at 08:09:55PM +0200, Bernhard Beschow wrote:
> Commit 0f8445820f11a69154309863960328dda3dc1ad4 'xen: piix reuse pci
> generic class init function' already resolved redundant code which in
> turn rendered piix3-ide-xen redundant.
>
> Signed-off-by: Bernhard Beschow
Creating a
On 19.05.2022 14:44, Roger Pau Monné wrote:
> On Thu, May 19, 2022 at 08:50:55AM +0200, Jan Beulich wrote:
>> On 17.05.2022 15:21, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -4567,6 +4567,30 @@ void vmx_vmexit_handler(struct cpu_user_regs
On Wed, May 18, 2022 at 02:09:45PM +0100, Stefan Hajnoczi wrote:
> Commit 1b7fd729559c ("block: rename buffer_alignment to
> guest_block_size") noted:
>
> At this point, the field is set by the device emulation, but completely
> ignored by the block layer.
>
> The last time the value of buffe
> -Original Message-
> From: Xen-devel On Behalf Of
> Juergen Gross
> Sent: Thursday, May 19, 2022 9:33 AM
> To: Lengyel, Tamas ; xen-devel@lists.xenproject.org
> Cc: Wei Liu ; Anthony PERARD ;
> Cooper, Andrew
> Subject: Re: [PATCH] tools/libs/ctrl: add and export xc_memory_op
>
> On
On 19.05.22 15:27, Tamas K Lengyel wrote:
Add and export xc_memory_op so that do_memory_op can be used by tools linking
with libxc. This is effectively in the same spirit as the existing xc_domctl
and xc_sysctl functions, which are already exported.
In this patch we move do_memory_op into xc_pri
Add and export xc_memory_op so that do_memory_op can be used by tools linking
with libxc. This is effectively in the same spirit as the existing xc_domctl
and xc_sysctl functions, which are already exported.
In this patch we move do_memory_op into xc_private.h as a static inline function
and conve
On Mon, May 02, 2022 at 10:47:29AM +0200, Juergen Gross wrote:
> libxl_domain_setmaxmem() called during "xl mem-max" should update the
> domain's memory/static-max Xenstore node, as otherwise "xl mem-set"
> won't be able to set the memory size to the new maximum.
>
> Adjust the related comments an
On 19/05/2022 13:21, Roger Pau Monné wrote:
> On Wed, May 18, 2022 at 10:50:02PM +, Andrew Cooper wrote:
>> On 17/05/2022 14:21, Roger Pau Monne wrote:
>>> Add support for enabling Bus Lock Detection on Intel systems. Such
>>> detection works by triggering a vmexit, which is enough of a pause
On Thu, May 19, 2022 at 08:50:55AM +0200, Jan Beulich wrote:
> On 17.05.2022 15:21, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/hvm/vmx/vmcs.c
> > +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> > @@ -67,6 +67,9 @@ integer_param("ple_gap", ple_gap);
> > static unsigned int __read_mostly ple_window = 4096;
>
On 06.05.2022 08:21, Jan Beulich wrote:
> On 05.05.2022 21:10, Andrew Cooper wrote:
>> On 29/04/2022 14:05, Jan Beulich wrote:
>>> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
>>> unless you have verified the sender and know the content is safe.
>>>
>>> IOMMU code mapp
On Wed, May 18, 2022 at 10:50:02PM +, Andrew Cooper wrote:
> On 17/05/2022 14:21, Roger Pau Monne wrote:
> > Add support for enabling Bus Lock Detection on Intel systems. Such
> > detection works by triggering a vmexit, which is enough of a pause to
> > prevent a guest from abusing of the Bus
On 18/05/2022 19:17, Scott Branden wrote:
> Hi Guilherme,
>
> +Desmond
> [...]
I'm afraid it breaks kdump if this device is not reset beforehand - it's
a doorbell write, so not high risk I think...
But in case the not-reset device can be probed normally in kdump kernel,
t
On 22.04.2022 11:58, Jan Beulich wrote:
> EPT is of no interest when !HVM. While I'm observing gcc11 to fully
> eliminate the function, older gcc's DCE looks to not be as good. Aid the
> compiler in eliminating the accesses of opt_hap_{2mb,1gb}, which
> otherwise cause undefined symbol errors when
On 06.05.2022 13:16, Roger Pau Monné wrote:
> On Mon, Apr 25, 2022 at 10:40:55AM +0200, Jan Beulich wrote:
>> ---
>> An alternative to the ASSERT()s added to set_iommu_ptes_present() would
>> be to make the function less general-purpose; it's used in a single
>> place only after all (i.e. it might
On 19/05/2022 04:03, Petr Mladek wrote:
> [...]
> I would ignore it for now. If anyone would want to safe the log
> then they would need to read it. They will most likely use
> the existing kmsg_dump() infastructure. In fact, they should
> use it to avoid a code duplication.
>
> Best Regards,
> Pe
Hi all,
I have recent-ish made openQA to run tests not only inside KVM machines,
but also on physical hardware. The setup is described here:
https://www.qubes-os.org/news/2022/05/05/automated-os-testing-on-physical-laptops/
The live instance is at https://openqa.qubes-os.org. Tests running on
phy
On 5/18/22 17:46, Rafael J. Wysocki wrote:
> On Tue, May 10, 2022 at 1:33 AM Dmitry Osipenko
> wrote:
...
>> Introduce new API that provides call chains support for all restart and
>> power-off modes. The new API is designed with simplicity and extensibility
>> in mind.
...
> The v8 looks much bet
Recent versions of OVMF now need a version of NASM that is newer
than the one available on Debian oldstable/buster. They want to use
NASM 2.15.05 [1], which is available in Debian stable/bullseye. The
need to use a newer version started with d3febfd9ade3 ("MdePkg:
Replace Opcode with the correspond
On 18.05.2022 19:32, Demi Marie Obenour wrote:
> @@ -567,6 +587,39 @@ static int __init efi_check_dt_boot(const
> EFI_LOADED_IMAGE *loaded_image)
> }
> #endif
>
> +static UINTN __initdata esrt = EFI_INVALID_TABLE_ADDR;
Just out of curiosity: It's an arbitrary choice to use this initializer,
i
flight 170567 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170567/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 19/05/2022 07:59, Jan Beulich wrote:
> On 19.05.2022 02:10, Andrew Cooper wrote:
>> On 17/05/2022 14:21, Roger Pau Monne wrote:
>>> Under certain conditions guests can get the CPU stuck in an infinite
>>> loop without the possibility of an interrupt window to occur.
>> instruction boundary.
>>
>
Hi Vikram,
A few more comments that I spotted after reviewing the next patch.
On 08/03/2022 19:47, Vikram Garhwal wrote:
Introduce sysctl XEN_SYSCTL_dt_overlay to remove device-tree nodes added using
device tree overlay.
xl overlay remove file.dtbo:
Removes all the nodes in a given dtbo.
flight 170560 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170560/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
flight 170564 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170564/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170546 linux-linus real [real]
flight 170565 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/170546/
http://logs.test-lab.xenproject.org/osstest/logs/170565/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
On Wed 2022-05-18 10:16:20, Guilherme G. Piccoli wrote:
> On 18/05/2022 04:58, Petr Mladek wrote:
> > [...]
> >> I does similar things like kmsg_dump() so it should be called in
> >> the same location (after info notifier list and before kdump).
> >>
> >> A solution might be to put it at these noti
73 matches
Mail list logo
