A function called via the paravirt play_dead() hook should not return
to the caller.
xen_pv_play_dead() has a problem in this regard, as it currently will
return in case an offlined cpu is brought to life again. This can be
changed only by doing basically a longjmp() to cpu_bringup_and_idle(),
as
Mark xen_pv_play_dead() and related to that xen_cpu_bringup_again()
as "__noreturn".
Signed-off-by: Juergen Gross
---
arch/x86/xen/smp.h| 2 +-
arch/x86/xen/smp_pv.c | 4 ++--
tools/objtool/check.c | 1 +
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/x86/xen/smp.h b/arc
All play_dead() functions but xen_pv_play_dead() don't return to the
caller.
Adapt xen_pv_play_dead() to behave like the other play_dead() variants.
Juergen Gross (2):
x86/xen: don't let xen_pv_play_dead() return
x86/xen: mark xen_pv_play_dead() as __noreturn
arch/x86/xen/smp.h | 2 ++
On 24-11-22, 20:19, Julien Grall wrote:
> Unfortunately, we had some delay for releasing 4.17. So I have pushed this
> series in a branch for-next/4.18.
Thanks.
> This will be applied to staging once the
> tree has re-opened.
I don't see the branch here though. Is it not public yet ? Or should I
On 24.11.22 17:39, Josh Poimboeuf wrote:
On Thu, Nov 24, 2022 at 08:47:47AM +0100, Juergen Gross wrote:
+++ b/arch/x86/xen/smp_pv.c
@@ -385,17 +385,9 @@ static void xen_pv_play_dead(void) /* used only
with HOTPLUG_CPU */
{
play_dead_common();
HYPERVISOR_vcpu_op(VCPUOP_down, xen_
flight 174957 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174957/
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
test-arm64-arm64-xl
Hi Jan,
I am still digesting this series and replying with some initial comments.
On 19/10/2022 09:43, Jan Beulich wrote:
The registration by virtual/linear address has downsides: At least on
x86 the access is expensive for HVM/PVH domains. Furthermore for 64-bit
PV domains the areas are inacce
Hi Jan,
On 19/10/2022 09:38, Jan Beulich wrote:
x86'es variant is a superset of Arm's, with CONFIG_COMPAT parts already
properly marked. The only other missing piece is
update_guest_memory_policy(): For the time being Arm simply gains an
empty struct and inline function.
Signed-off-by: Jan Beul
flight 174955 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174955/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu broken
test-arm64-arm64-examine 8 reboot
Hi Viresh,
On 04/10/2022 11:59, Julien Grall wrote:
On 20/09/2022 11:29, Viresh Kumar wrote:
On 09-09-22, 16:02, Anthony PERARD wrote:
On Fri, Sep 09, 2022 at 08:13:28PM +0530, Viresh Kumar wrote:
The iommu node will be required for other virtio device types too, not
just disk device.
Move t
From: Julien Grall
Explain how the banner in README is generated and take the opportunity
to mention what it should look like for RC.
Signed-off-by: Julien Grall
Changes in v2:
- Mention what the banner looks like for RC.
---
docs/process/release-technician-checklist.txt | 7
Hi Michal,
On 28/10/2022 14:49, Michal Orzel wrote:
At the moment, we route NS phys timer IRQ to Xen even though it does not
make use of this timer. Xen uses hypervisor timer for itself and the
physical timer is fully emulated, hence there is nothing that can trigger
such IRQ. This means that re
Hi,
On 18/11/2022 12:46, Michal Orzel wrote:
This patch series performs simple early printk code cleanup around PL011.
No functional changes has been made.
Michal Orzel (3):
xen/arm: Drop early_uart_init macro from debug-meson.inc
xen/arm: debug-pl011.inc: Use macros instead of hardcoded
On 23/11/2022 10:35, Michal Orzel wrote:
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
Hi,
On 23/11/2022 16:22, Bertrand Marquis wrote:
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
Hi all,
The proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/zh4Ya2wW19fSnZe8L31fGM3K/ and you can edit
to add items. Alternatively, you can reply to this mail directly.
Agenda items appreciated a few days before the call: please put your name
besides items if you edit the document
Use actual include directory used to install the public header in
COPYING file.
Also, move the input file out of "tools/include/xen/" because that
directory is removed on `make clean`.
We can't used ./configure because $includedir contain another
variable, so the change is done in Makefile.
Fixe
On Thu, Nov 24, 2022 at 08:47:47AM +0100, Juergen Gross wrote:
> > > +++ b/arch/x86/xen/smp_pv.c
> > > @@ -385,17 +385,9 @@ static void xen_pv_play_dead(void) /* used only
> > > with HOTPLUG_CPU */
> > > {
> > > play_dead_common();
> > > HYPERVISOR_vcpu_op(VCPUOP_down, xen_vcpu_nr(smp
On 23.11.22 16:58, Xiu Jianfeng wrote:
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:
On 23.11.22 16:58, Xiu Jianfeng wrote:
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 save
On 24.11.22 16:35, Borislav Petkov wrote:
On Thu, Nov 24, 2022 at 02:30:39PM +0100, Juergen Gross wrote:
Looking at the date when 084ee1c641a0 went in I don't think it _needs_
to go in now, but I wouldn't complain ...
So if you don't have a particular and specific reason, I won't queue it
for
On Thu, Nov 24, 2022 at 02:30:39PM +0100, Juergen Gross wrote:
> Looking at the date when 084ee1c641a0 went in I don't think it _needs_
> to go in now, but I wouldn't complain ...
So if you don't have a particular and specific reason, I won't queue it
for stable at all.
--
Regards/Gruss,
Bor
On Sat, Oct 22, 2022 at 05:51:15PM +0200, Carlo Nonato wrote:
> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> index b2901e04cf..5f53cec8bf 100644
> --- a/docs/man/xl.cfg.5.pod.in
> +++ b/docs/man/xl.cfg.5.pod.in
> @@ -2880,6 +2880,16 @@ Currently, only the "sbsa_uart" model is
On Thu, Nov 24, 2022 at 12:16:13PM +0100, Jan Beulich wrote:
> On 24.11.2022 10:33, Roger Pau Monné wrote:
> > On Thu, Nov 24, 2022 at 10:11:05AM +0100, Jan Beulich wrote:
> >> On 24.11.2022 10:06, Roger Pau Monné wrote:
> >>> On Thu, Nov 24, 2022 at 09:42:40AM +0100, Roger Pau Monné wrote:
>
On Thu, Nov 24, 2022 at 10:56:33AM +0100, Roger Pau Monné wrote:
> On Thu, Nov 24, 2022 at 09:59:25AM +0100, Roger Pau Monné wrote:
> > On Thu, Nov 24, 2022 at 06:15:15AM +0100, Marek Marczykowski-Górecki wrote:
> > > But to get dom0 display image from BGRT, it seems something else is
> > > needed
> On 24 Nov 2022, at 14:13, Andrew Cooper wrote:
>
> On 24/11/2022 14:03, Edwin Torok wrote:
>>
>>> On 24 Nov 2022, at 13:43, Andrew Cooper wrote:
>>>
>>> On 24/11/2022 09:03, Edwin Torok wrote:
>> Perhaps a compromise between the 2 extremes would be for xenopsd to open and
>> have its own
On 24/11/2022 14:03, Edwin Torok wrote:
>
>> On 24 Nov 2022, at 13:43, Andrew Cooper wrote:
>>
>> On 24/11/2022 09:03, Edwin Torok wrote:
On 23 Nov 2022, at 22:25, Andrew Cooper wrote:
The binding for xc_interface_close() free the underlying handle while
leaving
the Ocam
> On 24 Nov 2022, at 13:43, Andrew Cooper wrote:
>
> On 24/11/2022 09:03, Edwin Torok wrote:
>>> On 23 Nov 2022, at 22:25, Andrew Cooper wrote:
>>>
>>> The binding for xc_interface_close() free the underlying handle while
>>> leaving
>>> the Ocaml object still in scope and usable. This wou
On 24/11/2022 09:03, Edwin Torok wrote:
>> On 23 Nov 2022, at 22:25, Andrew Cooper wrote:
>>
>> 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
On 24.11.22 14:28, Borislav Petkov wrote:
On Wed, Nov 23, 2022 at 12:45:23PM +0100, Juergen Gross wrote:
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
On Wed, Nov 23, 2022 at 12:45:23PM +0100, Juergen Gross wrote:
> 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, especial
flight 174951 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174951/
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
test-arm64-arm64-xl
On 24.11.2022 10:33, Roger Pau Monné wrote:
> On Thu, Nov 24, 2022 at 10:11:05AM +0100, Jan Beulich wrote:
>> On 24.11.2022 10:06, Roger Pau Monné wrote:
>>> On Thu, Nov 24, 2022 at 09:42:40AM +0100, Roger Pau Monné wrote:
On Thu, Nov 24, 2022 at 08:59:00AM +0100, Jan Beulich wrote:
> - pr
flight 174952 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174952/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 174937
test-armhf-armhf-libvirt-qcow2 15 saveres
On Thu, Nov 24, 2022 at 09:59:25AM +0100, Roger Pau Monné wrote:
> On Thu, Nov 24, 2022 at 06:15:15AM +0100, Marek Marczykowski-Górecki wrote:
> > But to get dom0 display image from BGRT, it seems something else is
> > needed too. Linux complains "Incorrect checksum in table [BGRT]". The
> > only r
Hi all,
We will be branching the tree for Xen 4.17 in the next few days. Please
avoid committing any new patches to staging until further notice.
Cheers,
--
Julien Grall
On Thu, Nov 24, 2022 at 10:11:05AM +0100, Jan Beulich wrote:
> On 24.11.2022 10:06, Roger Pau Monné wrote:
> > On Thu, Nov 24, 2022 at 09:42:40AM +0100, Roger Pau Monné wrote:
> >> On Thu, Nov 24, 2022 at 08:59:00AM +0100, Jan Beulich wrote:
> >>> - problematic wrt evtchn_upcall_pending, once set,
On 24.11.2022 10:06, Roger Pau Monné wrote:
> On Thu, Nov 24, 2022 at 09:42:40AM +0100, Roger Pau Monné wrote:
>> On Thu, Nov 24, 2022 at 08:59:00AM +0100, Jan Beulich wrote:
>>> - problematic wrt evtchn_upcall_pending, once set, preventing event
>>> injection later on.
>>> As you may have inferr
On 24.11.2022 09:42, Roger Pau Monné wrote:
> On Thu, Nov 24, 2022 at 08:59:00AM +0100, Jan Beulich wrote:
>> One related question here is whether vlapic_do_init() shouldn't have
>> the non-architectural side effect of clearing evtchn_upcall_pending.
>> While this again violates the principle of th
On Thu, Nov 24, 2022 at 09:42:40AM +0100, Roger Pau Monné wrote:
> On Thu, Nov 24, 2022 at 08:59:00AM +0100, Jan Beulich wrote:
> > - problematic wrt evtchn_upcall_pending, once set, preventing event
> > injection later on.
> > As you may have inferred already, I'm inclined to suggest to drop the
> On 23 Nov 2022, at 22:25, Andrew Cooper wrote:
>
> 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
> si
On Thu, Nov 24, 2022 at 06:15:15AM +0100, Marek Marczykowski-Górecki wrote:
> 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
On Thu, Nov 24, 2022 at 08:59:00AM +0100, Jan Beulich wrote:
> 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
On 24.11.2022 06:15, Marek Marczykowski-Górecki wrote:
> 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.
>
44 matches
Mail list logo
