On 25.02.2021 02:22, Stefano Stabellini wrote:
> --- a/xen/include/public/features.h
> +++ b/xen/include/public/features.h
> @@ -114,6 +114,13 @@
> */
> #define XENFEAT_linux_rsdp_unrestricted 15
>
> +/*
> + * A direct-mapped (or 1:1 mapped) domain is a domain for which its
> + * local
On 24.02.2021 21:08, Andrew Cooper wrote:
> On 24/02/2021 10:26, Roger Pau Monne wrote:
>> Hello,
>>
>> Following two patches aim to make hvmloader standalone, so that it don't
>> try to use system headers. It shouldn't result in any functional
>> change.
>>
>> Thanks, Roger.
>
> After some
flight 159646 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159646/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
On 24.02.2021 17:39, Paul Durrant wrote:
> On 23/02/2021 16:29, Jan Beulich wrote:
>> When re-entering the main loop of xenvif_tx_check_gop() a 2nd time, the
>> special considerations for the head of the SKB no longer apply. Don't
>> mistakenly report ERROR to the frontend for the first entry in
flight 159656 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159656/
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
On 24.02.2021 18:17, Andrew Cooper wrote:
> On 23/02/2021 07:53, Jan Beulich wrote:
>> On 22.02.2021 17:36, Andrew Cooper wrote:
>>> On 19/02/2021 08:09, Jan Beulich wrote:
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -123,8 +123,13 @@ ifneq ($(efi-y),)
# Check
On 24.02.2021 18:17, Andrew Cooper wrote:
> On 23/02/2021 07:53, Jan Beulich wrote:
>> On 22.02.2021 17:36, Andrew Cooper wrote:
>>> On 19/02/2021 08:09, Jan Beulich wrote:
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -123,8 +123,13 @@ ifneq ($(efi-y),)
# Check
flight 159642 qemu-mainline real [real]
flight 159658 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159642/
http://logs.test-lab.xenproject.org/osstest/logs/159658/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
On Wed, Feb 24, 2021 at 08:30:45PM -0800, Roman Shaposhnik wrote:
> Right -- but that's not what distro builders use, right? I mean they do
> the whole sdeb -> deb business.
>
> In fact, to stay as faithful as possible -- I'd love to:
>1. unpack SDEB
>2. add a single patch to the set of
On Wed, Feb 24, 2021 at 7:44 PM Elliott Mitchell wrote:
>
> On Wed, Feb 24, 2021 at 07:06:25PM -0800, Roman Shaposhnik wrote:
> > I'm slightly confused about this patch -- it seems to me that it needs
> > to be applied to the guest kernel, correct?
> >
> > If that's the case -- the challenge I
On Wed, Feb 24, 2021 at 07:06:25PM -0800, Roman Shaposhnik wrote:
> I'm slightly confused about this patch -- it seems to me that it needs
> to be applied to the guest kernel, correct?
>
> If that's the case -- the challenge I have is that I need to re-build
> the Canonical (Ubuntu) distro kernel
Hi Jürgen!
sorry for the belated reply -- I wanted to externalize the VM before I
do -- but let me at least reply to you:
On Tue, Feb 23, 2021 at 5:17 AM Jürgen Groß wrote:
>
> On 18.02.21 06:21, Roman Shaposhnik wrote:
> > On Wed, Feb 17, 2021 at 12:29 AM Jürgen Groß >
2021年2月24日(水) 20:17 Gerd Hoffmann :
>
> On Tue, Feb 23, 2021 at 01:50:51PM +0900, Akihiko Odaki wrote:
> > 2021年2月22日(月) 19:57 Gerd Hoffmann :
> > >
> > > On Sun, Feb 21, 2021 at 10:34:14PM +0900, Akihiko Odaki wrote:
> > > > This change introduces an additional member, refresh_rate to
> > > >
Introduce two feature flags to tell the domain whether it is
direct-mapped or not. It allows the guest kernel to make informed
decisions on things such as swiotlb-xen enablement.
Currently, only Dom0 on ARM is direct-mapped, see:
xen/include/asm-arm/domain.h:is_domain_direct_mapped
flight 159626 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159626/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-3 19 xtf/test-pv32pae-selftest fail REGR. vs. 159475
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-qemut-rhel6hvm-intel
testid xen-boot
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
Tree: qemuu
On 24/02/2021 23:58, Volodymyr Babchuk wrote:
> And I am not mentioning x86 support there...
x86 uses per-pCPU stacks, not per-vCPU stacks.
Transcribing from an old thread which happened in private as part of an
XSA discussion, concerning the implications of trying to change this.
~Andrew
Julien Grall writes:
> On Wed, 24 Feb 2021 at 20:58, Volodymyr Babchuk
> wrote:
>>
>>
>> Hi Julien,
>>
>> Julien Grall writes:
>>
>>> On 23/02/2021 12:06, Volodymyr Babchuk wrote:
Hi Julien,
>>>
>>> Hi Volodymyr,
>>>
Julien Grall writes:
> On 23/02/2021 02:34, Volodymyr Babchuk
Hi Andrew,
Andrew Cooper writes:
> On 23/02/2021 02:34, Volodymyr Babchuk wrote:
>> Hello community,
>>
>> Subject of this cover letter is quite self-explanatory. This patch
>> series implements PoC for preemption in hypervisor mode.
>>
>> This is the sort of follow-up to recent discussion
flight 159644 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159644/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Wed, 24 Feb 2021 at 20:58, Volodymyr Babchuk
wrote:
>
>
> Hi Julien,
>
> Julien Grall writes:
>
> > On 23/02/2021 12:06, Volodymyr Babchuk wrote:
> >> Hi Julien,
> >
> > Hi Volodymyr,
> >
> >> Julien Grall writes:
> >>> On 23/02/2021 02:34, Volodymyr Babchuk wrote:
> >>> ... just rescheduling
Hi Julien,
Julien Grall writes:
> On 23/02/2021 12:06, Volodymyr Babchuk wrote:
>> Hi Julien,
>
> Hi Volodymyr,
>
>> Julien Grall writes:
>>> On 23/02/2021 02:34, Volodymyr Babchuk wrote:
>>> ... just rescheduling the vCPU. It will also give the opportunity for
>>> the guest to handle
flight 159640 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159640/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 35f87da8a2debd443ac842db0a3794b17914a8f4
baseline version:
ovmf
On 24/02/2021 10:26, Roger Pau Monne wrote:
> Hello,
>
> Following two patches aim to make hvmloader standalone, so that it don't
> try to use system headers. It shouldn't result in any functional
> change.
>
> Thanks, Roger.
After some experimentation in the arch container
Given foo.c as:
flight 159610 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159610/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
On 23/02/2021 07:13, Jan Beulich wrote:
> On 22.02.2021 17:47, Andrew Cooper wrote:
>> On 22/02/2021 14:22, Jan Beulich wrote:
>>> On 22.02.2021 15:14, Andrew Cooper wrote:
On 22/02/2021 10:27, Jan Beulich wrote:
> Now that we guard the entire Xen VA space against speculative abuse
>
From: Rafael J. Wysocki
The ACPI_DEBUG_PRINT() macro is used in a few places in
xen-acpi-cpuhotplug.c and xen-acpi-memhotplug.c for printing debug
messages, but that is questionable, because that macro belongs to
ACPICA and it should not be used elsewhere. In addition,
ACPI_DEBUG_PRINT()
On 23/02/2021 02:34, Volodymyr Babchuk wrote:
> With XEN preemption enabled, scheduler functions can be called with
> IRQs disabled (for example, at end of IRQ handler), so we should
> save and restore IRQ state in schedulers code.
>
> Signed-off-by: Volodymyr Babchuk
These functions need to
flight 159629 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159629/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 159600
Tests which
flight 159606 qemu-mainline real [real]
flight 159639 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159606/
http://logs.test-lab.xenproject.org/osstest/logs/159639/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
On 23/02/2021 02:34, Volodymyr Babchuk wrote:
> Hello community,
>
> Subject of this cover letter is quite self-explanatory. This patch
> series implements PoC for preemption in hypervisor mode.
>
> This is the sort of follow-up to recent discussion about latency
> ([1]).
>
> Motivation
>
On 23/02/2021 07:53, Jan Beulich wrote:
> On 22.02.2021 17:36, Andrew Cooper wrote:
>> On 19/02/2021 08:09, Jan Beulich wrote:
>>> --- a/xen/arch/x86/Makefile
>>> +++ b/xen/arch/x86/Makefile
>>> @@ -123,8 +123,13 @@ ifneq ($(efi-y),)
>>> # Check if the compiler supports the MS ABI.
>>> export
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in
flight 159619 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159619/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 739a506b18c4f694b8d5d2f3424a329c45d737ba
baseline version:
ovmf
Hi,
Just to inform you that after talking with Andrew, we identified that latest
workaround for recent Intel laptop (this series of patches
https://github.com/QubesOS/qubes-vmm-xen/commit/075e6b1) is failing on my
system having AMD Ryzen 1800X CPU and Asrock X370 Gaming K4 as motherboard.
On 23/02/2021 16:29, Jan Beulich wrote:
When re-entering the main loop of xenvif_tx_check_gop() a 2nd time, the
special considerations for the head of the SKB no longer apply. Don't
mistakenly report ERROR to the frontend for the first entry in the list,
even if - from all I can tell - this
On Wed, Feb 24, 2021 at 8:55 AM Oleksandr Andrushchenko
wrote:
>
> Hello, Jan!
>
> On 2/23/21 6:41 PM, Jan Beulich wrote:
> > By having selected DRM_XEN, I was assuming I would build the frontend
> > driver. As it turns out this is a dummy option, and I have really not
> > been building this
Hi Roger,
These seems to be genuine breakages:
https://gitlab.com/xen-project/patchew/xen/-/pipelines/260986219
FYI keep an eye on the patchew gitlab-ci as you should be able to see
the alpine linux tests pass once your series is fixed.
Cheers,
Stefano
On Wed, 24 Feb 2021,
On 24.02.2021 16:58, Jan Beulich wrote:
> On 24.02.2021 10:43, Julien Grall wrote:
>> --- a/xen/drivers/passthrough/x86/iommu.c
>> +++ b/xen/drivers/passthrough/x86/iommu.c
>> @@ -149,6 +149,13 @@ int arch_iommu_domain_init(struct domain *d)
>>
>> void arch_iommu_domain_destroy(struct domain
On Wed, Feb 24, 2021 at 04:01:13PM +0100, Jan Beulich wrote:
> On 24.02.2021 15:58, Roger Pau Monne wrote:
> > Those are need by the rombios relocation code in hvmloader. Fixes the
> > following build error:
> >
> > 32bitbios_support.c: In function 'relocate_32bitbios':
> >
Roger Pau Monne writes ("[PATCH for-4.15] elfstructs: add relocation defines
for i386"):
> Those are need by the rombios relocation code in hvmloader. Fixes the
> following build error:
>
> 32bitbios_support.c: In function 'relocate_32bitbios':
> 32bitbios_support.c:130:18: error: 'R_386_PC32'
On 24.02.2021 15:58, Roger Pau Monne wrote:
> Those are need by the rombios relocation code in hvmloader. Fixes the
> following build error:
>
> 32bitbios_support.c: In function 'relocate_32bitbios':
> 32bitbios_support.c:130:18: error: 'R_386_PC32' undeclared (first use in this
> function); did
Those are need by the rombios relocation code in hvmloader. Fixes the
following build error:
32bitbios_support.c: In function 'relocate_32bitbios':
32bitbios_support.c:130:18: error: 'R_386_PC32' undeclared (first use in this
function); did you mean 'R_X86_64_PC32'?
case R_386_PC32:
On 24.02.2021 15:33, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH 2/2] hvmloader: do not include system
> headers for type declarations"):
>> At what point do we just declare Alpine broken? These are all
>> freestanding headers, an explicitly available for use, in the way we use
>>
Andrew Cooper writes ("Re: [PATCH 2/2] hvmloader: do not include system headers
for type declarations"):
> At what point do we just declare Alpine broken? These are all
> freestanding headers, an explicitly available for use, in the way we use
> them.
There is IMO nothing wrong with Alpine
flight 159624 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159624/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 159600
Tests which
On 24.02.2021 10:43, Julien Grall wrote:
> From: Julien Grall
>
> The new x86 IOMMU page-tables allocator will release the pages when
> relinquishing the domain resources. However, this is not sufficient
> when the domain is dying because nothing prevents page-table to be
> allocated.
>
> As
flight 159602 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159602/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 8 xen-boot fail REGR. vs. 159475
Jan Beulich writes ("Re: [PATCH v2 0/8] x86/PV: avoid speculation abuse through
guest accessors"):
> On 24.02.2021 14:08, Ian Jackson wrote:
> > For 7, I remember what I think was an IRC conversation where someone
> > (you, I think) said you had examined the generated asm and it was
> >
On 24/02/2021 11:07, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH 2/2] hvmloader: do not include system headers
> for type declarations"):
>> Like the hypervisor, we should prefer using __SIZE_TYPE__
>> when available.
> I disagree.
size_t is obnoxious in the C spec. It might not be the
On 24.02.2021 14:08, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH v2 0/8] x86/PV: avoid speculation abuse
> through guest accessors"):
>> On 19.02.2021 16:50, Ian Jackson wrote:
>>> Jan Beulich writes ("[PATCH v2 0/8] x86/PV: avoid speculation abuse through
>>> guest accessors"):
4:
On 24.02.2021 13:01, Roger Pau Monné wrote:
> On Wed, Feb 24, 2021 at 11:51:39AM +0100, Jan Beulich wrote:
>> On 24.02.2021 11:26, Roger Pau Monne wrote:
>>> --- /dev/null
>>> +++ b/tools/firmware/hvmloader/types.h
>>> @@ -0,0 +1,47 @@
>>> +#ifndef _HVMLOADER_TYPES_H_
>>> +#define
Jan Beulich writes ("Re: [PATCH v2 0/8] x86/PV: avoid speculation abuse through
guest accessors"):
> On 19.02.2021 16:50, Ian Jackson wrote:
> > Jan Beulich writes ("[PATCH v2 0/8] x86/PV: avoid speculation abuse through
> > guest accessors"):
> >> 4: rename {get,put}_user() to {get,put}_guest()
From: Jan Beulich
[ Upstream commit 871997bc9e423f05c7da7c9178e62dde5df2a7f8 ]
The function uses a goto-based loop, which may lead to an earlier error
getting discarded by a later iteration. Exit this ad-hoc loop when an
error was encountered.
The out-of-memory error path additionally fails to
From: Jan Beulich
[ Upstream commit 871997bc9e423f05c7da7c9178e62dde5df2a7f8 ]
The function uses a goto-based loop, which may lead to an earlier error
getting discarded by a later iteration. Exit this ad-hoc loop when an
error was encountered.
The out-of-memory error path additionally fails to
On Wed, Feb 24, 2021 at 12:11:45PM +, Andrew Cooper wrote:
> On 24/02/2021 10:26, Roger Pau Monne wrote:
> > Instead create a private types.h header that contains the set of types
> > that are required by hvmloader. Replace include occurrences of std*
> > headers with type.h. Note that
On 24/02/2021 10:26, Roger Pau Monne wrote:
> Instead create a private types.h header that contains the set of types
> that are required by hvmloader. Replace include occurrences of std*
> headers with type.h. Note that including types.h directly is not
> required in util.c because it already
flight 159613 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159613/
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
On Wed, Feb 24, 2021 at 11:51:39AM +0100, Jan Beulich wrote:
> On 24.02.2021 11:26, Roger Pau Monne wrote:
> > --- /dev/null
> > +++ b/tools/firmware/hvmloader/types.h
> > @@ -0,0 +1,47 @@
> > +#ifndef _HVMLOADER_TYPES_H_
> > +#define _HVMLOADER_TYPES_H_
> > +
> > +typedef unsigned char uint8_t;
>
On 24.02.2021 12:07, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH 2/2] hvmloader: do not include system headers
> for type declarations"):
>> On 24.02.2021 11:26, Roger Pau Monne wrote:
>>> --- /dev/null
>>> +++ b/tools/firmware/hvmloader/types.h
>>> @@ -0,0 +1,47 @@
>>> +#ifndef
On Tue, Feb 23, 2021 at 01:50:51PM +0900, Akihiko Odaki wrote:
> 2021年2月22日(月) 19:57 Gerd Hoffmann :
> >
> > On Sun, Feb 21, 2021 at 10:34:14PM +0900, Akihiko Odaki wrote:
> > > This change introduces an additional member, refresh_rate to
> > > qemu_edid_info in include/hw/display/edid.h.
> > >
>
On 19.02.2021 16:50, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH v2 0/8] x86/PV: avoid speculation abuse through
> guest accessors"):
>> Re-sending primarily for the purpose of getting a release ack, an
>> explicit release nak, or an indication of there not being a need,
>> all for at least
Jan Beulich writes ("Re: [PATCH 2/2] hvmloader: do not include system headers
for type declarations"):
> On 24.02.2021 11:26, Roger Pau Monne wrote:
> > --- /dev/null
> > +++ b/tools/firmware/hvmloader/types.h
> > @@ -0,0 +1,47 @@
> > +#ifndef _HVMLOADER_TYPES_H_
> > +#define _HVMLOADER_TYPES_H_
Julien Grall writes ("[for-4.15][RESEND PATCH v4 0/2] xen/iommu: Collection of
bug fixes for IOMMU teardown"):
> This series is a collection of bug fixes for the IOMMU teardown code.
> All of them are candidate for 4.15 as they can either leak memory or
> lead to host crash/host corruption.
>
>
Roger Pau Monne writes ("[PATCH 0/2] hvmloader: drop usage of system headers"):
> Following two patches aim to make hvmloader standalone, so that it don't
> try to use system headers. It shouldn't result in any functional
> change.
Both patches:
Reviewed-by: Ian Jackson
Given its status as a
On 24.02.2021 11:26, Roger Pau Monne wrote:
> --- /dev/null
> +++ b/tools/firmware/hvmloader/types.h
> @@ -0,0 +1,47 @@
> +#ifndef _HVMLOADER_TYPES_H_
> +#define _HVMLOADER_TYPES_H_
> +
> +typedef unsigned char uint8_t;
> +typedef signed char int8_t;
> +
> +typedef unsigned short uint16_t;
>
On 24.02.2021 11:26, Roger Pau Monne wrote:
> Do not use the system provided elf.h, and instead use elfstructs.h
> from libelf.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
Instead create a private types.h header that contains the set of types
that are required by hvmloader. Replace include occurrences of std*
headers with type.h. Note that including types.h directly is not
required in util.c because it already includes util.h which in turn
includes the newly created
Do not use the system provided elf.h, and instead use elfstructs.h
from libelf.
Signed-off-by: Roger Pau Monné
---
tools/firmware/hvmloader/32bitbios_support.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/firmware/hvmloader/32bitbios_support.c
Hello,
Following two patches aim to make hvmloader standalone, so that it don't
try to use system headers. It shouldn't result in any functional
change.
Thanks, Roger.
Roger Pau Monne (2):
hvmloader: use Xen private header for elf structs
hvmloader: do not include system headers for type
On Tue, Feb 23, 2021 at 05:08:43PM -0800, Stefano Stabellini wrote:
> The hvmloader build on Alpine Linux x86_64 currenly fails:
>
>
> hvmloader.c: In function 'init_vm86_tss':
> hvmloader.c:202:39: error: left shift count >= width of type
> [-Werror=shift-count-overflow]
> 202 |
On 23/02/2021 12:06, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
Julien Grall writes:
On 23/02/2021 02:34, Volodymyr Babchuk wrote:
... just rescheduling the vCPU. It will also give the opportunity for
the guest to handle interrupts.
If you don't return to the guest, then risk to
flight 159620 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159620/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 5d94433a66df29ce314696a13bdd324ec0e342fe
baseline version:
xen
From: Julien Grall
The new per-domain IOMMU page-table allocator will now free the
page-tables when domain's resources are relinquished. However, the
per-domain IOMMU structure will still contain a dangling pointer to
the root page-table.
Xen may access the IOMMU page-tables afterwards at least
From: Julien Grall
Hi all,
This series is a collection of bug fixes for the IOMMU teardown code.
All of them are candidate for 4.15 as they can either leak memory or
lead to host crash/host corruption.
This is sent directly on xen-devel because all the issues were either
introduced in 4.15 or
From: Julien Grall
The new x86 IOMMU page-tables allocator will release the pages when
relinquishing the domain resources. However, this is not sufficient
when the domain is dying because nothing prevents page-table to be
allocated.
As the domain is dying, it is not necessary to continue to
Hi all,
Please ignore this version. I forgot to CC the maintainers on it. I will
resend a new series.
Cheers,
On 23/02/2021 12:34, Julien Grall wrote:
From: Julien Grall
Hi all,
This series is a collection of bug fixes for the IOMMU teardown code.
All of them are candidate for 4.15 as
On 09.02.2021 13:57, Jan Beulich wrote:
> To reduce latency on time_calibration_tsc_rendezvous()'s last loop
> iteration, separate fields written on the last iteration enough from the
> crucial field read by all CPUs on the last iteration such that they end
> up in distinct cache lines. Prefetch
78 matches
Mail list logo
