On 10.2.2021 3.59, Elliott Mitchell wrote:
On Tue, Feb 09, 2021 at 11:53:34AM -0800, Stefano Stabellini wrote:
This fixes Xen boot on RPi4. Some RPi4 kernels have the following node
on their device trees:
IMO I like keeping the reference to Linux kernel d1ac0002dd29 in the
commit message.
flight 159149 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159149/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm broken
test-amd64-i386-libvirt-xsm
> From: Julien Grall
> Sent: Tuesday, February 9, 2021 11:28 PM
>
> 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 root
> page-table (i.e. hd->arch.pg_maddr) will not be cleared.
It's
On Tue, Feb 09, 2021 at 11:53:34AM -0800, Stefano Stabellini wrote:
> This fixes Xen boot on RPi4. Some RPi4 kernels have the following node
> on their device trees:
IMO I like keeping the reference to Linux kernel d1ac0002dd29 in the
commit message. The commit is distinctly informative and
flight 159191 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159191/
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
verify_patch_size() is a maximum size check, and doesn't have a minimum bound.
If the microcode container encodes a blob with a length less than 64 bytes,
the subsequent calls to microcode_fits()/compare_header() may read off the end
of the buffer.
Fixes: 4de936a38a ("x86/ucode/amd: Rework
From: Nadav Amit
To improve TLB shootdown performance, flush the remote and local TLBs
concurrently. Introduce flush_tlb_multi() that does so. Introduce
paravirtual versions of flush_tlb_multi() for KVM, Xen and hyper-v (Xen
and hyper-v are only compile-tested).
While the updated smp
From: Nadav Amit
This is a respin of a rebased version of an old series, which I did not
follow, as I was preoccupied with personal issues (sorry).
The series improve TLB shootdown by flushing the local TLB concurrently
with remote TLBs, overlapping the IPI delivery time with the local
flush.
flight 159184 xen-unstable-smoke real [real]
flight 159188 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159184/
http://logs.test-lab.xenproject.org/osstest/logs/159188/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
Currently, a failure of verify_patch_size() causes an early abort of the
microcode blob loop, which in turn causes a second go around the main
container loop, ultimately failing the UCODE_MAGIC check.
First, check for errors after the blob loop. An error here is unrecoverable,
so avoid going
On Tue, 9 Feb 2021, Stefano Stabellini wrote:
> On Tue, 9 Feb 2021, Rahul Singh wrote:
> > > On 8 Feb 2021, at 6:49 pm, Stefano Stabellini
> > > wrote:
> > >
> > > Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
> > > The offending chunk is:
> > >
> > > #define
On Tue, 9 Feb 2021 at 20:28, Paul Durrant wrote:
>
> > -Original Message-
> > From: Julien Grall
> > Sent: 09 February 2021 15:28
> > To: xen-devel@lists.xenproject.org
> > Cc: hongy...@amazon.co.uk; i...@xenproject.org; Julien Grall
> > ; Jan Beulich
> > ; Paul Durrant
> > Subject:
flight 159143 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159143/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 472276f59bba2b22bb882c5c6f5479754e68d467
baseline version:
ovmf
On Tue, 9 Feb 2021 at 17:31, Stefano Stabellini wrote:
>
> On Tue, 9 Feb 2021, Ian Jackson wrote:
> > Jan Beulich writes ("Re: [PATCH v2] xen/arm: fix
> > gnttab_need_iommu_mapping"):
> > > On 08.02.2021 21:24, Stefano Stabellini wrote:
> > ...
> > > > For these cases, I would just follow a
On 20.01.21 18:40, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
Sorry for the late response.
On 17/01/2021 22:22, Oleksandr wrote:
On 15.01.21 23:30, Julien Grall wrote:
On 12/01/2021 21:52, Oleksandr Tyshchenko wrote:
From: Julien Grall
So I am not quite too sure how this new
flight 159131 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159131/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-raw broken in 159052
> -Original Message-
> From: Julien Grall
> Sent: 09 February 2021 15:28
> To: xen-devel@lists.xenproject.org
> Cc: hongy...@amazon.co.uk; i...@xenproject.org; Julien Grall
> ; Jan Beulich
> ; Andrew Cooper ; Kevin Tian
> ;
> Paul Durrant
> Subject: [for-4.15][PATCH v2 5/5] xen/iommu:
On Tue, 9 Feb 2021, Rahul Singh wrote:
> > On 8 Feb 2021, at 6:49 pm, Stefano Stabellini
> > wrote:
> >
> > Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
> > The offending chunk is:
> >
> > #define gnttab_need_iommu_mapping(d)\
> > -
> -Original Message-
> From: Julien Grall
> Sent: 09 February 2021 15:28
> To: xen-devel@lists.xenproject.org
> Cc: hongy...@amazon.co.uk; i...@xenproject.org; Julien Grall
> ; Jan Beulich
> ; Paul Durrant
> Subject: [for-4.15][PATCH v2 4/5] xen/iommu: x86: Don't leak the IOMMU
>
> -Original Message-
> From: Julien Grall
> Sent: 09 February 2021 15:28
> To: xen-devel@lists.xenproject.org
> Cc: hongy...@amazon.co.uk; i...@xenproject.org; Julien Grall
> ; Jan Beulich
> ; Paul Durrant
> Subject: [for-4.15][PATCH v2 3/5] xen/iommu: iommu_map: Don't crash the
>
> -Original Message-
> From: Julien Grall
> Sent: 09 February 2021 15:28
> To: xen-devel@lists.xenproject.org
> Cc: hongy...@amazon.co.uk; i...@xenproject.org; Julien Grall
> ; Jan Beulich
> ; Paul Durrant
> Subject: [for-4.15][PATCH v2 2/5] xen/iommu: Check if the IOMMU was
>
On Tue, 9 Feb 2021, Andrew Cooper wrote:
> On 09/02/2021 19:53, Stefano Stabellini wrote:
> > diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> > index 18825e333e..f1a96a3b90 100644
> > --- a/xen/common/device_tree.c
> > +++ b/xen/common/device_tree.c
> > @@ -563,14 +563,28 @@
> -Original Message-
> From: Xen-devel On Behalf Of Julien
> Grall
> Sent: 09 February 2021 15:28
> To: xen-devel@lists.xenproject.org
> Cc: hongy...@amazon.co.uk; i...@xenproject.org; Julien Grall
> ; Jan Beulich
> ; Andrew Cooper ; Roger Pau
> Monné
> ; Wei Liu
> Subject:
On 09/02/2021 19:53, Stefano Stabellini wrote:
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 18825e333e..f1a96a3b90 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -563,14 +563,28 @@ static unsigned int dt_bus_default_get_flags(const
>
On Tue, 9 Feb 2021, Stefano Stabellini wrote:
> PCI buses differ from default buses in a few important ways, so it is
> important to detect them properly. Normally, PCI buses are expected to
> have the following property:
>
> device_type = "pci"
>
> In reality, it is not always the case. To
PCI buses differ from default buses in a few important ways, so it is
important to detect them properly. Normally, PCI buses are expected to
have the following property:
device_type = "pci"
In reality, it is not always the case. To handle PCI bus nodes that
don't have the device_type
On Tue, 9 Feb 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 09/02/2021 17:47, Stefano Stabellini wrote:
> > On Tue, 9 Feb 2021, Bertrand Marquis wrote:
> > > Hi Stefano,
> > >
> > > > On 8 Feb 2021, at 23:56, Stefano Stabellini
> > > > wrote:
> > > >
> > > > PCI buses differ from default
branch xen-unstable
xenbranch xen-unstable
job test-arm64-arm64-xl-seattle
testid guest-start
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Andrew Cooper writes ("Re: [PATCH for-4.15] x86/ucode: Fix microcode payload
size for Fam19 processors"):
> On 09/02/2021 17:17, Ian Jackson wrote:
> > Jan Beulich writes ("Re: [PATCH for-4.15] x86/ucode: Fix microcode payload
> > size for Fam19 processors"):
...
> >> How certain is it that
The recent Debian update broke some guest setup. Roll back.
CC: Julien Grall
CC: Stefano Stabellini
Signed-off-by: Ian Jackson
---
production-config | 2 ++
1 file changed, 2 insertions(+)
diff --git a/production-config b/production-config
index e7009a55..126c5d3b 100644
---
This version was generated by running mg-debian-installer-update-all
with the recent changes to handle snapshots, and to use that for
buster armhf.
Signed-off-by: Ian Jackson
---
production-config | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/production-config
NFC with existing config.
Signed-off-by: Ian Jackson
---
mg-debian-installer-update | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/mg-debian-installer-update b/mg-debian-installer-update
index 5e890d34..4fb4bc21 100755
--- a/mg-debian-installer-update
+++
No functional change with existing configs.
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 35 ---
README | 4
make-distros-flight | 2 ++
production-config | 3 ---
ts-debian-install | 4 +++-
5 files changed, 41 insertions(+), 7
When using snapshots, we can get a redirect and then we don't
recurse. There doesn't seem to be a suitable option for wget, so do
this by hand before we call wget -m.
Signed-off-by: Ian Jackson
---
mg-debian-installer-update | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff
mg-debian-installer-update is going to want this. NFC.
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 05cc6e1f..dee52b3d 100644
--- a/Osstest/Debian.pm
+++
This is kind of duplicative of the logic in preseed_backports_packages
but I don't want to mess with that now.
Signed-off-by: Ian Jackson
---
Osstest.pm| 2 ++
Osstest/Debian.pm | 16
2 files changed, 18 insertions(+)
diff --git a/Osstest.pm b/Osstest.pm
index
Hi Stefano,
On 09/02/2021 17:47, Stefano Stabellini wrote:
On Tue, 9 Feb 2021, Bertrand Marquis wrote:
Hi Stefano,
On 8 Feb 2021, at 23:56, Stefano Stabellini wrote:
PCI buses differ from default buses in a few important ways, so it is
important to detect them properly. Normally, PCI buses
On Tue, 9 Feb 2021, Bertrand Marquis wrote:
> Hi Stefano,
>
> > On 8 Feb 2021, at 23:56, Stefano Stabellini wrote:
> >
> > PCI buses differ from default buses in a few important ways, so it is
> > important to detect them properly. Normally, PCI buses are expected to
> > have the following
On 09/02/2021 17:17, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH for-4.15] x86/ucode: Fix microcode payload
> size for Fam19 processors"):
>> On 09.02.2021 16:33, Andrew Cooper wrote:
>>> The original limit provided wasn't accurate. Blobs are in fact rather
>>> larger.
>>>
>>> Fixes:
flight 159130 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159130/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl broken
test-arm64-arm64-xl-seattle
On Tue, 9 Feb 2021, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH v2] xen/arm: fix gnttab_need_iommu_mapping"):
> > On 08.02.2021 21:24, Stefano Stabellini wrote:
> ...
> > > For these cases, I would just follow a simple rule of thumb:
> > > - is the submitter willing to provide the
Jan Beulich writes ("Re: [PATCH for-4.15] x86/ucode: Fix microcode payload size
for Fam19 processors"):
> On 09.02.2021 16:33, Andrew Cooper wrote:
> > The original limit provided wasn't accurate. Blobs are in fact rather
> > larger.
> >
> > Fixes: fe36a173d1 ("x86/amd: Initial support for
Olaf Hering writes ("Re: [PATCH v20210209 3/4] xl: optionally print timestamps
when running xl commands"):
> Am Tue, 9 Feb 2021 16:53:06 +
> schrieb Ian Jackson :
>
> > This part of the commit message talks about -t rather than -T. I will
> > fix that on commit.
>
> It is really the
Am Tue, 9 Feb 2021 17:12:28 +
schrieb Ian Jackson :
> Also, Olaf, please CC Andy on these migration-related patches.
Can this be automated via MAINTAINERS, so that scripts/get_maintainer.pl
addresses the people who feel responsible for it? Right now it ends up in your
queue due to
Olaf Hering writes ("[PATCH v20210209 4/4] xl: disable --debug option for xl
migrate"):
> xl migrate --debug used to track every pfn in every batch of pages.
>
> Since commit cfa955591caea5d7ec505cdcbf4442f2d6e889e1 from Xen 4.6 the
> debug flag changed meaning from "verify transferred memory
Am Tue, 9 Feb 2021 16:53:06 +
schrieb Ian Jackson :
> This part of the commit message talks about -t rather than -T. I will
> fix that on commit.
It is really the lowercase t.
01f78a81ae56220dd496a61185ba5dfae30dc2fe did not adjust the output in
tools/libxl/xl_cmdimpl.c:help().
Olaf
On 09.02.2021 17:06, Roger Pau Monné wrote:
> On Thu, Jan 14, 2021 at 04:04:32PM +0100, Jan Beulich wrote:
>> The "guest" variants are intended to work with (potentially) fully guest
>> controlled addresses, while the "unsafe" variants are not. Subsequently
>> we will want them to have different
Olaf Hering writes ("[PATCH v20210209 3/4] xl: optionally print timestamps when
running xl commands"):
> Add a global option "-T" to xl to enable timestamps in the output from
> libxl and libxc. This is most useful with long running commands such
> as "migrate".
>
> During 'xl -v.. migrate domU
Olaf Hering writes ("[PATCH v20210209 2/4] tools: add with-xen-scriptdir
configure option"):
> Some distros plan for fresh installations will have an empty /etc,
> whose content will not be controlled by the package manager anymore.
>
> To make this possible, add a knob to configure to allow
Olaf Hering writes ("[PATCH v20210209 1/4] tools: move CONFIG_DIR and
XEN_CONFIG_DIR in paths.m4"):
> Upcoming changes need to reuse XEN_CONFIG_DIR.
>
> In its current location the assignment happens too late. Move it up
> in the file, along with CONFIG_DIR. Their only dependency is
>
On 09.02.2021 16:33, Andrew Cooper wrote:
> The original limit provided wasn't accurate. Blobs are in fact rather larger.
>
> Fixes: fe36a173d1 ("x86/amd: Initial support for Fam19h processors")
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
> --- a/xen/arch/x86/cpu/microcode/amd.c
>
Julien Grall writes ("[for-4.15][PATCH v2 0/5] xen/iommu: Collection of bug
fixes for IOMMU teadorwn"):
> From: Julien Grall
...
> 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
On Thu, Jan 14, 2021 at 04:04:57PM +0100, Jan Beulich wrote:
> Inspired by
> https://lore.kernel.org/lkml/f12e7d3cecf41b2c29734ea45a393be21d4a8058.1597848273.git.jpoim...@redhat.com/
> and prior work in that area of x86 Linux, suppress speculation with
> guest specified pointer values by suitably
On Thu, Jan 14, 2021 at 04:04:32PM +0100, Jan Beulich wrote:
> The "guest" variants are intended to work with (potentially) fully guest
> controlled addresses, while the "unsafe" variants are not. Subsequently
> we will want them to have different behavior, so as first step identify
> which one is
xl migrate --debug used to track every pfn in every batch of pages.
Since commit cfa955591caea5d7ec505cdcbf4442f2d6e889e1 from Xen 4.6 the
debug flag changed meaning from "verify transferred memory during live
migration" to "verify transferred memory in remus/colo". At least xl
will not be able
Add a global option "-T" to xl to enable timestamps in the output from
libxl and libxc. This is most useful with long running commands such
as "migrate".
During 'xl -v.. migrate domU host' a large amount of debug is generated.
It is difficult to map each line to the sending and receiving side.
Some distros plan for fresh installations will have an empty /etc,
whose content will not be controlled by the package manager anymore.
To make this possible, add a knob to configure to allow storing the
hotplug scripts to libexec instead of /etc/xen/scripts.
The current default remains
Upcoming changes need to reuse XEN_CONFIG_DIR.
In its current location the assignment happens too late. Move it up
in the file, along with CONFIG_DIR. Their only dependency is
sysconfdir, which may also be adjusted in this file.
No functional change intended.
Signed-off-by: Olaf Hering
---
As discussed in the v20210111 thread, split out and redo a few xl and
configure.ac specific changes.
Olaf
Olaf Hering (4):
tools: move CONFIG_DIR and XEN_CONFIG_DIR in paths.m4
tools: add with-xen-scriptdir configure option
xl: optionally print timestamps when running xl commands
xl:
The original limit provided wasn't accurate. Blobs are in fact rather larger.
Fixes: fe36a173d1 ("x86/amd: Initial support for Fam19h processors")
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Ian Jackson
For 4.15. This is a very targetted fix at AMD
flight 159135 qemu-mainline real [real]
flight 159160 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159135/
http://logs.test-lab.xenproject.org/osstest/logs/159160/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
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 root
page-table (i.e. hd->arch.pg_maddr) will not be cleared.
Xen may access the IOMMU page-tables afterwards at least in the case of
PV domain:
From: Julien Grall
The new IOMMU page-tables allocator will release the pages when
relinquish the domain resources. However, this is not sufficient when
the domain is dying because nothing prevents page-table to be allocated.
iommu_alloc_pgtable() is now checking if the domain is dying before
From: Julien Grall
It is a bit pointless to crash a domain that is already dying. This will
become more an annoyance with a follow-up change where page-table
allocation will be forbidden when the domain is dying.
Security wise, there is no change as the devices would still have access
to the
From: Julien Grall
Currently, the IOMMU page-tables will be populated early in the domain
creation if the hardware is able to virtualize the local APIC. However,
the IOMMU page tables will not be freed during early failure and will
result to a leak.
An assigned device should not need to DMA
From: Julien Grall
is_iommu_enabled() will return true even if the IOMMU has not been
initialized (e.g. the ops are not set).
In the case of an early failure in arch_domain_init(), the function
iommu_destroy_domain() will be called even if the IOMMU is not
initialized.
This will result to
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
On Tue, Feb 09, 2021 at 04:14:41PM +0100, Jan Beulich wrote:
> On 09.02.2021 15:55, Roger Pau Monné wrote:
> > On Thu, Jan 14, 2021 at 04:04:11PM +0100, Jan Beulich wrote:
> >> The "guest" variants are intended to work with (potentially) fully guest
> >> controlled addresses, while the "unsafe"
On Tue, Feb 09, 2021 at 03:57:22PM +0100, Jan Beulich wrote:
> I did change the paragraph to read
>
> The "guest" variants are intended to work with (potentially) fully guest
> controlled addresses, while the "unsafe" variants are intended to be
> used in order to access addresses not (directly)
On 09.02.2021 15:55, Roger Pau Monné wrote:
> On Thu, Jan 14, 2021 at 04:04:11PM +0100, Jan Beulich wrote:
>> The "guest" variants are intended to work with (potentially) fully guest
>> controlled addresses, while the "unsafe" variants are not. (For
>> descriptor table accesses the low bits of the
On 09.02.2021 15:46, Roger Pau Monné wrote:
> On Tue, Feb 09, 2021 at 02:15:18PM +0100, Jan Beulich wrote:
>> On 09.02.2021 14:07, Roger Pau Monné wrote:
>>> On Fri, Feb 05, 2021 at 05:26:33PM +0100, Jan Beulich wrote:
On 05.02.2021 17:18, Roger Pau Monné wrote:
> On Fri, Feb 05, 2021 at
On Thu, Jan 14, 2021 at 04:04:11PM +0100, Jan Beulich wrote:
> The "guest" variants are intended to work with (potentially) fully guest
> controlled addresses, while the "unsafe" variants are not. (For
> descriptor table accesses the low bits of the addresses may still be
> guest controlled, but
On Tue, Feb 09, 2021 at 02:15:18PM +0100, Jan Beulich wrote:
> On 09.02.2021 14:07, Roger Pau Monné wrote:
> > On Fri, Feb 05, 2021 at 05:26:33PM +0100, Jan Beulich wrote:
> >> On 05.02.2021 17:18, Roger Pau Monné wrote:
> >>> On Fri, Feb 05, 2021 at 05:13:22PM +0100, Jan Beulich wrote:
> On
On 09.02.2021 14:56, Norbert Manthey wrote:
> On 2/9/21 2:45 PM, Jan Beulich wrote:
>> On 09.02.2021 14:41, Norbert Manthey wrote:
>>> On 2/9/21 10:40 AM, Jan Beulich wrote:
On 08.02.2021 20:47, Norbert Manthey wrote:
> On 2/8/21 3:21 PM, Jan Beulich wrote:
>> On 05.02.2021 21:39,
Jan Beulich writes ("Re: [PATCH v2] xen/arm: fix gnttab_need_iommu_mapping"):
> On 08.02.2021 21:24, Stefano Stabellini wrote:
...
> > For these cases, I would just follow a simple rule of thumb:
> > - is the submitter willing to provide the backport?
> > - is the backport low-risk?
> > - is the
On 2/9/21 2:45 PM, Jan Beulich wrote:
> On 09.02.2021 14:41, Norbert Manthey wrote:
>> On 2/9/21 10:40 AM, Jan Beulich wrote:
>>> On 08.02.2021 20:47, Norbert Manthey wrote:
On 2/8/21 3:21 PM, Jan Beulich wrote:
> On 05.02.2021 21:39, Norbert Manthey wrote:
>> @@ -4108,6 +4108,13 @@
On Sat, Feb 06, 2021 at 11:49:29AM +0100, Juergen Gross wrote:
> In order to support the possibility of per-device event channel
> settings (e.g. lateeoi spurious event thresholds) add a xenbus device
> pointer to struct irq_info() and modify the related event channel
> binding interfaces to take
On 09.02.2021 14:41, Norbert Manthey wrote:
> On 2/9/21 10:40 AM, Jan Beulich wrote:
>> On 08.02.2021 20:47, Norbert Manthey wrote:
>>> On 2/8/21 3:21 PM, Jan Beulich wrote:
On 05.02.2021 21:39, Norbert Manthey wrote:
> @@ -4108,6 +4108,13 @@ static int hvm_allow_set_param(struct domain
On 2/9/21 10:40 AM, Jan Beulich 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 08.02.2021 20:47, Norbert Manthey wrote:
>> On 2/8/21 3:21 PM, Jan
On 09.02.2021 14:07, Roger Pau Monné wrote:
> On Fri, Feb 05, 2021 at 05:26:33PM +0100, Jan Beulich wrote:
>> On 05.02.2021 17:18, Roger Pau Monné wrote:
>>> On Fri, Feb 05, 2021 at 05:13:22PM +0100, Jan Beulich wrote:
On 05.02.2021 16:43, Roger Pau Monné wrote:
> On Thu, Jan 14, 2021 at
Hello Stefano,
> On 8 Feb 2021, at 6:49 pm, Stefano Stabellini wrote:
>
> Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
> The offending chunk is:
>
> #define gnttab_need_iommu_mapping(d)\
> -(is_domain_direct_mapped(d) && need_iommu(d))
> +
Hello Julien,
> On 8 Feb 2021, at 6:49 pm, Julien Grall wrote:
>
>
>
> On 08/02/2021 18:19, Rahul Singh wrote:
>> Hello Julien,
>
> Hi Rahul,
>
>>> On 8 Feb 2021, at 6:11 pm, Julien Grall wrote:
>>>
>>>
>>>
>>> On 08/02/2021 18:06, Rahul Singh wrote:
> On 6 Feb 2021, at 12:38 am,
On Fri, Feb 05, 2021 at 05:26:33PM +0100, Jan Beulich wrote:
> On 05.02.2021 17:18, Roger Pau Monné wrote:
> > On Fri, Feb 05, 2021 at 05:13:22PM +0100, Jan Beulich wrote:
> >> On 05.02.2021 16:43, Roger Pau Monné wrote:
> >>> On Thu, Jan 14, 2021 at 04:04:11PM +0100, Jan Beulich wrote:
> The
On 09.02.2021 13:53, Jan Beulich wrote:
> The middle two patches are meant to address a regression reported on
> the list under "Problems with APIC on versions 4.9 and later (4.8
> works)". In the course of analyzing output from a debugging patch I
> ran into another anomaly again, which I thought
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 this field on an earlier iteration.
flight 159129 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159129/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl 14 guest-start fail REGR. vs. 158387
While doing this for small amounts may be okay, the unconditional use
of CPU0's value here has been found to be a problem when the boot time
TSC of the BSP was behind that of all APs by more than a second. In
particular because of get_s_time_fixed() producing insane output when
the calculated
The (stime,tsc) tuple is the basis for extrapolation by get_s_time().
Therefore the two better get taken as close to one another as possible.
This means two things: First, reading platform time is too early when
done on the first iteration. The closest we can get is on the last
iteration,
Setting the timer a second (EPOCH) into the future at a random point
during boot (prior to bringing up APs and prior to launching Dom0) does
not yield predictable results: The timer may expire while we're still
bringing up APs (too early) or when Dom0 already boots (too late).
Instead invoke the
The middle two patches are meant to address a regression reported on
the list under "Problems with APIC on versions 4.9 and later (4.8
works)". In the course of analyzing output from a debugging patch I
ran into another anomaly again, which I thought I should finally try
to address. Hence patch 1.
Am Mon, 8 Feb 2021 16:39:01 +
schrieb Andrew Cooper :
> It is possibly worth noting that you typically do see changed data when
> using --debug, because of how the front/back pairs work. This was a bit
> of a curveball during development.
I just noticed "migrate --debug" is a noop, "verify"
The function drm_gem_fb_prepare_fb() is a helper for atomic modesetting,
but currently located next to framebuffer helpers. Move it to GEM atomic
helpers, rename it slightly and adopt the drivers. Same for the rsp
simple-pipe helper.
Compile-tested with x86-64, aarch64 and arm. The patch is
Hi Stefano,
> On 8 Feb 2021, at 23:56, Stefano Stabellini wrote:
>
> PCI buses differ from default buses in a few important ways, so it is
> important to detect them properly. Normally, PCI buses are expected to
> have the following property:
>
>device_type = "pci"
>
> In reality, it is
On 08.02.2021 21:00, Norbert Manthey wrote:
> To prevent leaking HVM params via L1TF and similar issues on a
> hyperthread pair, let's load values of domains after performing all
> relevant checks, and blocking speculative execution.
I'd like to suggest "..., let's load values of domains only
On 08.02.2021 21:24, Stefano Stabellini wrote:
> On Mon, 8 Feb 2021, Julien Grall wrote:
>> On 08/02/2021 18:49, Stefano Stabellini wrote:
>>> Given the severity of the bug, I would like to request this patch to be
>>> backported to 4.12 too, even if 4.12 is security-fixes only since Oct
>>> 2020.
On 08.02.2021 20:47, Norbert Manthey wrote:
> On 2/8/21 3:21 PM, Jan Beulich wrote:
>> On 05.02.2021 21:39, Norbert Manthey wrote:
>>> @@ -4108,6 +4108,13 @@ static int hvm_allow_set_param(struct domain *d,
>>> if ( rc )
>>> return rc;
>>>
>>> +if ( index >= HVM_NR_PARAMS )
>>> +
Hi Stefano,
On 09/02/2021 01:57, Stefano Stabellini wrote:
On Mon, 8 Feb 2021, Julien Grall wrote:
On Mon, 8 Feb 2021 at 20:24, Stefano Stabellini wrote:
@Ian, I think this wants to go in 4.15. Without it, Xen may receive an IOMMU
fault for DMA transaction using granted page.
Backport:
On Tue, Feb 09, 2021 at 02:21:18PM +0800, Claire Chang wrote:
> This can be dropped if Christoph's swiotlb cleanups are landed.
> https://lore.kernel.org/linux-iommu/20210207160934.2955931-1-...@lst.de/T/#m7124f29b6076d462101fcff6433295157621da09
>
FYI, I've also started looking into additional
98 matches
Mail list logo
