flight 181127 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181127/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c1dd400a13d1a5e862809c55f6760ba3a944a609
baseline version:
ovmf 8fbf857a0b42697c22ec0
flight 181115 linux-linus real [real]
flight 181129 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181115/
http://logs.test-lab.xenproject.org/osstest/logs/181129/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
flight 181119 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181119/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 10 xen-install/src_host fail REGR. vs. 180691
test-amd64-amd64-
flight 181122 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181122/
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 1
flight 181109 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181109/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 181095
test-amd64-i386-xl-qemuu-win7-amd64
On 01/06/2023 11:54 am, Andrew Cooper wrote:
> Instead, I recommend the following:
>
> 1) One patch moving the early-cpuid/msr read from tsx_init() into
> early_microcode_init(), adjusting the comment as it goes. No point
> duplicating that logic, and we need it earlier on boot now.
> 2) This patc
On Wed, May 31, 2023 at 04:49:21PM -0700, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> Add a PVH Dom0 test for the zen3 runner.
>
> Signed-off-by: Stefano Stabellini
Acked-by: Marek Marczykowski-Górecki
> ---
> automation/gitlab-ci/test.yaml | 8
> 1 file changed, 8 ins
flight 181117 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181117/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8fbf857a0b42697c22ec03abda9a2101b2870812
baseline version:
ovmf 4354c22f38778a2bb4644
On Wed, 2023-05-31 at 12:45 +0100, Andrew Cooper wrote:
> On 25/05/2023 4:28 pm, Oleksii Kurochko wrote:
> > Oleksii Kurochko (5):
> > xen/riscv: add VM space layout
> > xen/riscv: introduce setup_initial_pages
> > xen/riscv: align __bss_start
> > xen/riscv: setup initial pagetables
> > x
On Tue, 2 May 2023 at 18:08, Peter Maydell wrote:
>
> On Tue, 7 Mar 2023 at 18:27, David Woodhouse wrote:
> >
> > From: David Woodhouse
> >
> > Firing watches on the nodes that still exist is relatively easy; just
> > walk the tree and look at the nodes with refcount of one.
> >
> > Firing watch
On 02/06/2023 2:19 pm, Alejandro Vallejo wrote:
> On Thu, Jun 01, 2023 at 11:54:31AM +0100, Andrew Cooper wrote:
>> I had something else in mind here. Right now, this will read
>> MSR_MCU_CONTROL and emit a printk() on every microcode load, which will
>> be every AP, and every time the user uses t
flight 181103 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181103/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 10 xen-install/src_host fail REGR. vs. 180691
test-amd64-amd64-
On 02/06/2023 5:08 pm, Alejandro Vallejo wrote:
> On Fri, Jun 02, 2023 at 03:22:20PM +0100, Andrew Cooper wrote:
>> Linux deals with this in verify_cpu() (early asm) along with a FMS check
>> protecting the access to MSR_MISC_ENABLE, rather than using rdmsr_safe()
>> and catching the #GP.
> On a re
On Fri, Jun 02, 2023 at 03:22:20PM +0100, Andrew Cooper wrote:
> On 01/06/2023 6:43 pm, Alejandro Vallejo wrote:
> > diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> > index 09bebf8635..8414266281 100644
> > --- a/xen/arch/x86/boot/head.S
> > +++ b/xen/arch/x86/boot/head.S
> > @@
Hi Roger,
On 02/06/2023 16:24, Roger Pau Monné wrote:
On Fri, Jun 02, 2023 at 02:46:03PM +0100, Ayan Kumar Halder wrote:
Hi Roger,
On 02/06/2023 12:43, Roger Pau Monné wrote:
On Fri, Jun 02, 2023 at 09:48:48AM +0100, Ayan Kumar Halder wrote:
Hi Xen developers,
We are trying to better docume
On 02/06/2023 4:29 pm, Andrew Cooper wrote:
> On 02/06/2023 11:20 am, Jan Beulich wrote:
>> On 01.06.2023 16:48, Andrew Cooper wrote:
>> What about a tool stack request leading to us setting the 2nd of the two
>> bits here, while the other was already set? IOW wouldn't we better clear
>> the other
On 02/06/2023 11:20 am, Jan Beulich wrote:
> On 01.06.2023 16:48, Andrew Cooper wrote:
>> The RSBA bit, "RSB Alternative", means that the RSB may use alternative
>> predictors when empty. From a practical point of view, this mean "Retpoline
>> not safe".
>>
>> Enhanced IBRS (officially IBRS_ALL in
On Fri, Jun 02, 2023 at 02:46:03PM +0100, Ayan Kumar Halder wrote:
> Hi Roger,
>
> On 02/06/2023 12:43, Roger Pau Monné wrote:
> > On Fri, Jun 02, 2023 at 09:48:48AM +0100, Ayan Kumar Halder wrote:
> > > Hi Xen developers,
> > >
> > > We are trying to better document xen project development proce
On 31/05/2023 22:24, Sean Christopherson wrote:
On Tue, May 30, 2023, Rick P Edgecombe wrote:
On Fri, 2023-05-26 at 17:22 +0200, Micka�l Sala�n wrote:
Can the guest kernel ask the host VMM's emulated devices to DMA into
the protected data? It should go through the host userspace mappings
flight 181100 linux-linus real [real]
flight 181113 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181100/
http://logs.test-lab.xenproject.org/osstest/logs/181113/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
flight 18 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/18/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4354c22f38778a2bb4644d1f1f43a47e4313fe42
baseline version:
ovmf 78262899d225eb30e5fbe
On 01/06/2023 6:43 pm, Alejandro Vallejo wrote:
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index 09bebf8635..8414266281 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -647,11 +653,18 @@ trampoline_setup:
> cpuid
> 1: mov %e
flight 181102 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181102/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 181066
test-armhf-armhf-libvirt 16 saveresto
On 02/06/2023 10:56 am, Jan Beulich wrote:
> On 01.06.2023 16:48, Andrew Cooper wrote:
>> @@ -593,15 +596,85 @@ static bool __init retpoline_calculations(void)
>> return false;
>>
>> /*
>> - * RSBA may be set by a hypervisor to indicate that we may move to a
>> - * processor
Hi Roger,
On 02/06/2023 12:43, Roger Pau Monné wrote:
On Fri, Jun 02, 2023 at 09:48:48AM +0100, Ayan Kumar Halder wrote:
Hi Xen developers,
We are trying to better document xen project development processes and
related tools. At present, we are targeting **x86 and Arm** only.
These tools rang
On Thu, Jun 01, 2023 at 11:54:31AM +0100, Andrew Cooper wrote:
> I had something else in mind here. Right now, this will read
> MSR_MCU_CONTROL and emit a printk() on every microcode load, which will
> be every AP, and every time the user uses the xen-ucode tool.
Not every AP. The hypercall would
On 02.06.2023 14:05, Andrew Cooper wrote:
> On 01/06/2023 6:43 pm, Alejandro Vallejo wrote:
>> @@ -151,6 +152,11 @@ not_multiboot:
>> .Lnot_aligned:
>> add $sym_offs(.Lbag_alg_msg),%esi # Error message
>> jmp .Lget_vtb
>> +#if IS_ENABLED(CONFIG_REQUIRE_NX_BIT)
>
> This
Refer ARM DDI 0406C.d ID040418, B3-1345,
"A stage 2 translation with an input address range of 31-34 bits can
start the translation either:
- With a first-level lookup, accessing a first-level translation
table with 2-16 entries.
- With a second-level lookup, accessing a set of concatenated
When 32 bit physical addresses are used (ie PHYS_ADDR_T_32=y),
"va >> ZEROETH_SHIFT" causes an overflow.
Also, there is no zeroeth level page table on Arm32.
Also took the opportunity to clean up dump_pt_walk(). One could use
DECLARE_OFFSETS() macro instead of declaring an array of page table
offs
As the previous patch introduces CONFIG_PHYS_ADDR_T_32 to support 32 bit
physical addresses, the code specific to "Large Physical Address Extension"
(ie LPAE) should be enclosed within "ifndef CONFIG_PHYS_ADDR_T_32".
Refer xen/arch/arm/include/asm/short-desc.h, "short_desc_l1_supersec_t"
unsigned
Some Arm based hardware platforms which does not support LPAE
(eg Cortex-R52), uses 32 bit physical addresses.
Also, users may choose to use 32 bits to represent physical addresses
for optimization.
To support the above use cases, we have introduced arch independent
config to choose if the physica
Restructure the code so that one can use pa_range_info[] table for both
ARM_32 as well as ARM_64.
Also, removed the hardcoding for P2M_ROOT_ORDER and P2M_ROOT_LEVEL as
p2m_root_order can be obtained from the pa_range_info[].root_order and
p2m_root_level can be obtained from pa_range_info[].sl0.
R
Hi All,
Please have a look at
https://lists.xenproject.org/archives/html/xen-devel/2022-11/msg01465.html
for the context.
The benefits of using 32 bit physical addresses are as follows :-
1. It helps to use Xen on platforms (for eg R52) which supports 32-bit
physical addresses and has no suppor
On 01/06/2023 6:43 pm, Alejandro Vallejo wrote:
> This allows replacing many instances of runtime checks with folded
> constants. The patch asserts support for the NX bit in PTEs at boot time
> and if so short-circuits cpu_has_nx to 1. This has several knock-on effects
> that improve codegen:
> *
On Fri, Jun 02, 2023 at 09:48:48AM +0100, Ayan Kumar Halder wrote:
> Hi Xen developers,
>
> We are trying to better document xen project development processes and
> related tools. At present, we are targeting **x86 and Arm** only.
>
> These tools range from bug/change request tracking means, comp
flight 181106 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181106/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 78262899d225eb30e5fbe6a88e85a4b1d8c04a61
baseline version:
ovmf 41abf00bf98e36830974b
Hi,
Sure to everything. A couple of notes:
On Fri, Jun 02, 2023 at 10:31:08AM +0200, Jan Beulich wrote:
> > + def_bool n
> > + prompt "Require NX bit support"
>
> Just
>
> bool "Require NX bit support"
>
> please.
I didn't realize Kconfig defaulted to 'n'. That's neat, thanks.
>
> >
On Fri, Jun 02, 2023 at 09:48:48AM +0100, Ayan Kumar Halder wrote:
> Hi Xen developers,
>
> We are trying to better document xen project development processes and
> related tools. At present, we are targeting **x86 and Arm** only.
>
> These tools range from bug/change request tracking means, comp
On 01.06.2023 16:48, Andrew Cooper wrote:
> The RSBA bit, "RSB Alternative", means that the RSB may use alternative
> predictors when empty. From a practical point of view, this mean "Retpoline
> not safe".
>
> Enhanced IBRS (officially IBRS_ALL in Intel's docs, previously IBRS_ATT) is a
> statem
On 01.06.2023 16:48, Andrew Cooper wrote:
> @@ -593,15 +596,85 @@ static bool __init retpoline_calculations(void)
> return false;
>
> /*
> - * RSBA may be set by a hypervisor to indicate that we may move to a
> - * processor which isn't retpoline-safe.
> + * The meaning
On 02/06/2023 9:31 am, Jan Beulich wrote:
> On 01.06.2023 19:43, Alejandro Vallejo wrote:
>> This allows replacing many instances of runtime checks with folded
>> constants. The patch asserts support for the NX bit in PTEs at boot time
>> and if so short-circuits cpu_has_nx to 1. This has several k
flight 181095 xen-unstable real [real]
flight 181107 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181095/
http://logs.test-lab.xenproject.org/osstest/logs/181107/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On 01.06.2023 16:48, Andrew Cooper wrote:
> This is prep work, split out to simply the diff on the following change.
>
> * Rename to retpoline_calculations(), and call unconditionally. It is
>shortly going to synthesise missing enumerations required for guest safety.
> * For the model check
On Fri, Jun 2, 2023 at 1:49 AM Ayan Kumar Halder wrote:
> Hi Xen developers,
>
> We are trying to better document xen project development processes and
> related tools. At present, we are targeting **x86 and Arm** only.
>
> These tools range from bug/change request tracking means, compilers,
> in
On 02.06.2023 02:48, Vikram Garhwal wrote:
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -1057,6 +1057,25 @@ typedef struct xen_sysctl_cpu_policy
> xen_sysctl_cpu_policy_t;
> DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cpu_policy_t);
> #endif
>
> +#if defined(__arm__) ||
On 02.06.2023 11:19, Jan Beulich wrote:
> On 02.06.2023 02:48, Vikram Garhwal wrote:
>> --- a/xen/drivers/passthrough/device_tree.c
>> +++ b/xen/drivers/passthrough/device_tree.c
>> @@ -18,6 +18,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>
Hi Jan and Vikram,
> -Original Message-
> Subject: Re: [XEN][PATCH v7 05/19] xen/arm: Add CONFIG_OVERLAY_DTB
>
> > diff --git a/CHANGELOG.md b/CHANGELOG.md
> > index 5bfd3aa5c0..a137fce576 100644
> > --- a/CHANGELOG.md
> > +++ b/CHANGELOG.md
> > @@ -20,6 +20,8 @@ The format is based on [K
On 02.06.2023 02:48, Vikram Garhwal wrote:
> --- a/xen/drivers/passthrough/device_tree.c
> +++ b/xen/drivers/passthrough/device_tree.c
> @@ -126,6 +126,47 @@ int iommu_release_dt_devices(struct domain *d)
> return 0;
> }
>
> +int iommu_remove_dt_device(struct dt_device_node *np)
> +{
> +
On 02.06.2023 02:48, Vikram Garhwal wrote:
> @@ -189,6 +194,8 @@ int iommu_add_dt_device(struct dt_device_node *np)
> if ( rc < 0 )
> iommu_fwspec_free(dev);
>
> +fail:
> +spin_unlock(&dtdevs_lock);
Nit: Labels indented by at least on blank please (see ./CODING_STYLE).
Jan
On 02.06.2023 02:48, Vikram Garhwal wrote:
> --- a/xen/drivers/passthrough/device_tree.c
> +++ b/xen/drivers/passthrough/device_tree.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -83,16 +84,14 @@ fail:
> return rc;
> }
>
On 02.06.2023 02:48, Vikram Garhwal wrote:
> --- a/xen/common/libfdt/Makefile
> +++ b/xen/common/libfdt/Makefile
> @@ -1,7 +1,11 @@
> include $(src)/Makefile.libfdt
>
> SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
> +
> +# For CONFIG_OVERLAY_DTB, libfdt functionalities will be needed during
On 02.06.2023 02:48, Vikram Garhwal wrote:
> Introduce a config option where the user can enable support for
> adding/removing
> device tree nodes using a device tree binary overlay.
>
> Update SUPPORT.md and CHANGELOG.md to state the Device Tree Overlays support
> for
> Arm.
>
> Signed-off-by:
Hi Xen developers,
We are trying to better document xen project development processes and
related tools. At present, we are targeting **x86 and Arm** only.
These tools range from bug/change request tracking means, compilers,
infra, editors, code-review tools, etc which is connected in some wa
On 02.06.2023 05:21, osstest service owner wrote:
> flight 181082 linux-linus real [real]
> flight 181098 linux-linus real-retest [real]
> http://logs.test-lab.xenproject.org/osstest/logs/181082/
> http://logs.test-lab.xenproject.org/osstest/logs/181098/
>
> Regressions :-(
>
> Tests which did no
On 01.06.2023 19:43, Alejandro Vallejo wrote:
> This allows replacing many instances of runtime checks with folded
> constants. The patch asserts support for the NX bit in PTEs at boot time
> and if so short-circuits cpu_has_nx to 1. This has several knock-on effects
> that improve codegen:
> * _
On 02/06/2023 02:48, Vikram Garhwal wrote:
> Add remove_device callback for removing the device entry from smmu-master
> using
> following steps:
> 1. Find if SMMU master exists for the device node.
> 2. Check if device is currently in use.
> 3. Remove the SMMU master.
>
> Signed-off-by: Vikra
On 02/06/2023 02:48, Vikram Garhwal wrote:
> Rename iommu_dt_device_is_assigned() to iommu_dt_device_is_assigned_locked().
> Remove static type so this can also be used by SMMU drivers to check if the
> device is being used before removing.
>
> Moving spin_lock to caller was done to prevent the
On 02/06/2023 03:52, Henry Wang wrote:
>
>
> Hi Vikram,
>
>> -Original Message-
>> Subject: [XEN][PATCH v7 08/19] xen/device-tree: Add
>> device_tree_find_node_by_path() to find nodes in device tree
>>
>> Add device_tree_find_node_by_path() to find a matching node with path for
>> a
>>
On 02/06/2023 02:48, Vikram Garhwal wrote:
> Introduce a config option where the user can enable support for
> adding/removing
> device tree nodes using a device tree binary overlay.
>
> Update SUPPORT.md and CHANGELOG.md to state the Device Tree Overlays support
> for
> Arm.
>
> Signed-off-b
On 02/06/2023 02:48, Vikram Garhwal wrote:
> Following changes are done to __unflatten_device_tree():
> 1. __unflatten_device_tree() is renamed to unflatten_device_tree().
> 2. Remove __init and static function type.
>
> Signed-off-by: Vikram Garhwal
> Reviewed-by: Henry Wang
Reviewed-
Title: s/unflatten_device_tree/__unflatten_device_tree/ or you mean to propagate
errors from unflatten_dt_node?
On 02/06/2023 02:48, Vikram Garhwal wrote:
> This will be useful in dynamic node programming when new dt nodes are
> unflattend
> during runtime. Invalid device tree node related errors
On 02/06/2023 02:48, Vikram Garhwal wrote:
> Change __unflatten_device_tree() return type to integer so it can propagate
> memory allocation failure. Add panic() in dt_unflatten_host_device_tree() for
> memory allocation failure during boot.
>
> Fixes: fb97eb614acf ("xen/arm: Create a hierarchic
62 matches
Mail list logo
