On 12.08.2020 14:47, Roger Pau Monne wrote:
> Add a new vlapic_set_irq_callback helper in order to inject a vector
> and set a callback to be executed when the guest performs the end of
> interrupt acknowledgment.
One thing I don't understand at all for now is how these
callbacks are going to be
On 24.08.2020 18:39, Roger Pau Monné wrote:
> Would you be fine with clearing the callback in vlapic_handle_EOI and
Yes - as said, I'd prefer such a model.
> then vlapic_set_irq_callback complaining if it finds there's a
> previous callback different than the one provided already set for the
>
flight 152764 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152764/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 152332
flight 152769 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152769/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ad40eb4e6c9d5576cca24bc934441f5bb0231c04
baseline version:
ovmf
On 24.08.20 22:02, Stefano Stabellini wrote:
On Fri, 21 Aug 2020, Simon Leiner wrote:
On 20.08.20 20:35, Stefano Stabellini wrote:
Thank for the well-written analysis of the problem. The following
should
work to translate the virtual address properly in xenbus_grant_ring:
if
On 24.08.20 23:21, Thomas Gleixner wrote:
On Mon, Aug 24 2020 at 06:59, Jürgen Groß wrote:
On 21.08.20 02:24, Thomas Gleixner wrote:
+static __init void xen_setup_pci_msi(void)
+{
+ if (xen_initial_domain()) {
+ x86_msi.setup_msi_irqs = xen_initdom_setup_msi_irqs;
+
On Fri, 21 Aug 2020, Thomas Gleixner wrote:
> On Fri, Aug 21 2020 at 14:17, Jürgen Groß wrote:
> > On 21.08.20 13:19, Sergei Temerkhanov wrote:
> >>> Did you see any specific problem where handler_data is written by
> >> another component?
> >>
> >> I've posted this series in the thread
> >>
Hi Julien, Bertrand,
> -Original Message-
> From: Julien Grall
> Sent: 2020年8月25日 1:23
> To: Bertrand Marquis
> Cc: Wei Chen ; Xen-devel de...@lists.xenproject.org>; sstabell...@kernel.org; Andre Przywara
> ; Penny Zheng ; Kaly
> Xin ; nd
> Subject: Re: [PATCH v2 2/2] xen/arm: Throw
Hi,
> -Original Message-
> From: Julien Grall
> Sent: 2020年8月24日 21:15
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Andre Przywara ; Bertrand Marquis
> ; Penny Zheng ;
> Kaly Xin ; nd
> Subject: Re: [PATCH v2 1/2] xen/arm: Missing N1/A76/A75 FP
On Fri, Aug 21, 2020 at 1:23 AM Jan Beulich wrote:
>
> On 21.08.2020 09:38, Roman Shaposhnik wrote:
> > On Thu, Aug 20, 2020 at 11:47 PM Jan Beulich wrote:
> >> On 20.08.2020 21:31, Roman Shaposhnik wrote:
> >>> Well, default is overloaded. What I would like to see (and consider it
> >>> a void
flight 152750 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152750/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 18 guest-start/debian.repeat fail REGR. vs. 152715
On Fri, Aug 21, 2020 at 3:11 AM Andrew Cooper wrote:
>
> On 21/08/2020 07:50, Jan Beulich wrote:
> > On 20.08.2020 21:12, Roman Shaposhnik wrote:
> >> On Thu, Aug 20, 2020 at 5:56 AM Andrew Cooper
> >> wrote:
> >>> On 19/08/2020 23:50, Roman Shaposhnik wrote:
> Hi!
>
> below you
Hello again,
I'm now facing another issue with qemu-xen, this time on Xen 4.13
Starting a HVM domains with qemu-xen instead of qemu-dm fails with
(d9) Writing SMBIOS tables ...
(d9) Loading SeaBIOS ...
(d9) no BIOS ROM image found
(d9) *** HVMLoader bug at hvmloader.c:394
(d9) *** HVMLoader
Architectures which don't implement an M2P shouldn't be forced to implement
stubs. Implement them in common code.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
I'm
On 24/08/2020 12:58, Jan Beulich wrote:
> With changes done over time and as far as linking goes, the only special
> things about building with EFI support enabled are
> - the need for the dummy relocations object for xen.gz uniformly in all
> build stages,
> - the special efi/buildid.o file,
... including serialisation/deserialisation logic and unit tests.
There is no current way to configure this MSR correctly for guests.
The toolstack side this logic needs building, which is far easier to
do with it in place.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
On Mon, Aug 24, 2020 at 11:21:20AM +0100, Andrew Cooper wrote:
> On 24/08/2020 09:00, Jürgen Groß wrote:
> > On 24.08.20 09:51, Jan Beulich wrote:
> >> On 24.08.2020 09:23, Jürgen Groß wrote:
> >>> On 24.08.20 08:44, Jan Beulich wrote:
> On 23.08.2020 07:52, Jürgen Groß wrote:
> > On
On Mon, Aug 24, 2020 at 06:07:28PM +0200, Jan Beulich wrote:
> On 24.08.2020 16:44, Roger Pau Monné wrote:
> > On Mon, Aug 24, 2020 at 04:06:31PM +0200, Jan Beulich wrote:
> >> On 12.08.2020 14:47, Roger Pau Monne wrote:
> >>> Remove the unconditional call to hvm_dpci_msi_eoi in vlapic_handle_EOI
On Fri, 21 Aug 2020, Simon Leiner wrote:
> On 20.08.20 20:35, Stefano Stabellini wrote:
> > Thank for the well-written analysis of the problem. The following
> should
> > work to translate the virtual address properly in xenbus_grant_ring:
> >
> > if (is_vmalloc_addr(vaddr))
> >
flight 152726 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152726/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 152631
Hi Andrew,
On Mon, 24 Aug 2020, 19:15 Andrew Cooper, wrote:
> Architectures which don't implement an M2P shouldn't be forced to implement
> stubs. Implement them in common code.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC:
On Mon, Aug 24, 2020 at 04:06:31PM +0200, Jan Beulich wrote:
> On 12.08.2020 14:47, Roger Pau Monne wrote:
> > Remove the unconditional call to hvm_dpci_msi_eoi in vlapic_handle_EOI
> > and instead use the newly introduced EOI callback mechanism in order
> > to register a callback for MSI vectors
On Mon, Aug 24, 2020 at 11:24:06AM -0700, Roman Shaposhnik wrote:
> On Mon, Aug 24, 2020 at 11:12 AM Manuel Bouyer wrote:
> >
> > Hello,
> > with the recent XSA about qemu, I'm trying to switch the NetBSD port from
> > qemu-xen-traditional to qemu-xen (in Xen 4.11 for now, I'll look at
> > 4.13
On Mon, Aug 24, 2020 at 11:12 AM Manuel Bouyer wrote:
>
> Hello,
> with the recent XSA about qemu, I'm trying to switch the NetBSD port from
> qemu-xen-traditional to qemu-xen (in Xen 4.11 for now, I'll look at
> 4.13 later).
> One showstopper is that with qemu-xen, the bridge name is not passed
flight 152743 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152743/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4535fc312b76cb5b05b6a8064c1c64d9780f55ba
baseline version:
ovmf
Hello,
with the recent XSA about qemu, I'm trying to switch the NetBSD port from
qemu-xen-traditional to qemu-xen (in Xen 4.11 for now, I'll look at
4.13 later).
One showstopper is that with qemu-xen, the bridge name is not passed
any more to the qemu-ifup script. I tried adding a br= option to
flight 152721 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152721/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 152332
On Sat, Aug 22, 2020 at 02:36:37AM +0200, Thomas Gleixner wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> On Fri, Aug 21 2020 at 22:27, Thomas Gleixner
On 24/08/2020 13:34, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -34,17 +34,31 @@ EMIT_FILE;
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
>
> +#ifdef CONFIG_PV32
> +
> #define
On Fri, Aug 21, 2020 at 03:32:01PM +0100, George Dunlap wrote:
> Signed-off-by: George Dunlap
Acked-by: Roger Pau Monné
Thanks.
On 24/08/2020 13:34, Jan Beulich wrote:
> While in most cases code ahead of the invocation of set_gpfn_from_mfn()
> deals with shared pages, at least in set_typed_p2m_entry() I can't spot
> such handling (it's entirely possible there's code missing there). Let's
> try to play safe and add an extra
Hi Julien,
> On 24 Aug 2020, at 14:34, Julien Grall wrote:
>
> Hi Wei,
>
> On 24/08/2020 04:28, Wei Chen wrote:
>> Arm ID_AA64PFR0_EL1 register provides two fields to describe CPU
>> FP/SIMD implementations. Currently, we exactly know the meaning of
>> 0x0, 0x1 and 0xf of these fields. Xen
On 24/08/2020 13:35, Jan Beulich wrote:
> is_pv_32bit_domain() has become expensive, and its use here is
> redundant: Only 32-bit guests would ever get PGT_pae_xen_l2 set on
> their L2 page table pages anyway.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Possibly "if some other
flight 152739 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152739/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 24/08/2020 13:35, Jan Beulich wrote:
> While big endian x86 images are pretty unlikely to appear, merely
> logging endianness isn't of much use.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 24/08/2020 13:34, Jan Beulich wrote:
> It is already a little too heavy for a macro, and more logic is about to
> get added to it.
>
> This also allows reducing the scope of compat_machine_to_phys_mapping.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
It's a shame that we
On 24.08.2020 16:44, Roger Pau Monné wrote:
> On Mon, Aug 24, 2020 at 04:06:31PM +0200, Jan Beulich wrote:
>> On 12.08.2020 14:47, Roger Pau Monne wrote:
>>> Remove the unconditional call to hvm_dpci_msi_eoi in vlapic_handle_EOI
>>> and instead use the newly introduced EOI callback mechanism in
Hi Julien
Thanks for getting back to me.
On Mon, Aug 24, 2020 at 11:10 AM Julien Grall wrote:
>
> Hi,
>
> On 24/08/2020 15:23, luckybreak051779 wrote:
> > Xen Team:
> >
> > I am running Xen 4.13.0 on a 32-bit ARM processor. In a domU driver I
> > use the dma_map_single() function to obtain a
Hi,
On 24/08/2020 15:23, luckybreak051779 wrote:
Xen Team:
I am running Xen 4.13.0 on a 32-bit ARM processor. In a domU driver I
use the dma_map_single() function to obtain a DMA address.
How can I get the MFN of that DMA address from inside the domU?
We don't provide a way to find the
On Mon, Aug 24, 2020 at 03:11:41PM +0200, Jan Beulich wrote:
> On 04.08.2020 18:41, Nick Rosbrook wrote:
> > On Tue, Aug 4, 2020 at 12:02 PM Jan Beulich wrote:
> >>
> >> On 04.08.2020 17:57, Wei Liu wrote:
> >>> On Tue, Aug 04, 2020 at 05:53:49PM +0200, Jan Beulich wrote:
> On 04.08.2020
On Mon, Aug 24, 2020 at 9:06 AM Jan Beulich wrote:
>
> On 24.08.2020 15:00, Andrew Cooper wrote:
> > On 24/08/2020 13:34, Jan Beulich wrote:
> >> While in most cases code ahead of the invocation of set_gpfn_from_mfn()
> >> deals with shared pages, at least in set_typed_p2m_entry() I can't spot
>
Xen Team:
I am running Xen 4.13.0 on a 32-bit ARM processor. In a domU driver I use
the dma_map_single() function to obtain a DMA address.
How can I get the MFN of that DMA address from inside the domU? I need the
MFN to be able to differentiate between
two identical domUs running the same
On 24/08/2020 09:00, Jürgen Groß wrote:
> On 24.08.20 09:51, Jan Beulich wrote:
>> On 24.08.2020 09:23, Jürgen Groß wrote:
>>> On 24.08.20 08:44, Jan Beulich wrote:
On 23.08.2020 07:52, Jürgen Groß wrote:
> On 23.08.20 07:24, osstest service owner wrote:
>> flight 152672 linux-linus
On 12.08.2020 14:47, Roger Pau Monne wrote:
> Remove the unconditional call to hvm_dpci_msi_eoi in vlapic_handle_EOI
> and instead use the newly introduced EOI callback mechanism in order
> to register a callback for MSI vectors injected from passed through
> devices.
In patch 2 you merely invoke
Hi Wei,
On 24/08/2020 04:28, Wei Chen wrote:
Arm ID_AA64PFR0_EL1 register provides two fields to describe CPU
FP/SIMD implementations. Currently, we exactly know the meaning of
0x0, 0x1 and 0xf of these fields. Xen treats value < 8 as FP/SIMD
features presented. If there is a value 0x2 bumped
Hi,
> On 24 Aug 2020, at 04:28, Wei Chen wrote:
>
> Arm ID_AA64PFR0_EL1 register provides two fields to describe CPU
> FP/SIMD implementations. Currently, we exactly know the meaning of
> 0x0, 0x1 and 0xf of these fields. Xen treats value < 8 as FP/SIMD
> features presented. If there is a value
Hi,
On 24/08/2020 04:28, Wei Chen wrote:
Xen has cpu_has_fp/cpu_has_simd to detect whether the CPU supports
FP/SIMD or not. But currently, these two MACROs only consider value 0
of ID_AA64PFR0_EL1.FP/SIMD as FP/SIMD features enabled. But for CPUs
that support FP/SIMD and half-precision
On 04.08.2020 18:41, Nick Rosbrook wrote:
> On Tue, Aug 4, 2020 at 12:02 PM Jan Beulich wrote:
>>
>> On 04.08.2020 17:57, Wei Liu wrote:
>>> On Tue, Aug 04, 2020 at 05:53:49PM +0200, Jan Beulich wrote:
On 04.08.2020 17:50, Wei Liu wrote:
> On Tue, Aug 04, 2020 at 05:30:40PM +0200, Jan
On 24.08.2020 15:00, Andrew Cooper wrote:
> On 24/08/2020 13:34, Jan Beulich wrote:
>> While in most cases code ahead of the invocation of set_gpfn_from_mfn()
>> deals with shared pages, at least in set_typed_p2m_entry() I can't spot
>> such handling (it's entirely possible there's code missing
On 24.08.2020 14:50, Andrew Cooper wrote:
> On 24/08/2020 13:35, Jan Beulich wrote:
>> is_pv_32bit_domain() has become expensive, and its use here is
>> redundant: Only 32-bit guests would ever get PGT_pae_xen_l2 set on
>> their L2 page table pages anyway.
>>
>> Suggested-by: Andrew Cooper
>>
Under certain conditions CPUs can speculate into the instruction stream
past a RET instruction. Guard against this just like 3b7dab93f240
("x86/spec-ctrl: Protect against CALL/JMP straight-line speculation")
did - by inserting an "INT $3" insn. It's merely the mechanics of how to
achieve this that
is_pv_32bit_domain() has become expensive, and its use here is
redundant: Only 32-bit guests would ever get PGT_pae_xen_l2 set on
their L2 page table pages anyway.
Suggested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/include/asm-x86/x86_64/page.h
+++
While big endian x86 images are pretty unlikely to appear, merely
logging endianness isn't of much use.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -288,7 +288,8 @@ int __init
It is already a little too heavy for a macro, and more logic is about to
get added to it.
This also allows reducing the scope of compat_machine_to_phys_mapping.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@
While in most cases code ahead of the invocation of set_gpfn_from_mfn()
deals with shared pages, at least in set_typed_p2m_entry() I can't spot
such handling (it's entirely possible there's code missing there). Let's
try to play safe and add an extra check.
Signed-off-by: Jan Beulich
---
v2:
It's effectively unused in this case (as well as when "pv=no-32").
While touching their definitions anyway, also adjust section placement
of m2p_compat_vstart and compat_idle_pg_table_l2. Similarly, while
putting init_xen_pae_l2_slots() inside #ifdef, also move it to a PV-only
source file.
On 24.07.2020 16:19, Jan Beulich wrote:
> On 24.07.2020 14:11, Andrew Cooper wrote:
>> On 17/07/2020 14:10, Jan Beulich wrote:
>>> Since we intercept RTC/CMOS port accesses, let's do so consistently in
>>> all cases, i.e. also for e.g. a dword access to [006E,0071]. To avoid
>>> the risk of
As pointed out by Andrew, maintaining the compat M2P when !PV32
(or when "pv=no-32" was given) is a pointless waste of memory. Do
away with this, with a possible plan to subsequently use the
compat instance instead of the native one in shim mode with a
32-bit guest (requiring more intrusive
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-14364 / XSA-335
version 2
QEMU: usb: out-of-bounds r/w access issue
UPDATES IN VERSION 2
Don't break the DSO by eliding the SoB on the
Address at least the primary reason why 52bba67f8b87 ("efi/boot: Don't
free ebmalloc area at all") was put in place: Make xen_in_range() aware
of the freed range. This is in particular relevant for EFI-enabled
builds not actually running on EFI, as the entire range will be unused
in this case.
We're gaining such sections, and like .text.* and .data.* they shouldn't
be present in objects subject to automatic to-init conversion. Oddly
enough for quite some time we did have an instance breaking this rule,
which gets fixed at this occasion, by breaking out the EFI boot
allocator functions
Initially I merely noticed the regression addressed by a patch which
meanwhile has already gone in, but looking more closely revealed
further deficiencies. After having moved the FIXME in patch 1 I
couldn't resist and address that issue at least partly (patch 2),
seeing that three and a half years
There is no need for platform-wide, system-wide, or per-domain control
in this case. Hence avoid including this dead code in the build.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -23,7 +23,6 @@ obj-$(CONFIG_GDBSX) +=
A subsequent change will exclude domctl.c from getting built for a
particular configuration, yet the two functions get used from elsewhere.
While moving the code
- drop unmotivated uses of min_t(),
- fix style violations in the moved code,
- xfree() as early as possible.
Signed-off-by: Jan
There's no need for xen.efi at all, and there's also no need for EFI
support in xen.gz since the shim runs in PVH mode, i.e. without any
firmware (and hence by implication also without EFI one).
The slightly odd looking use of $(space) is to ensure the new ifneq()
evaluates consistently between
With changes done over time and as far as linking goes, the only special
things about building with EFI support enabled are
- the need for the dummy relocations object for xen.gz uniformly in all
build stages,
- the special efi/buildid.o file, which can't be made part of
efi/built_in.o, due to
This is a in part just loosely connected set of changes in particular
aiming at further shim size binary reduction.
Review feedback for v2 addressed for 1 and 2; 3 and 4 unchanged. One
patch was dropped.
1: x86/EFI: sanitize build logic
2: x86: don't build with EFI support in shim-exclusive mode
flight 152715 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152715/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 152684
flight 152718 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152718/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d4e0b9607c9a64a8eff20724b2e35ea2cd5bd33f
baseline version:
ovmf
On 24.08.2020 12:33, Norbert Kaminski wrote:
> I'm trying to boot Qubes 4.1 under the Heads (http://osresearch.net/).
> The Heads uses kexec to run the Xen 4.13 with Qubes kernel. During the
> boot process on the screen appear colorful artifacts, which are shown in
> this issue:
>
>
Hi all,
I'm trying to boot Qubes 4.1 under the Heads (http://osresearch.net/).
The Heads uses kexec to run the Xen 4.13 with Qubes kernel. During the
boot process on the screen appear colorful artifacts, which are shown in
this issue:
https://github.com/osresearch/heads/issues/789
The
From: Randy Dunlap
[ Upstream commit ee87e1557c42dc9c2da11c38e11b87c311569853 ]
../arch/x86/pci/xen.c: In function ‘pci_xen_init’:
../arch/x86/pci/xen.c:410:2: error: implicit declaration of function
‘acpi_noirq_set’; did you mean ‘acpi_irq_get’?
[-Werror=implicit-function-declaration]
From: Randy Dunlap
[ Upstream commit ee87e1557c42dc9c2da11c38e11b87c311569853 ]
../arch/x86/pci/xen.c: In function ‘pci_xen_init’:
../arch/x86/pci/xen.c:410:2: error: implicit declaration of function
‘acpi_noirq_set’; did you mean ‘acpi_irq_get’?
[-Werror=implicit-function-declaration]
From: Randy Dunlap
[ Upstream commit ee87e1557c42dc9c2da11c38e11b87c311569853 ]
../arch/x86/pci/xen.c: In function ‘pci_xen_init’:
../arch/x86/pci/xen.c:410:2: error: implicit declaration of function
‘acpi_noirq_set’; did you mean ‘acpi_irq_get’?
[-Werror=implicit-function-declaration]
From: Randy Dunlap
[ Upstream commit ee87e1557c42dc9c2da11c38e11b87c311569853 ]
../arch/x86/pci/xen.c: In function ‘pci_xen_init’:
../arch/x86/pci/xen.c:410:2: error: implicit declaration of function
‘acpi_noirq_set’; did you mean ‘acpi_irq_get’?
[-Werror=implicit-function-declaration]
This is a note to let you know that I've just added the patch titled
xen: don't reschedule in preemption off sections
to the 5.7-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
xen: don't reschedule in preemption off sections
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
xen: don't reschedule in preemption off sections
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
xen: don't reschedule in preemption off sections
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
xen: don't reschedule in preemption off sections
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
xen: don't reschedule in preemption off sections
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
On Thu, Aug 20, 2020 at 08:59:08AM +0200, Juergen Gross wrote:
> For support of long running hypercalls xen_maybe_preempt_hcall() is
> calling cond_resched() in case a hypercall marked as preemptible has
> been interrupted.
>
> Normally this is no problem, as only hypercalls done via some
On 24.08.20 09:51, Jan Beulich wrote:
On 24.08.2020 09:23, Jürgen Groß wrote:
On 24.08.20 08:44, Jan Beulich wrote:
On 23.08.2020 07:52, Jürgen Groß wrote:
On 23.08.20 07:24, osstest service owner wrote:
flight 152672 linux-linus real [real]
On 24.08.2020 09:23, Jürgen Groß wrote:
> On 24.08.20 08:44, Jan Beulich wrote:
>> On 23.08.2020 07:52, Jürgen Groß wrote:
>>> On 23.08.20 07:24, osstest service owner wrote:
flight 152672 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152672/
On 24.08.20 08:44, Jan Beulich wrote:
On 23.08.2020 07:52, Jürgen Groß wrote:
On 23.08.20 07:24, osstest service owner wrote:
flight 152672 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152672/
Regressions :-(
With 32-bit pv support now removed from the kernel the
flight 152712 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152712/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 152631
On 23.08.2020 07:52, Jürgen Groß wrote:
> On 23.08.20 07:24, osstest service owner wrote:
>> flight 152672 linux-linus real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/152672/
>>
>> Regressions :-(
>
> With 32-bit pv support now removed from the kernel the associated tests
> should
flight 152720 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152720/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On 21.08.20 02:24, Thomas Gleixner wrote:
To allow utilizing the irq domain pointer in struct device it is necessary
to make XEN/MSI irq domain compatible.
While the right solution would be to truly convert XEN to irq domains, this
is an exercise which is not possible for mere mortals with
89 matches
Mail list logo
