Hi Julien
> -Original Message-
> From: Xen-devel On Behalf Of
> Julien Grall
> Sent: Wednesday, August 17, 2022 3:00 AM
> To: xen-devel@lists.xenproject.org
> Cc: jul...@xen.org; Julien Grall ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk
> Subject: [PATCH for-4.17] xen/
On 17.08.22 06:43, Lukas Bulwahn wrote:
Commit c70727a5bc18 ("xen: allow more than 512 GB of RAM for 64 bit
pv-domains") from July 2015 replaces the config XEN_MAX_DOMAIN_MEMORY with
a new config XEN_512GB, but misses to adjust arch/x86/configs/xen.config.
As XEN_512GB defaults to yes, there is n
On 16.08.22 21:49, Stefano Stabellini wrote:
On Tue, 16 Aug 2022, Juergen Gross wrote:
On 15.08.22 22:32, Stefano Stabellini wrote:
+ Xen maintainers and committers
For context, I wrote a patch to introduce SPDX tags starting from
arch/arm/*.c.
Don't we want something like the kernel's LICE
flight 172586 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172586/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
Hi Julien,
> -Original Message-
> Subject: [PATCH for-4.17] xen/arm: Support properly __ro_after_init on Arm
>
> From: Julien Grall
>
> __ro_after_init was introduced recently to prevent modifying
> some variables after init.
>
> At the moment, on Arm, the variables will still be acces
Commit c70727a5bc18 ("xen: allow more than 512 GB of RAM for 64 bit
pv-domains") from July 2015 replaces the config XEN_MAX_DOMAIN_MEMORY with
a new config XEN_512GB, but misses to adjust arch/x86/configs/xen.config.
As XEN_512GB defaults to yes, there is no need to explicitly set any config
in xen
On Wed, Aug 10, 2022 at 9:07 AM Jan Beulich wrote:
>
> On 10.08.2022 07:07, Lukas Bulwahn wrote:
> > --- a/arch/x86/configs/xen.config
> > +++ b/arch/x86/configs/xen.config
> > @@ -14,7 +14,7 @@ CONFIG_CPU_FREQ=y
> >
> > # x86 xen specific config options
> > CONFIG_XEN_PVH=y
> > -CONFIG_XEN_MAX_
On Wed, Aug 10, 2022 at 1:32 PM Oleksandr Tyshchenko
wrote:
>
>
> On 10.08.22 08:07, Lukas Bulwahn wrote:
>
> Hello Lukas, all
>
> > While reviewing arch/x86/configs/xen.config, I noticed the following
> > note in this file:
> >
> >'# depends on MEMORY_HOTPLUG, arm64 doesn't enable this yet,
>
flight 172578 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172578/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
flight 172575 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172575/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-raw 1 buil
Hi all๏ผ
Sorry for that, please ignore this. I sent the wrong email.
> -Original Message-
> From: jiaxie01
> Sent: Wednesday, August 17, 2022 10:07 AM
> To: Jiamei Xie ; xen-devel@lists.xenproject.org
> Cc: Julien Grall ; Wei Liu ; Anthony
> PERARD ; Juergen Gross ;
> Stefano Stabellini ;
From: Oleksandr Tyshchenko
This patch adds basic support for configuring and assisting virtio-mmio
based virtio-disk backend (emulator) which is intended to run out of
Qemu and could be run in any domain.
Although the Virtio block device is quite different from traditional
Xen PV block device (vb
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 with allocated params. In order to deal
with multiple Virtio devices, reserve corresponding ranges.
For now, we reserve 1MB for memory r
flight 172576 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172576/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
build-i386-libvir
flight 172582 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172582/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 172579 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172579/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 172562 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172562/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172133
build-amd64-libvirt
flight 172563 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172563/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-armhf-libvirt
On Tue, 16 Aug 2022, Bertrand Marquis wrote:
> Hi Stefano,
>
> > On 15 Aug 2022, at 21:32, Stefano Stabellini wrote:
> >
> > + Xen maintainers and committers
> >
> >
> > For context, I wrote a patch to introduce SPDX tags starting from
> > arch/arm/*.c.
> >
> > Julien rightfully pointed out t
On Tue, 16 Aug 2022, Juergen Gross wrote:
> On 15.08.22 22:32, Stefano Stabellini wrote:
> > + Xen maintainers and committers
> >
> >
> > For context, I wrote a patch to introduce SPDX tags starting from
> > arch/arm/*.c.
>
> Don't we want something like the kernel's LICENSES directory in order
From: Julien Grall
__ro_after_init was introduced recently to prevent modifying
some variables after init.
At the moment, on Arm, the variables will still be accessible
because the region permission is not updated.
Address that, but moving the sections .data.ro_after_init
out of .data and then
On 8/13/2022 6:41 PM, Chuck Zmudzinski wrote:
> On 8/13/2022 5:48 PM, Borislav Petkov wrote:
> > On Sat, Aug 13, 2022 at 05:40:34PM -0400, Chuck Zmudzinski wrote:
> > > I did a search for Juergen Gross on lkml and he is active submitting and
> > > reviewing patches during the past few weeks. Howeve
flight 172574 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172574/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 172556 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172556/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
On Thu, Aug 11, 2022 at 8:30 AM Anthony PERARD
wrote:
>
> On Tue, Aug 09, 2022 at 08:17:49AM -0400, Jason Andryuk wrote:
> > On Mon, Aug 8, 2022 at 7:06 AM Anthony PERARD
> > wrote:
> > > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> > > index 6d98d73d76..b2901e04cf 100644
>
Hi,
I think you should change the title to "xsm/flask: Boot-time labeling
for multiple domains". Refactor implies no functional change, and
this is a functional change. With this, I think the commit message
should be re-written to focus on the "why" of the new labeling policy.
On Tue, Aug 9, 20
On 8/16/2022 12:53 PM, Thorsten Leemhuis wrote:
> On 16.08.22 18:16, Chuck Zmudzinski wrote:
> > On 8/16/2022 10:41 AM, Thorsten Leemhuis wrote:
> >> On 15.08.22 20:17, Chuck Zmudzinski wrote:
> >>> On 8/15/2022 2:00 PM, Thorsten Leemhuis wrote:
> >>>
> And FWIW: I've seen indicators that a so
On 16.08.22 18:16, Chuck Zmudzinski wrote:
> On 8/16/2022 10:41 AM, Thorsten Leemhuis wrote:
>> On 15.08.22 20:17, Chuck Zmudzinski wrote:
>>> On 8/15/2022 2:00 PM, Thorsten Leemhuis wrote:
>>>
And FWIW: I've seen indicators that a solution to resolve this is
hopefully pretty close now.
>
flight 172554 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172554/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 broken
build-amd64-libvirt 6 libvirt-
flight 172557 xen-unstable real [real]
flight 172573 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/172557/
http://logs.test-lab.xenproject.org/osstest/logs/172573/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On 16.08.2022 17:43, Anthony PERARD wrote:
> On Tue, Aug 16, 2022 at 03:02:10PM +0200, Jan Beulich wrote:
>> On 16.08.2022 12:30, Anthony PERARD wrote:
>>> We can't have a source file with the same name that exist in both the
>>> common code and in the arch specific code for efi/. This can lead to
On 8/16/2022 10:41 AM, Thorsten Leemhuis wrote:
> On 15.08.22 20:17, Chuck Zmudzinski wrote:
> > On 8/15/2022 2:00 PM, Thorsten Leemhuis wrote:
> >
> >> And FWIW: I've seen indicators that a solution to resolve this is
> >> hopefully pretty close now.
> >
> > That's good to know. But I must ask, c
On 16/08/2022 11:30, Anthony Perard wrote:
> We can't have a source file with the same name that exist in both the
> common code and in the arch specific code for efi/. This can lead to
> comfusion in make and it can pick up the wrong source file. This issue
> lead to a failure to build a pv-shim f
On Tue, Aug 16, 2022 at 03:02:10PM +0200, Jan Beulich wrote:
> On 16.08.2022 12:30, Anthony PERARD wrote:
> > We can't have a source file with the same name that exist in both the
> > common code and in the arch specific code for efi/. This can lead to
> > comfusion in make and it can pick up the w
flight 172571 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172571/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On Tue, Aug 16, 2022 at 12:01:40PM +0100, Julien Grall wrote:
> > xen/common/efi/{stub.c => common_stub.c} | 6 ++
>
> I haven't looked at the rest of the patch. However, I think you also want to
> update .gitignore to excluse arch/*/efi/common_stub.c.
>
> Also, I am thinking to drop my patc
On 15.08.22 20:17, Chuck Zmudzinski wrote:
> On 8/15/2022 2:00 PM, Thorsten Leemhuis wrote:
>
>> the right people have the issue on their radar again; give them time to
>> breath and work out a solution: it's not something that can be fixed
>> easily within a few minutes by one person alone, as pre
flight 172568 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172568/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
build-amd64-libvirt 6 lib
flight 172550 xen-4.14-testing real [real]
flight 172569 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/172550/
http://logs.test-lab.xenproject.org/osstest/logs/172569/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
flight 172570 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172570/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On 16.08.2022 12:16, Jane Malalane wrote:
> On 05/08/2022 10:24, Jan Beulich wrote:
>> On 04.08.2022 17:04, Jane Malalane wrote:
>>> Suggested-by: Andrew Cooper
>>> Signed-off-by: Jane Malalane
>>
>> In the title you say "port", but then you don't say what customization
>> you've done beyond the
On 16.08.2022 12:30, Anthony PERARD wrote:
> We can't have a source file with the same name that exist in both the
> common code and in the arch specific code for efi/. This can lead to
> comfusion in make and it can pick up the wrong source file. This issue
> lead to a failure to build a pv-shim f
On 16.08.2022 13:03, Anthony PERARD wrote:
> I'd like to keep an eye on any changes in the Makefiles, to avoid
> further break of the build system.
>
> With this entries, it means that THE REST will not be CCed anymore for
> changes in
> - xen/Makefile
> - xen/*.mk
> - xen/scripts/Kbuild.include
>
At 09:43 +0200 on 12 Aug (1660297391), Jan Beulich wrote:
> I did notice this anomaly in the context of IOMMU side work.
>
> 1: shadow: slightly consolidate sh_unshadow_for_p2m_change() (part I)
> 2: shadow: slightly consolidate sh_unshadow_for_p2m_change() (part II)
> 3: shadow: slightly consolid
flight 172567 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172567/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On 15.08.2022 18:54, Dylanger Daly wrote:
> Please see the attached dom0 dmesg log, verbose lspci output and a tar of all
> SSDT and DSDT decompiled ACPI tables.
The only way I can currently explain all aspects of the behavior that
I'm aware of is for Dom0's kernel somehow not identifying the pag
I'd like to keep an eye on any changes in the Makefiles, to avoid
further break of the build system.
With this entries, it means that THE REST will not be CCed anymore for
changes in
- xen/Makefile
- xen/*.mk
- xen/scripts/Kbuild.include
- xen/scripts/Makefile.*
This could be an issue.
Most other
Hi Anthony,
On 16/08/2022 11:30, Anthony PERARD wrote:
We can't have a source file with the same name that exist in both the
common code and in the arch specific code for efi/. This can lead to
comfusion in make and it can pick up the wrong source file. This issue
Typo: s/comfusion/confusion/
This patch probably need a slight better subject, as the issue is only
with out-of-tree build. So new subject:
build: Fix x86 out-of-tree build without EFI
--
Anthony PERARD
We can't have a source file with the same name that exist in both the
common code and in the arch specific code for efi/. This can lead to
comfusion in make and it can pick up the wrong source file. This issue
lead to a failure to build a pv-shim for x86 out-of-tree, as this is
one example of an x8
On 05/08/2022 10:24, Jan Beulich wrote:
> On 04.08.2022 17:04, Jane Malalane wrote:
>> Suggested-by: Andrew Cooper
>> Signed-off-by: Jane Malalane
>
> In the title you say "port", but then you don't say what customization
> you've done beyond the obvious adjustment of inclusion guard and
> adjus
In order to prepare not allocating or freeing memory from
schedule_cpu_rm(), move this functionality to dedicated functions.
For now call those functions from schedule_cpu_rm().
No change of behavior expected.
Signed-off-by: Juergen Gross
---
V2:
- add const (Jan Beulich)
- use "unsigned int" f
For updating the node affinities of all domains in a cpupool add a new
function cpupool_update_node_affinity().
In order to avoid multiple allocations of cpumasks carve out memory
allocation and freeing from domain_update_node_affinity() into new
helpers, which can be used by cpupool_update_node_a
A recent change in the hypervisor memory allocation framework led to
crashes when unplugging host cpus.
This was due to the (correct) assertion that allocating and freeing
memory is allowed with enabled interrupts only. As the main cpu unplug
operation is done in stop-machine context, this asserti
Cpu cpu unplugging is calling schedule_cpu_rm() via stop_machine_run()
with interrupts disabled, thus any memory allocation or freeing must
be avoided.
Since commit 5047cd1d5dea ("xen/common: Use enhanced
ASSERT_ALLOC_CONTEXT in xmalloc()") this restriction is being enforced
via an assertion, whic
flight 172560 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172560/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On 16.08.2022 11:19, Dylanger Daly wrote:
> Opening sound settings in dom0 and setting the HD Audio Controller to "Off"
> allowed the VM to boot! ๐
"The HD Audio Controller" is somewhat ambiguous - according to lspci
apparently you've got three of them, one named as "multimedia controller"
(and h
Hi Jan,
Interesting morning indeed!
Opening sound settings in dom0 and setting the HD Audio Controller to "Off"
allowed the VM to boot! ๐
Very strange indeed
Cheers
On Tue, Aug 16, 2022 at 09:11:37AM +0200, Juergen Gross wrote:
> Commit c89191ce67ef ("x86/entry: Convert SWAPGS to swapgs and remove
> the definition of SWAPGS") missed one use case of SWAPGS in
> entry_INT80_compat. Removing of the SWAPGS macro led to asm just
> using "swapgs", as it is accepting
On 16.08.2022 10:34, Dylanger Daly wrote:
> Indeed no devices are being passed into the domU, I'm simply trying to start
> a vanilla VM with no PCIe devices attached.
Hmm, looking more closely it's the sound device which is being opened by
some ALSA process. I have no clue at all why this would h
flight 172548 xen-4.16-testing real [real]
flight 172565 xen-4.16-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/172548/
http://logs.test-lab.xenproject.org/osstest/logs/172565/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
Hi Jan,
Indeed no devices are being passed into the domU, I'm simply trying to start a
vanilla VM with no PCIe devices attached.
Could it be a misconfiguration with ACPI tables? I originally thought it could
be AMD's SEV but I think it might just be that Xen is attempting to use a
memory regio
flight 172549 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172549/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 172113
test-amd64-i386-xl-qemuu-win7-am
On 16.08.22 08:32, Jan Beulich wrote:
The initial observation were duplicate symbols that our checking warns
about. Instead of merely renaming one or both pair(s) of symbols,
reduce #ifdef-ary at the same time by moving the instantiation of the
arrays into a macro. While doing the conversion also
On 16.08.2022 09:11, Juergen Gross wrote:
> Commit c89191ce67ef ("x86/entry: Convert SWAPGS to swapgs and remove
> the definition of SWAPGS") missed one use case of SWAPGS in
> entry_INT80_compat. Removing of the SWAPGS macro led to asm just
> using "swapgs", as it is accepting instructions in capi
Hi,
> On 15 Aug 2022, at 17:44, Julien Grall wrote:
>
>
>
> On 15/08/2022 15:45, Bertrand Marquis wrote:
>> Hi Julien,
>
> Hi Bertrand,
>
>>> On 12 Aug 2022, at 20:24, Julien Grall wrote:
>>>
>>> From: Julien Grall
>>>
>>> There are a few places in the code that need to find the slot
>>>
Hi Stefano,
> On 15 Aug 2022, at 21:32, Stefano Stabellini wrote:
>
> + Xen maintainers and committers
>
>
> For context, I wrote a patch to introduce SPDX tags starting from
> arch/arm/*.c.
>
> Julien rightfully pointed out that it should be added to our coding
> style. He is right. Also as
Hi Julien,
> On 15 Aug 2022, at 18:04, Julien Grall wrote:
>
>
>
> On 15/08/2022 17:39, Bertrand Marquis wrote:
>> Hi Julien,
>
> Hi Bertrand,
>
>>> On 12 Aug 2022, at 20:24, Julien Grall wrote:
>>>
>>> From: Julien Grall
>>>
>>> Unlike arm64, on arm32 there are no extra information dump
Commit c89191ce67ef ("x86/entry: Convert SWAPGS to swapgs and remove
the definition of SWAPGS") missed one use case of SWAPGS in
entry_INT80_compat. Removing of the SWAPGS macro led to asm just
using "swapgs", as it is accepting instructions in capital letters,
too.
This in turn leads to splats in
69 matches
Mail list logo
