On 23.11.2022 13:03, Roger Pau Monné wrote:
> On Mon, Nov 21, 2022 at 01:34:38PM +0100, Jan Beulich wrote:
>> On 21.11.2022 13:23, Andrew Cooper wrote:
>>> On 21/11/2022 08:56, Jan Beulich wrote:
On 18.11.2022 15:27, Andrew Cooper wrote:
> I even got as far as writing that maybe leaving
flight 174950 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174950/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 174944
Tests which are
On 24.11.22 06:28, Juergen Gross wrote:
On 24.11.22 03:39, Josh Poimboeuf wrote:
On Wed, Nov 23, 2022 at 09:03:40AM -0800, Josh Poimboeuf wrote:
On Wed, Nov 23, 2022 at 10:52:09AM +, Andrew Cooper wrote:
Well, if you return from arch_cpu_idle_dead() you're back in the idle
loop -- exactly
flight 174949 qemu-mainline real [real]
flight 174953 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/174949/
http://logs.test-lab.xenproject.org/osstest/logs/174953/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 24.11.22 03:39, Josh Poimboeuf wrote:
On Wed, Nov 23, 2022 at 09:03:40AM -0800, Josh Poimboeuf wrote:
On Wed, Nov 23, 2022 at 10:52:09AM +, Andrew Cooper wrote:
Well, if you return from arch_cpu_idle_dead() you're back in the idle
loop -- exactly where you would be if you were to
On Wed, Nov 23, 2022 at 04:45:19PM +0100, Roger Pau Monne wrote:
> Marek: after this series using console= without the vga option should
> result in Xen not attempting to touch the selected GOP mode and the
> screen not getting cleared.
Thanks, this seems to work mostly fine.
There is one message
flight 174948 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174948/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462
Signed-off-by: Henry Wang
Reviewed-by: Julien Grall
---
v4 -> v5:
- Add Julien's Reviewed-by.
v3 -> v4:
- No change.
v2 -> v3:
- Take the opportunity to also adjust the 4.17 entry since this
patch will be applied only after branching.
- Add 4.17 release date.
- Drop Julien's acked-by because
From: Andrew Cooper
Signed-off-by: Andrew Cooper
Signed-off-by: Henry Wang
Reviewed-by: Roger Pau Monné
Reviewed-by: Julien Grall
---
v4 -> v5:
- Add Julien's reviewed-by.
v3 -> v4:
- Add my own sign-off because I changed the original wording.
v2 -> v3:
- Remove the "on x86" for
Signed-off-by: Henry Wang
Reviewed-by: Julien Grall
---
v4 -> v5:
- Add gitlab CI improvement following Michal's suggestion.
- Add Julien's reviewed-by.
v3 -> v4:
- Use the corrected sentence for VIRT_SSBD and MSR_SPEC_CTRL
- Clarify that the virtio-mmio toolstack for ARM is only creating the
Hello,
The following changes are preparation work for the 4.17 release. Also
collecting the changelog changes happened during the 4.17 dev phase.
This is my first pass at the log for the release, it's likely missing
more entries.
Thanks,
Henry
v4 -> v5:
- Add gitlab CI improvement following
On Wed, Nov 23, 2022 at 09:03:40AM -0800, Josh Poimboeuf wrote:
> On Wed, Nov 23, 2022 at 10:52:09AM +, Andrew Cooper wrote:
> > > Well, if you return from arch_cpu_idle_dead() you're back in the idle
> > > loop -- exactly where you would be if you were to bootstrap the whole
> > > CPU --
The binding for xc_interface_close() free the underlying handle while leaving
the Ocaml object still in scope and usable. This would make it easy to suffer
a use-after-free, if it weren't for the fact that the typical usage is as a
singleton that lives for the lifetime of the program.
Ocaml 5 no
flight 174944 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174944/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-coresched-i386-xl 23 guest-start.2fail in 174930 pass in 174944
flight 174947 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174947/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 174943
test-amd64-i386-xl-qemuu-win7-amd64 19
flight 174942 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174942/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462
On Mon, Nov 21, 2022 at 4:41 AM Jan Beulich wrote:
> On 11.10.2022 11:28, Jan Beulich wrote:
> > find_ring_mfn() already holds a page reference when trying to obtain a
> > writable type reference. We shouldn't make assumptions on the general
> > reference count limit being effectively
On Wed, Nov 23, 2022 at 10:52:09AM +, Andrew Cooper wrote:
> > Well, if you return from arch_cpu_idle_dead() you're back in the idle
> > loop -- exactly where you would be if you were to bootstrap the whole
> > CPU -- provided you have it remember the whole state (easier with a
> > vCPU).
Hi,
在 2022/11/23 23:23, Juergen Gross 写道:
On 19.11.22 09:59, Xiu Jianfeng wrote:
The new string allocated by kasprintf() is leaked on error path
Xiu Jianfeng (2):
x86/xen: Fix memory leak in xen_smp_intr_init{_pv}()
x86/xen: Fix memory leak in xen_init_lock_cpu()
arch/x86/xen/smp.c
The new string allocated by kasprintf() is leaked on error paths
v2: follow Juergen's suggestion.
Xiu Jianfeng (2):
x86/xen: Fix memory leak in xen_smp_intr_init{_pv}()
x86/xen: Fix memory leak in xen_init_lock_cpu()
arch/x86/xen/smp.c | 24
In xen_init_lock_cpu(), the @name has allocated new string by kasprintf(),
if bind_ipi_to_irqhandler() fails, it should be freed, otherwise may lead
to a memory leak issue, fix it.
Fixes: 2d9e1e2f58b5 ("xen: implement Xen-specific spinlocks")
Signed-off-by: Xiu Jianfeng
---
These local variables @{resched|pmu|callfunc...}_name saves the new
string allocated by kasprintf(), and when bind_{v}ipi_to_irqhandler()
fails, it goes to the @fail tag, and calls xen_smp_intr_free{_pv}() to
free resource, however the new string is not saved, which cause a memory
leak issue. fix
On 23/11/2022 15:22, Bertrand Marquis wrote:
Hi Michal,
On 23 Nov 2022, at 14:39, Michal Orzel wrote:
When creating direct mapped domU, the vIRQ for vpl011 is taken from
the SERHND_DTUART serial port using serial_irq. This function can return
-1 (i.e. no interrupt found) in which case we
flight 174935 qemu-mainline real [real]
flight 174945 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/174935/
http://logs.test-lab.xenproject.org/osstest/logs/174945/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Currently the vga command line gfx- option is ignored when booted
using multboot2 and EFI, as the setting of the GOP mode is done way
before the command line is processed.
Add support for parsing the vga gfx- selection if present in order to
set the selected GOP mode.
Signed-off-by: Roger Pau
Only set the GOP mode if vga is selected in the console option,
otherwise just fetch the information from the current mode in order to
make it available to dom0.
Introduce support for passing the command line to the efi_multiboot2()
helper, and parse the console= option if present.
Hello,
The following series contains some fixes and improvements related to
graphics usage when booting Xen.
First patch introduces a new platform hypercall to pass the graphics
console information and mode to a PVH dom0, which doesn't have this
information available as part of the start_info
Modify efi_find_gop_mode() so that passing cols or rows as 0 is
interpreted as a request to attempt to keep the currently set mode,
and do so if the mode query for information is successful and the depth
is supported.
Signed-off-by: Roger Pau Monné
---
xen/common/efi/boot.c | 20
Do not unconditionally set a mode in efi_console_set_mode(), do so
only if the currently set mode is not valid.
Signed-off-by: Roger Pau Monné
---
xen/common/efi/boot.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index
This is required so PVH dom0 can get the initial video console state
as handled by Xen. PV dom0 will get this as part of the start_info,
but it doesn't seem necessary to place such information in the
HVM start info.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/platform_hypercall.c | 11
On 19.11.22 09:59, Xiu Jianfeng wrote:
The new string allocated by kasprintf() is leaked on error path
Xiu Jianfeng (2):
x86/xen: Fix memory leak in xen_smp_intr_init{_pv}()
x86/xen: Fix memory leak in xen_init_lock_cpu()
arch/x86/xen/smp.c | 16
Hi Michal,
> On 23 Nov 2022, at 14:39, Michal Orzel wrote:
>
> When creating direct mapped domU, the vIRQ for vpl011 is taken from
> the SERHND_DTUART serial port using serial_irq. This function can return
> -1 (i.e. no interrupt found) in which case we should call a panic.
> However,
On 23.11.22 14:10, Jani Nikula wrote:
For CONFIG_XEN_PVH=y, xen.h uses bool before the type is known. Include
earlier.
Signed-off-by: Jani Nikula
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP
On 22/11/2022 15:20, Andrew Cooper wrote:
> A debug statement got inserted into a single-expression if statement.
>
> Insert brackets to give the intended meaning, rather than the actual meaning
> where the "let con = Connections..." is outside and executed unconditionally.
>
> This results in
flight 174937 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174937/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 174907
test-armhf-armhf-libvirt-qcow2 15
When creating direct mapped domU, the vIRQ for vpl011 is taken from
the SERHND_DTUART serial port using serial_irq. This function can return
-1 (i.e. no interrupt found) in which case we should call a panic.
However, vpl011_virq is defined as unsigned int which causes the panic
to be unreachable,
For CONFIG_XEN_PVH=y, xen.h uses bool before the type is known. Include
earlier.
Signed-off-by: Jani Nikula
---
include/xen/xen.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/xen/xen.h b/include/xen/xen.h
index a99bab817523..7adf59837c25 100644
---
flight 174943 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174943/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 174925
test-amd64-i386-xl-qemuu-win7-amd64 19
From: ruanjinjie
[ Upstream commit c53717e1e3f0d0f9129b2e0dbc6dcc5e0a8132e9 ]
free_irq() is missing in case of error in platform_pci_probe(), fix that.
Signed-off-by: ruanjinjie
Reviewed-by: Oleksandr Tyshchenko
Link: https://lore.kernel.org/r/20221114112124.1965611-1-ruanjin...@huawei.com
From: ruanjinjie
[ Upstream commit c53717e1e3f0d0f9129b2e0dbc6dcc5e0a8132e9 ]
free_irq() is missing in case of error in platform_pci_probe(), fix that.
Signed-off-by: ruanjinjie
Reviewed-by: Oleksandr Tyshchenko
Link: https://lore.kernel.org/r/20221114112124.1965611-1-ruanjin...@huawei.com
From: ruanjinjie
[ Upstream commit c53717e1e3f0d0f9129b2e0dbc6dcc5e0a8132e9 ]
free_irq() is missing in case of error in platform_pci_probe(), fix that.
Signed-off-by: ruanjinjie
Reviewed-by: Oleksandr Tyshchenko
Link: https://lore.kernel.org/r/20221114112124.1965611-1-ruanjin...@huawei.com
From: ruanjinjie
[ Upstream commit c53717e1e3f0d0f9129b2e0dbc6dcc5e0a8132e9 ]
free_irq() is missing in case of error in platform_pci_probe(), fix that.
Signed-off-by: ruanjinjie
Reviewed-by: Oleksandr Tyshchenko
Link: https://lore.kernel.org/r/20221114112124.1965611-1-ruanjin...@huawei.com
From: Marek Marczykowski-Górecki
[ Upstream commit 5e29500eba2aa19e1323df46f64dafcd4a327092 ]
When Xen domain configures MSI-X, the usual approach is to enable MSI-X
together with masking all of them via the config space, then fill the
table and only then clear PCI_MSIX_FLAGS_MASKALL. Allow
From: ruanjinjie
[ Upstream commit c53717e1e3f0d0f9129b2e0dbc6dcc5e0a8132e9 ]
free_irq() is missing in case of error in platform_pci_probe(), fix that.
Signed-off-by: ruanjinjie
Reviewed-by: Oleksandr Tyshchenko
Link: https://lore.kernel.org/r/20221114112124.1965611-1-ruanjin...@huawei.com
From: ruanjinjie
[ Upstream commit c53717e1e3f0d0f9129b2e0dbc6dcc5e0a8132e9 ]
free_irq() is missing in case of error in platform_pci_probe(), fix that.
Signed-off-by: ruanjinjie
Reviewed-by: Oleksandr Tyshchenko
Link: https://lore.kernel.org/r/20221114112124.1965611-1-ruanjin...@huawei.com
From: Marek Marczykowski-Górecki
[ Upstream commit 5e29500eba2aa19e1323df46f64dafcd4a327092 ]
When Xen domain configures MSI-X, the usual approach is to enable MSI-X
together with masking all of them via the config space, then fill the
table and only then clear PCI_MSIX_FLAGS_MASKALL. Allow
From: ruanjinjie
[ Upstream commit c53717e1e3f0d0f9129b2e0dbc6dcc5e0a8132e9 ]
free_irq() is missing in case of error in platform_pci_probe(), fix that.
Signed-off-by: ruanjinjie
Reviewed-by: Oleksandr Tyshchenko
Link: https://lore.kernel.org/r/20221114112124.1965611-1-ruanjin...@huawei.com
From: Marek Marczykowski-Górecki
[ Upstream commit 5e29500eba2aa19e1323df46f64dafcd4a327092 ]
When Xen domain configures MSI-X, the usual approach is to enable MSI-X
together with masking all of them via the config space, then fill the
table and only then clear PCI_MSIX_FLAGS_MASKALL. Allow
On Mon, Nov 21, 2022 at 01:34:38PM +0100, Jan Beulich wrote:
> On 21.11.2022 13:23, Andrew Cooper wrote:
> > On 21/11/2022 08:56, Jan Beulich wrote:
> >> On 18.11.2022 15:27, Andrew Cooper wrote:
> >>> On 18/11/2022 12:54, Jan Beulich wrote:
> On 18.11.2022 13:33, Andrew Cooper wrote:
> >
Hi Henry,
On 23/11/2022 11:46, Henry Wang wrote:
>
>
> Hi Michal,
>
>> -Original Message-
>> Subject: Re: [PATCH v4 1/3] CHANGELOG: Add missing entries for work during
>> the 4.17 release
>> Hi Henry,
>> Looking at the "Added" section for the previous releases, we seem to
>> mention
When running as a Xen PV guest there is no need for setting up the
realmode trampoline, as realmode isn't supported in this environment.
Trying to setup the trampoline has been proven to be problematic in
some cases, especially when trying to debug early boot problems with
Xen requiring to keep
> On 22 Nov 2022, at 15:20, Andrew Cooper wrote:
>
> From: Edwin Török
>
> Closing the evtchn handle will unbind and free all local ports. The new
> xenstored would need to rebind all evtchns, which is work that we don't want
> or need to be doing during the critical handover period.
>
>
On 23/11/2022 08:55, Peter Zijlstra wrote:
> On Tue, Nov 22, 2022 at 05:23:50PM -0800, Josh Poimboeuf wrote:
>> On Tue, Nov 22, 2022 at 09:35:17AM +0100, Peter Zijlstra wrote:
>>> On Mon, Nov 21, 2022 at 09:16:05PM -0800, Josh Poimboeuf wrote:
>>>
It's complaining about an unreachable
Hi Michal,
> -Original Message-
> Subject: Re: [PATCH v4 1/3] CHANGELOG: Add missing entries for work during
> the 4.17 release
> Hi Henry,
> Looking at the "Added" section for the previous releases, we seem to
> mention the changes to CI (automation/) as well.
> Because there were quite
On 23.11.22 10:18, Jan Beulich wrote:
On 23.11.2022 08:39, Juergen Gross wrote:
On 22.11.22 10:47, Roger Pau Monné wrote:
On Mon, Nov 21, 2022 at 06:01:00PM +0100, Jan Beulich wrote:
On 21.11.2022 17:48, Roger Pau Monné wrote:
On Mon, Nov 21, 2022 at 05:27:16PM +0100, Jan Beulich wrote:
Hi Henry,
On 23/11/2022 05:03, Henry Wang wrote:
>
>
> Signed-off-by: Henry Wang
> ---
> v3 -> v4:
> - Use the corrected sentence for VIRT_SSBD and MSR_SPEC_CTRL
> - Clarify that the virtio-mmio toolstack for ARM is only creating the
> device-tree binding.
> - Remove the "initial" in i.MX
Hi Henry,
On 23/11/2022 04:03, Henry Wang wrote:
Signed-off-by: Henry Wang
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
On 23/11/2022 04:03, Henry Wang wrote:
From: Andrew Cooper
Signed-off-by: Andrew Cooper
Signed-off-by: Henry Wang
Reviewed-by: Roger Pau Monné
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
Hi Henry,
On 23/11/2022 04:03, Henry Wang wrote:
Signed-off-by: Henry Wang
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
Hi Ayan,
On 11/11/2022 15:17, Ayan Kumar Halder wrote:
> One can now use GICv3 on AArch32 systems. However, ITS is not supported.
> The reason being currently we are trying to validate GICv3 on an AArch32_v8R
> system. Refer ARM DDI 0568A.c ID110520, B1.3.1,
> "A Generic Interrupt Controller
On 23.11.2022 10:41, Jan Beulich wrote:
> On 22.11.2022 21:25, Julien Grall wrote:
>> On 21/11/2022 16:40, Jan Beulich wrote:
>>> On 21.11.2022 17:23, Carlo Nonato wrote:
This would be really good. The only problem I can see is the p2m allocation
which is done during domain creation.
On 22.11.2022 21:25, Julien Grall wrote:
> Hi Jan,
>
> On 21/11/2022 16:40, Jan Beulich wrote:
>> On 21.11.2022 17:23, Carlo Nonato wrote:
>>> On Mon, Nov 21, 2022 at 4:14 PM Jan Beulich wrote:
On 21.11.2022 15:50, Carlo Nonato wrote:
> I want to ask you some questions about this patch
On 22.11.2022 17:38, Juergen Gross wrote:
> @@ -137,12 +138,28 @@ static void __init xen_pv_init_platform(void)
> xen_init_time_ops();
> }
>
> +static struct real_mode_header xen_rm_header;
> +
> +static __initdata struct trampoline_ref xen_dummy_trampoline = {
> + .blob = (unsigned
Hi Julien,
On 22/11/2022 21:31, Julien Grall wrote:
>
>
> On 17/11/2022 13:39, Michal Orzel wrote:
>> Hi Ayan,
>>
>> On 11/11/2022 15:17, Ayan Kumar Halder wrote:
>>> Refer ARM DDI 0487I.a ID081822, G8-9817, G8.2.169
>>> Affinity level 3 is not present in AArch32.
>>> Also, refer ARM DDI
On 23.11.2022 08:39, Juergen Gross wrote:
> On 22.11.22 10:47, Roger Pau Monné wrote:
>> On Mon, Nov 21, 2022 at 06:01:00PM +0100, Jan Beulich wrote:
>>> On 21.11.2022 17:48, Roger Pau Monné wrote:
On Mon, Nov 21, 2022 at 05:27:16PM +0100, Jan Beulich wrote:
> Hello,
>
> on a
On Tue, Nov 22, 2022 at 05:23:50PM -0800, Josh Poimboeuf wrote:
> On Tue, Nov 22, 2022 at 09:35:17AM +0100, Peter Zijlstra wrote:
> > On Mon, Nov 21, 2022 at 09:16:05PM -0800, Josh Poimboeuf wrote:
> >
> > > It's complaining about an unreachable instruction after a call to
> > >
flight 174930 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174930/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-pvshimbroken in 174920
Hi Julien,
> -Original Message-
> From: Julien Grall
> Subject: Re: [PATCH v3 1/3] CHANGELOG: Add missing entries for work during
> the 4.17 release
> >> I was under the impression that the code that was merged is enough to
> >> support the platform. Do you have any pointer where it says
On 22/11/2022 12:46, Henry Wang wrote:
Hi Julien,
Hi Henry,
Thanks for your review as always!
-Original Message-
From: Julien Grall
Subject: Re: [PATCH v3 1/3] CHANGELOG: Add missing entries for work during
the 4.17 release
(Reducing the CC-list)
Thanks, I will use this
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemut-debianhvm-i386-xsm
testid guest-saverestore
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
flight 174928 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174928/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462
71 matches
Mail list logo
