On 20.12.2021 12:29, Anthony PERARD wrote:
> On Thu, Dec 16, 2021 at 11:08:47AM +, Anthony PERARD wrote:
>> On Tue, Dec 07, 2021 at 12:10:34PM +0100, Jan Beulich wrote:
>>> On 25.11.2021 14:39, Anthony PERARD wrote:
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -22,6 +22,15 @@ export
On 17.12.2021 16:02, Andrew Cooper wrote:
> On 03/12/2021 12:06, Jan Beulich wrote:
>> This has gone out of sync over time, resulting in NPF and XSETBV exits
>> incrementing the same counter. Introduce a simplistic mechanism to
>> hopefully keep things in better sync going forward.
>>
>>
On 20.12.21 18:14, Julien Grall wrote:
Hi,
On 18/12/2021 00:00, Stefano Stabellini wrote:
On Fri, 17 Dec 2021, Juergen Gross wrote:
On 17.12.21 11:41, Julien Grall wrote:
Hi Juergen,
On 17/12/2021 08:50, Juergen Gross wrote:
On 17.12.21 08:45, Jan Beulich wrote:
On 17.12.2021 06:34,
On 17.12.2021 15:32, Julien Grall wrote:
> On 16/12/2021 13:37, Jan Beulich wrote:
>> On 16.12.2021 12:01, Roger Pau Monné wrote:
>>> On Thu, Dec 16, 2021 at 10:18:32AM +, Rahul Singh wrote:
> On 14 Dec 2021, at 12:37 pm, Roger Pau Monné wrote:
> On Tue, Dec 14, 2021 at 10:45:17AM
flight 167496 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167496/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 167489
test-armhf-armhf-libvirt 16
On 21.12.21 00:22, Samuel Thibault wrote:
Juergen Gross, le lun. 20 déc. 2021 17:07:10 +0100, a ecrit:
+unsigned long e820_get_max_contig_pages(unsigned long pfn, unsigned long pages)
+{
+int i;
+unsigned long end;
+
+for ( i = 0; i < e820_entries && e820_map[i].addr < (pfn <<
On 21.12.21 00:17, Samuel Thibault wrote:
Juergen Gross, le lun. 20 déc. 2021 17:07:08 +0100, a ecrit:
+static void e820_sanitize(void)
+{
+int i;
+unsigned long end, start;
+
+/* Sanitize memory map in current form. */
+e820_process_entries();
+
+/* Adjust map entries to
flight 167495 linux-linus real [real]
flight 167498 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167495/
http://logs.test-lab.xenproject.org/osstest/logs/167498/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On Tue, 14 Dec 2021, Oleksii Moisieiev wrote:
> Integration of the SCMI mediator with xen libs:
> - add hypercalls to aquire SCI channel and set device permissions
> for DomUs;
> - add SCMI_SMC nodes to DomUs device-tree based on partial device-tree;
> - SCI requests redirection from DomUs to
On Tue, 14 Dec 2021, Oleksii Moisieiev wrote:
> This enumeration sets SCI type for the domain. Currently there is
> two possible options: either 'none' or 'scmi_smc'.
>
> 'none' is the default value and it disables SCI support at all.
>
> 'scmi_smc' enables access to the Firmware from the
On Mon, 20 Dec 2021, Oleksii Moisieiev wrote:
> Hi Stefano,
>
> On Fri, Dec 17, 2021 at 06:14:55PM -0800, Stefano Stabellini wrote:
> > On Tue, 14 Dec 2021, Oleksii Moisieiev wrote:
> > > This is the implementation of SCI interface, called SCMI-SMC driver,
> > > which works as the mediator
On Mon, 20 Dec 2021, Julien Grall wrote:
> On 18/12/2021 00:00, Stefano Stabellini wrote:
> > On Fri, 17 Dec 2021, Juergen Gross wrote:
> > > On 17.12.21 11:41, Julien Grall wrote:
> > > > Hi Juergen,
> > > >
> > > > On 17/12/2021 08:50, Juergen Gross wrote:
> > > > > On 17.12.21 08:45, Jan
Juergen Gross, le lun. 20 déc. 2021 17:07:12 +0100, a ecrit:
> Add two functions for adding reserved areas to the memory map and
> for removing them again.
>
> Those will be needed for proper grant table/mapping support in PVH
> mode.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Samuel
Juergen Gross, le lun. 20 déc. 2021 17:07:10 +0100, a ecrit:
> +unsigned long e820_get_max_contig_pages(unsigned long pfn, unsigned long
> pages)
> +{
> +int i;
> +unsigned long end;
> +
> +for ( i = 0; i < e820_entries && e820_map[i].addr < (pfn << PAGE_SHIFT);
Shouldn't that be
Juergen Gross, le lun. 20 déc. 2021 17:07:09 +0100, a ecrit:
> Sizing the available memory should respect memory holes, so look at
> the memory map when setting the boundary for the memory allocator.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
> ---
> V2:
> - rename "max" to
Juergen Gross, le lun. 20 déc. 2021 17:07:08 +0100, a ecrit:
> +static void e820_sanitize(void)
> +{
> +int i;
> +unsigned long end, start;
> +
> +/* Sanitize memory map in current form. */
> +e820_process_entries();
> +
> +/* Adjust map entries to page boundaries. */
> +
From: Oleksandr Tyshchenko
All IOMMU drivers on Arm perform almost the same generic actions in
hwdom_init callback. Move this code to common arch_iommu_hwdom_init()
in order to get rid of code duplication.
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Volodymyr Babchuk
Reviewed-by:
From: Oleksandr Tyshchenko
Reference-count the micro-TLBs as several bus masters can be
connected to the same micro-TLB (and drop TODO comment).
This wasn't an issue so far, since the platform devices
(this driver deals with) get assigned/deassigned together during
domain creation/destruction.
From: Oleksandr Tyshchenko
Based on the following Linux upsteam commit:
7a62ced8ebd0e1b692c9dc4781a8d4ddb0f74792
Original commit message:
commit 7a62ced8ebd0e1b692c9dc4781a8d4ddb0f74792
Author: Yoshihiro Shimoda
Date: Tue Sep 7 17:30:20 2021 +0900
iommu/ipmmu-vmsa: Add support for
From: Oleksandr Tyshchenko
Based on the following commits from the Renesas BSP:
8fba83d97cca709a05139c38e29408e81ed4cf62
a8d93bc07da89a7fcf4d85f34d119a030310efa5
located at:
https://github.com/renesas-rcar/linux-bsp/tree/v5.10.41/rcar-5.1.3.rc5
Original commit messages:
commit
From: Oleksandr Tyshchenko
This is a non-verbatim port of corresponding Linux upsteam commit:
1289f7f15001c7ed36be6d23cb145c1d5feacdc8
Original commit message:
commit 1289f7f15001c7ed36be6d23cb145c1d5feacdc8
Author: Yoshihiro Shimoda
Date: Wed Nov 6 11:35:50 2019 +0900
From: Oleksandr Tyshchenko
Hello all.
You can find the V1 patch series at [1].
The R-Car S4 is an automotive System-on-Chip (SoC) for Car Server/Communication
Gateway and is one of the first products in Renesas’ 4th-generation R-Car
Family.
The integrated IOMMU HW is also VMSA-compatible and
From: Oleksandr Tyshchenko
This is a non-verbatim port of corresponding Linux upsteam commit:
77cf983892b2e0d40dc256b784930a9ffaad4fc8
Original commit message:
commit 77cf983892b2e0d40dc256b784930a9ffaad4fc8
Author: Yoshihiro Shimoda
Date: Wed Nov 6 11:35:45 2019 +0900
From: Oleksandr Tyshchenko
This is a non-verbatim port of corresponding Linux upsteam commit:
16d9454f5e0447f9c19cbf350b35ed377b9f64eb
Original commit message:
commit 16d9454f5e0447f9c19cbf350b35ed377b9f64eb
Author: Yoshihiro Shimoda
Date: Wed Nov 6 11:35:47 2019 +0900
From: Oleksandr Tyshchenko
This is a prereq work needed to add support for S4 series easily
in the future.
We don't need to pull the whole struct and all instances as Xen
driver doesn't support old Arm32 based Gen2 SoCs, so there is no
point in keeping all differences between Gen2 and Gen3
From: Oleksandr Tyshchenko
This is a non-verbatim port of corresponding Linux upsteam commit:
3dc28d9f59eaae41461542b27afe70339347ebb3
Original commit message:
commit 3dc28d9f59eaae41461542b27afe70339347ebb3
Author: Yoshihiro Shimoda
Date: Wed Nov 6 11:35:48 2019 +0900
From: Oleksandr Tyshchenko
This is a non-verbatim port of corresponding Linux upsteam commit:
3667c9978b2911dc1ded77f5971df477885409c4
Original commit message:
commit 3667c9978b2911dc1ded77f5971df477885409c4
Author: Yoshihiro Shimoda
Date: Wed Nov 6 11:35:49 2019 +0900
flight 167492 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167492/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail REGR.
vs. 167484
Tests
Hi Stefano,
On Fri, Dec 17, 2021 at 06:14:55PM -0800, Stefano Stabellini wrote:
> On Tue, 14 Dec 2021, Oleksii Moisieiev wrote:
> > This is the implementation of SCI interface, called SCMI-SMC driver,
> > which works as the mediator between XEN Domains and Firmware (SCP, ATF etc).
> > This allows
flight 167489 qemu-mainline real [real]
flight 167493 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167489/
http://logs.test-lab.xenproject.org/osstest/logs/167493/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi,
On 18/12/2021 00:00, Stefano Stabellini wrote:
On Fri, 17 Dec 2021, Juergen Gross wrote:
On 17.12.21 11:41, Julien Grall wrote:
Hi Juergen,
On 17/12/2021 08:50, Juergen Gross wrote:
On 17.12.21 08:45, Jan Beulich wrote:
On 17.12.2021 06:34, Juergen Gross wrote:
On 16.12.21 22:15,
First of all, thank you for your quick response, Juergen and Roger.
I just realized that I run into mail forwarding issue from sourceforge
mail alias service, and only found the responses when I checked the
list archive. As a result, I have to manually merge Roger's response
to reply...
> > I
For being able to use the grant mapping interface in PVH mode some
changes are required, as the guest needs to specify a physical address
in the hypercall interface.
Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
---
gntmap.c | 81
Grant table initialization for PVH requires some additional actions
compared to PV mode. Add those.
Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
---
arch/x86/gnttab.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/x86/gnttab.c
Instead of passing the pointer of a grantmap entry to the
_gntmap_[un]map_grant_ref() sub-functions use the map pointer and the
entry index instead. This will be needed for PVH mode usage.
Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
---
gntmap.c | 48
Introduce e820.c containing all the E820 memory map handling.
No functional change.
Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
---
Makefile | 1 +
arch/arm/mm.c | 8
arch/x86/mm.c | 70 +
e820.c | 119
Having grant table code in arch/x86/mm.c seems wrong. Move it to the
new file arch/x86/gnttab.c, especially as the amount of code is
expected to grow further.
While doing that replace type casts to pte_t with the more appropriate
__pte() macro.
No functional change.
Signed-off-by: Juergen
Today Mini-OS won't look at the memory map when ballooning up. This can
result in problems for PVH domains with more than 4 GB of RAM, as
ballooning will happily run into the ACPI area.
Fix that by adding only pages being marked as RAM in the memory map and
by distinguishing between the current
Do some processing of the E820 memory map obtained from the hypervisor:
- align the entries to page boundaries
- sort the entries by their start address
- merge adjacent entries of same type
This is relevant for PVH mode only.
Signed-off-by: Juergen Gross
---
V2:
- correct page boundary
arch/x86/setup.c is repeating the definition of __pte() instead using
the appropriate header. Fix that.
Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
---
arch/x86/setup.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/x86/setup.c b/arch/x86/setup.c
Sizing the available memory should respect memory holes, so look at
the memory map when setting the boundary for the memory allocator.
Signed-off-by: Juergen Gross
---
V2:
- rename "max" to "start" (Samuel Thibault)
---
arch/x86/mm.c | 6 +-
e820.c | 14 --
Add two functions for adding reserved areas to the memory map and
for removing them again.
Those will be needed for proper grant table/mapping support in PVH
mode.
Signed-off-by: Juergen Gross
---
V2:
- fix e820_put_reserved_pfns() (Samuel Thibault)
---
e820.c | 50
Mini-OS in PVH mode is missing some features, especially in the areas
of ballooning and grant tables.
With this series I am able to run Xenstore stubdom in PVH mode.
Changes in V2:
- multiple comments addressed
Juergen Gross (10):
mini-os: split e820 map handling into new source file
Hi Julien,
On Fri, Dec 17, 2021 at 04:38:31PM +, Julien Grall wrote:
>
>
> On 17/12/2021 13:58, Oleksii Moisieiev wrote:
> > Hi Julien,
>
> Hi,
>
> > On Fri, Dec 17, 2021 at 01:37:35PM +, Julien Grall wrote:
> > > Hi,
> > >
> > > On 17/12/2021 13:23, Oleksii Moisieiev wrote:
> > > >
On Thu, Dec 16, 2021 at 04:47:30PM +0100, Jan Beulich wrote:
> On 15.12.2021 14:57, Roger Pau Monné wrote:
> > On Fri, Sep 24, 2021 at 11:55:30AM +0200, Jan Beulich wrote:
> >> --- /dev/null
> >> +++ b/xen/include/asm-x86/contig-marker.h
> >> @@ -0,0 +1,105 @@
> >> +#ifndef
flight 167486 linux-linus real [real]
flight 167490 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167486/
http://logs.test-lab.xenproject.org/osstest/logs/167490/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Sun, Dec 19, 2021 at 02:35:56AM +0800, G.R. wrote:
> Hi all,
>
> I ran into the following error report in the DOM0 kernel after a recent
> upgrade:
> [ 501.840816] vif vif-1-0 vif1.0: Cross page boundary, txp->offset:
> 2872, size: 1460
> [ 501.840828] vif vif-1-0 vif1.0: fatal error;
From: Christopher Clark
This is a split out of the hyperlaunch dom0 series.
There were several instances of open-coded domid range checking. This commit
replaces those with the is_system_domain or is_system_domid inline function.
Signed-off-by: Christopher Clark
Signed-off-by: Daniel P. Smith
Change the support state of Linux and Windows pv frontends from
"supported" to "supported with caveats" in order to reflect that the
frontends can probably be harmed by their respective backends.
Some of the Linux frontends have been hardened already.
This is XSA-376
Signed-off-by: Juergen
Please disregard, I inadvertant picked up a couple of build artifacts.
My sincere apologies on that, I will be resending shortly without them.
v/r
dps
On 12/20/21 10:50 AM, Daniel P. Smith wrote:
From: Christopher Clark
This is a split out of the hyperlaunch dom0 series.
There were several
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-376
frontends vulnerable to backends
ISSUE DESCRIPTION
=
Xen offers the ability to run PV backends in regular unprivileged
guests, typically referred to as "driver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2021-28714,CVE-2021-28715 / XSA-392
version 4
Guest can force Linux netback driver to hog large amounts of kernel memory
UPDATES IN VERSION 4
Public release
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2021-28711,CVE-2021-28712,CVE-2021-28713 / XSA-391
version 3
Rogue backends can cause DoS of guests via high frequency events
UPDATES IN VERSION 3
Public
On Sat, Dec 18 2021 at 21:25, Cédric Le Goater wrote:
> On 12/18/21 11:25, Thomas Gleixner wrote:
>> On Fri, Dec 17 2021 at 15:30, Nathan Chancellor wrote:
>>> On Fri, Dec 10, 2021 at 11:19:26PM +0100, Thomas Gleixner wrote:
>>> I just bisected a boot failure on my AMD test desktop to this patch
From: Christopher Clark
This is a split out of the hyperlaunch dom0 series.
There were several instances of open-coded domid range checking. This commit
replaces those with the is_system_domain or is_system_domid inline function.
Signed-off-by: Christopher Clark
Signed-off-by: Daniel P. Smith
On Thu, Dec 16, 2021 at 11:08:47AM +, Anthony PERARD wrote:
> On Tue, Dec 07, 2021 at 12:10:34PM +0100, Jan Beulich wrote:
> > On 25.11.2021 14:39, Anthony PERARD wrote:
> > > --- a/xen/Makefile
> > > +++ b/xen/Makefile
> > > @@ -22,6 +22,15 @@ export CHECKPOLICY ?= checkpolicy
> > >
On 12/17/21 2:50 PM, Andrew Cooper wrote:
On 17/12/2021 23:34, Daniel P. Smith wrote:
From: Christopher Clark
There were several instances of open-coded domid range checking. This commit
replaces those with the is_system_domain inline function.
Signed-off-by: Christopher Clark
flight 167485 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167485/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass
in 167480
flight 167487 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167487/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf de9e5b7dc721d4ca319c0455cf83577347e0abef
baseline version:
ovmf
flight 167488 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167488/
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
60 matches
Mail list logo
