On 15.12.2022 20:32, Ayan Kumar Halder wrote:
> As "io_size" and "uart->io_size" are both u64, so there will be no truncation.
> Thus, one can remove the ASSERT() and extra assignment.
>
> In an earlier commit (7c1de0038895),
> "ns16550.io_size" was u32 and "io_size" was u64. Thus, the ASSERT() wa
On 16.12.2022 00:57, Demi Marie Obenour wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -6357,6 +6357,15 @@ unsigned long get_upper_mfn_bound(void)
> return min(max_mfn, 1UL << (paddr_bits - PAGE_SHIFT)) - 1;
> }
>
> +static void __init __maybe_unused build_assertions(void)
On 16.12.2022 03:25, Demi Marie Obenour wrote:
>> --- a/xen/arch/x86/include/asm/processor.h
>> +++ b/xen/arch/x86/include/asm/processor.h
>> @@ -100,6 +100,14 @@
>>
>> #ifndef __ASSEMBLY__
>>
>> +/* Convert from PAT/PCD/PWT embedded in PTE flags to actual cacheability
>> value */
>> +static
flight 175303 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175303/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 175202
test-amd64-amd64-xl-qemuu
On 16.12.2022 00:57, Demi Marie Obenour wrote:
> These are not currently used, so there is no functional change. Future
> patches will use these constants.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Demi Marie Obenour
Acked-by: Jan Beulich
on the assumption that Andrew accepted your jus
On 15-12-22, 17:33, Anthony PERARD wrote:
> For those virtio one in particular, it's probably ok. libxl doesn't
> mind, and hopefully the consumer of those don't mind either.
FWIW, the consumer in this case, Rust based xen-vhost-frontent [1]
implementation, did break and I still need to fix it to
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm
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 g
flight 175283 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175283/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 171197
test-amd64-amd64-xl-qemuu-
On 15/12/2022 11:57 pm, Demi Marie Obenour wrote:
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index
> 78b1972e4170ca9c37c6e64e76e66a7da87f..802073a01c5cf4dc3cf1d58d28ea4d4e9e8149c7
> 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -959,15 +959,22 @@ get_page_from_l1
On Thu, Dec 15, 2022 at 06:57:44PM -0500, Demi Marie Obenour wrote:
> get_page_from_l1e() relied on Xen's choice of PAT, which is brittle in
> the face of future PAT changes. Instead, compute the actual cacheability
> used by the CPU and switch on that, as this will work no matter what PAT
> Xen u
On Thu, 15 Dec 2022, Julien Grall wrote:
> > > On 13/12/2022 19:48, Smith, Jackson wrote:
> > > > Hi Xen Developers,
> > >
> > > Hi Jackson,
> > >
> > > Thanks for sharing the prototype with the community. Some
> > > questions/remarks below.
> > >
> > > > My team at Riverside Research is current
flight 175273 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175273/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 175202
test-amd64-amd64-xl-qemuu
flight 175270 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175270/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu 8 xen-bootfail REGR. vs. 173462
test-amd64-amd64-xl
Setting cacheability flags that are not ones specified by Xen is a bug
in the guest. By default, inject #GP into any guest that does this.
allow_invalid_cacheability can be used on the Xen command line to
disable this check.
Suggested-by: Andrew Cooper
Signed-off-by: Demi Marie Obenour
---
Chan
It may be desirable to change Xen's PAT for various reasons. This
requires changes to several _PAGE_* macros as well. Add static
assertions to check that XEN_MSR_PAT is consistent with the _PAGE_*
macros, and that _PAGE_WB is 0 as required by Linux.
Signed-off-by: Demi Marie Obenour
---
Changes
This is purely for testing, to see if it works around a bug in i915. It
is not intended to be merged.
NOT-signed-off-by: DO NOT MERGE
---
xen/arch/x86/include/asm/page.h | 4 ++--
xen/arch/x86/include/asm/processor.h | 10 +-
xen/arch/x86/mm.c| 5 -
3 files
This avoids it being a magic constant that is difficult for humans to
decode. Use BUILD_BUG_ON to check that the old and new values are
identical.
Signed-off-by: Demi Marie Obenour
---
xen/arch/x86/include/asm/processor.h | 9 -
xen/arch/x86/mm.c| 9 +
2 file
No functional change intended.
Signed-off-by: Demi Marie Obenour
---
Changes since v2:
- Keep MTRR_NUM_TYPES and adjust commit message accordingly
---
xen/arch/x86/hvm/mtrr.c | 18 +-
xen/arch/x86/include/asm/mtrr.h | 2 --
xen/arch/x86/mm/shadow/multi.c | 2 +-
3 fil
While working on Qubes OS Marek found out that there were some PAT hacks
in the Linux i195 driver. I decided to make Xen use Linux’s PAT to see
if it solved the graphics glitches that were observed; it did. This
required a substantial amount of preliminary work that is useful even
without using L
These are not currently used, so there is no functional change. Future
patches will use these constants.
Suggested-by: Andrew Cooper
Signed-off-by: Demi Marie Obenour
---
Changes since v3:
- Name the reserved values X86_MT_RSVD_2 and X86_MT_RSVD_3, to
match the architectural values of 0x02 an
This allows eliminating the former. No functional change intended.
Suggested-by: Andrew Cooper
Signed-off-by: Demi Marie Obenour
---
xen/arch/x86/include/asm/hvm/vmx/vmx.h | 9 -
xen/arch/x86/mm/hap/nested_ept.c | 4 ++--
2 files changed, 2 insertions(+), 11 deletions(-)
diff --
This allows eliminating of the former, with the exception of
MTRR_NUM_TYPES. MTRR_NUM_TYPES is kept, as due to a quirk of the x86
architecture X86_MT_UCM (7) is not valid in an MTRR.
Suggested-by: Andrew Cooper
Signed-off-by: Demi Marie Obenour
Reviewed-by: Jan Beulich
---
Changes since v2:
-
This allows eliminating the former.
Suggested-by: Andrew Cooper
Signed-off-by: Demi Marie Obenour
Reviewed-by: Jan Beulich
---
Changes since v2: Style adjustments
---
xen/arch/x86/hvm/hvm.c | 12
xen/arch/x86/hvm/mtrr.c | 52 -
xen/arch
get_page_from_l1e() relied on Xen's choice of PAT, which is brittle in
the face of future PAT changes. Instead, compute the actual cacheability
used by the CPU and switch on that, as this will work no matter what PAT
Xen uses.
No functional change intended.
Signed-off-by: Demi Marie Obenour
---
flight 175292 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175292/
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
Hi,
On 15/12/2022 19:32, Ayan Kumar Halder wrote:
zeroeth_table_offset is not accessed for ARM_32.
Right, but what is the problem with keep it? With your proposal we need
to duplicate the macro DECLARE_OFFSETS() which is not great.
So you want to provide a more compelling reason to have the
On 15/12/2022 19:27, Smith, Jackson wrote:
Hi Julien,
Hi Jackson,
-Original Message-
From: Julien Grall
Sent: Tuesday, December 13, 2022 3:55 PM
To: Smith, Jackson
On 13/12/2022 19:48, Smith, Jackson wrote:
Hi Xen Developers,
Hi Jackson,
Thanks for sharing the prototype wit
flight 175267 qemu-mainline real [real]
flight 175294 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/175267/
http://logs.test-lab.xenproject.org/osstest/logs/175294/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
On Wed, 14 Dec 2022, Michal Orzel wrote:
> At the moment, for dom0less domUs, we do not have a way to specify
> per domain grant table related limits (unlike when using xl), namely
> max version, max number of grant frames, max number of maptrack frames.
> This means that such domains always use th
When building with clang 12 and CONFIG_ARM_SMMU_V3=y, we observe the
following build error:
drivers/passthrough/arm/smmu-v3.c:1408:20: error: unused function
'arm_smmu_disable_pasid' [-Werror,-Wunused-function]
static inline void arm_smmu_disable_pasid(struct arm_smmu_master *master) { }
On Thu, 15 Dec 2022, Michal Orzel wrote:
> Add test jobs in both debug and non-debug versions to run hyp-xen-version
> XTF test as a dom0less domU on arm64. The purpose of this test is to
> validate the functional behavior of xen_version hypercall.
>
> Signed-off-by: Michal Orzel
> ---
> automat
On Thu, 15 Dec 2022, Michal Orzel wrote:
> Introduce support for using XTF on Arm to perform low-level testing.
> For the purpose of the CI testing, let's use the fork [1] from upstream
> XTF with implemented support for arm64 (the upstream XTF only supports
> x86).
>
> Add a new script under auto
flight 175266 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175266/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-livepatch 8 xen-boot fail REGR. vs. 175144
test-amd64-amd64-x
flight 175288 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175288/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 175173
Tests which
We have introduced a new config option to support 32 bit physical address.
By default, it is disabled.
ARM_PA_32 cannot be enabled on ARM_64 as the memory management unit works
on 48bit physical addresses.
On ARM_32, it can be used on systems where large page address extension is
not supported.
Si
1. Supersections are supported only for paddr greater than 32 bits.
2. Use 0 wherever physical addresses are right shifted for 32 bits.
3. Use PRIx64 to print u64
Signed-off-by: Ayan Kumar Halder
---
xen/arch/arm/guest_walk.c | 2 ++
xen/arch/arm/mm.c | 2 +-
xen/driver
zeroeth_table_offset is not accessed for ARM_32.
This is a left over of the following commit
"
commit 5fa6e9abfb11
Author: Ian Campbell
Date: Thu Sep 18 01:09:48 2014 +0100
xen: arm: Implement variable levels in dump_pt_walk
"
Signed-off-by: Ayan Kumar Halder
---
xen/arch/arm/include/as
dt_device_get_address() will return address and size which are always 'u64'.
One should use translate_dt_address_size() to translate address and size to
'paddr_t'.
Signed-off-by: Ayan Kumar Halder
---
xen/arch/arm/domain_build.c| 53 +++---
xen/arch/arm/gic-v2.c
bankbase, banksize and bankend are used to hold values of type
'unsigned long long'. Thus, one should use 'u64' instead of 'paddr_t'
(which may be either u64 or u32 depending on the architecture).
Signed-off-by: Ayan Kumar Halder
---
xen/arch/arm/domain_build.c | 6 +++---
1 file changed, 3 inse
One should use 'PRIpaddr' to display 'paddr_t' variables.
This may either be PRIx32 or PRIx64 depending of the type of architecture.
Signed-off-by: Ayan Kumar Halder
---
xen/arch/arm/domain_build.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/xen/arch/arm/domain
paddr_t may be u64 or u32 depending of the type of architecture.
Thus, while translating between u64 and paddr_t, one should check that the
truncated bits are 0. If not, then raise an appropriate error.
Signed-off-by: Ayan Kumar Halder
---
xen/arch/arm/include/asm/platform.h | 26 +++
Hi,
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 support fo
device_tree_get_reg(), dt_next_cell() uses u64 for address and size.
Thus, the caller needs to be fixed to pass u64 values and then invoke
translate_dt_address_size() to do the translation between u64 and paddr_t.
Signed-off-by: Ayan Kumar Halder
---
xen/arch/arm/bootfdt.c | 22 ++---
As "io_size" and "uart->io_size" are both u64, so there will be no truncation.
Thus, one can remove the ASSERT() and extra assignment.
In an earlier commit (7c1de0038895),
"ns16550.io_size" was u32 and "io_size" was u64. Thus, the ASSERT() was needed
to check if the values are the same.
However, i
Hi Julien,
-Original Message-
From: Julien Grall
Sent: Tuesday, December 13, 2022 3:55 PM
To: Smith, Jackson
>
> On 13/12/2022 19:48, Smith, Jackson wrote:
> > Hi Xen Developers,
>
> Hi Jackson,
>
> Thanks for sharing the prototype with the community. Some
> questions/remarks below.
>
>
On Thu, 15 Dec 2022, Jan Beulich wrote:
> On 15.12.2022 16:25, Michal Orzel wrote:
> > Add a new test hyp-xen-version to perform functional testing of
> > xen_version hypercall. Check the following commands (more can be added
> > later on):
> > - XENVER_version,
> > - XENVER_extraversion,
> > -
On 15/12/2022 1:31 pm, Viresh Kumar wrote:
> The field 'base' in 'struct libxl_device_virtio' is defined as uint64,
> while we are printing it with '%lu', which is 32bit only 32-bit
> platforms. And so generates a error like:
>
> libxl_internal.h:4388:51: error: format '%lu' expects argument of t
On Thu, Dec 15, 2022 at 05:17:30PM +, Andrew Cooper wrote:
> On 15/12/2022 8:49 am, Jan Beulich wrote:
> > On 15.12.2022 00:11, Demi Marie Obenour wrote:
> >> --- a/xen/arch/x86/include/asm/x86-defns.h
> >> +++ b/xen/arch/x86/include/asm/x86-defns.h
> >> @@ -153,4 +153,15 @@
> >> (1u << X
On 15/12/2022 5:33 pm, Anthony PERARD wrote:
> On Thu, Dec 15, 2022 at 04:58:02PM +, Andrew Cooper wrote:
>> A consumer of xenstore has to cope with all bases anyway. Anything that
>> doesn't is broken.
> So libxl is broken, that good to know :-).
Yes. Really, yes.
This is sufficiently basi
flight 175284 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175284/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 175173
Tests which
On Thu, Dec 15, 2022 at 04:58:02PM +, Andrew Cooper wrote:
> A consumer of xenstore has to cope with all bases anyway. Anything that
> doesn't is broken.
So libxl is broken, that good to know :-). Most keys read by libxl are
expected to be base 10, with some allowed to be in different base (a
Hi Stewart,
> On 15 Dec 2022, at 3:10 pm, Stewart Hildebrand
> wrote:
>
> On 12/15/22 09:51, Julien Grall wrote:
>> Hi Stewart,
>>
>> On 15/12/2022 14:11, Stewart Hildebrand wrote:
>>> On 12/15/22 06:34, Julien Grall wrote:
Hi Stewart,
I was about to commit this patch when I no
On 15/12/2022 8:49 am, Jan Beulich wrote:
> On 15.12.2022 00:11, Demi Marie Obenour wrote:
>> --- a/xen/arch/x86/include/asm/x86-defns.h
>> +++ b/xen/arch/x86/include/asm/x86-defns.h
>> @@ -153,4 +153,15 @@
>> (1u << X86_EXC_AC) | (1u << X86_EXC_CP) | \
>> (1u << X8
This patch introduces an optional TPM 2 interface definition to the ACPI table,
which is to be used as part of a vTPM 2 implementation.
Signed-off-by: Jennifer Herbert
---
tools/firmware/hvmloader/config.h | 1 +
tools/firmware/hvmloader/util.c | 7 ++
tools/libacpi/Makefile|
This patch makes the TPM version, for which the ACPI library probes,
configurable.
If acpi_config.tpm_verison is set to 1, it indicates that 1.2 (TCPA) should be
probed.
I have also added to hvmloader an option to allow setting this new config,
which can
be triggered by setting the platform/tpm_
This patch makes the TPM version, for which the ACPI library probes,
configurable.
This version incorpates feedback from v1, including splitting it into
two patches, tidying up some formatting, removing debug, and moving the
log into a more suitable memory area.
Jennifer Herbert (2):
acpi: Make
On 15.12.2022 00:11, Demi Marie Obenour wrote:
> --- a/xen/arch/x86/include/asm/processor.h
> +++ b/xen/arch/x86/include/asm/processor.h
> @@ -96,7 +96,15 @@
> * Host IA32_CR_PAT value to cover all memory types. This is not the default
> * MSR_PAT value, and is an ABI with PV guests.
> */
>
On 15/12/2022 3:11 pm, Jan Beulich wrote:
> On 15.12.2022 14:48, Anthony PERARD wrote:
>> On Thu, Dec 15, 2022 at 07:01:40PM +0530, Viresh Kumar wrote:
>>> The field 'base' in 'struct libxl_device_virtio' is defined as uint64,
>>> while we are printing it with '%lu', which is 32bit only 32-bit
>>>
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-ovmf-amd64
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenb
On 15.12.2022 00:11, Demi Marie Obenour wrote:
> No functional change intended.
>
> Signed-off-by: Demi Marie Obenour
I'm not convinced removing this (visual) distinction is a good idea.
I'd like to wait for other maontainers' views here.
Jan
On 15.12.2022 00:11, Demi Marie Obenour wrote:
> This allows eliminating of the former, with the exception of
> MTRR_NUM_TYPES. MTRR_NUM_TYPES is kept, as due to a quirk of the x86
> architecture X86_MT_UCM (7) is not valid in an MTRR.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Demi Marie
On Thu, Dec 15, 2022 at 09:46:41AM +0100, Jan Beulich wrote:
> On 15.12.2022 00:11, Demi Marie Obenour wrote:
> > get_page_from_l1e() relied on Xen's choice of PAT, which is brittle in
> > the face of future PAT changes. Use the proper _PAGE_* constants
> > instead. Also, treat the two unused cas
On 15.12.2022 16:25, Michal Orzel wrote:
> Add a new test hyp-xen-version to perform functional testing of
> xen_version hypercall. Check the following commands (more can be added
> later on):
> - XENVER_version,
> - XENVER_extraversion,
> - XENVER_compile_info,
> - XENVER_changeset
> - XENVER
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-armhf
testid xen-build
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 tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 43
flight 175279 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175279/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 175173
Tests which
Add test jobs in both debug and non-debug versions to run hyp-xen-version
XTF test as a dom0less domU on arm64. The purpose of this test is to
validate the functional behavior of xen_version hypercall.
Signed-off-by: Michal Orzel
---
automation/gitlab-ci/test.yaml | 16
1 file c
This series adds support into our CI for using XTF to perform low-level
testing on arm64 (dom0less use case for now). For the purpose of the CI
testing, we are going to use XTF fork with implemented arm64 support.
This series populates the CI jobs to run hyp-xen-version XTF test to validate
some o
Introduce support for using XTF on Arm to perform low-level testing.
For the purpose of the CI testing, let's use the fork [1] from upstream
XTF with implemented support for arm64 (the upstream XTF only supports
x86).
Add a new script under automation/scripts to be used by the CI XTF test
jobs to
Add a new test hyp-xen-version to perform functional testing of
xen_version hypercall. Check the following commands (more can be added
later on):
- XENVER_version,
- XENVER_extraversion,
- XENVER_compile_info,
- XENVER_changeset
- XENVER_get_features,
- passing invalid command.
For now, enab
On 15.12.2022 14:31, Viresh Kumar wrote:
> The field 'base' in 'struct libxl_device_virtio' is defined as uint64,
> while we are printing it with '%lu', which is 32bit only 32-bit
> platforms. And so generates a error like:
>
> libxl_internal.h:4388:51: error: format '%lu' expects argument of ty
On 15.12.2022 14:48, Anthony PERARD wrote:
> On Thu, Dec 15, 2022 at 07:01:40PM +0530, Viresh Kumar wrote:
>> The field 'base' in 'struct libxl_device_virtio' is defined as uint64,
>> while we are printing it with '%lu', which is 32bit only 32-bit
>> platforms. And so generates a error like:
>>
>>
On 12/15/22 09:51, Julien Grall wrote:
> Hi Stewart,
>
> On 15/12/2022 14:11, Stewart Hildebrand wrote:
>> On 12/15/22 06:34, Julien Grall wrote:
>>> Hi Stewart,
>>>
>>> I was about to commit this patch when I noticed the placement of the
>>> attribute doesn't match what we are usually doing in Xe
Hi Stewart,
On 15/12/2022 14:11, Stewart Hildebrand wrote:
On 12/15/22 06:34, Julien Grall wrote:
Hi Stewart,
I was about to commit this patch when I noticed the placement of the
attribute doesn't match what we are usually doing in Xen.
On 13/12/2022 18:18, Stewart Hildebrand wrote:
When bui
On 12/15/22 06:34, Julien Grall wrote:
> Hi Stewart,
>
> I was about to commit this patch when I noticed the placement of the
> attribute doesn't match what we are usually doing in Xen.
>
> On 13/12/2022 18:18, Stewart Hildebrand wrote:
>> When building with clang 12 and CONFIG_ARM_SMMU_V3=y, we
On Thu, Dec 15, 2022 at 07:03:03PM +0530, Viresh Kumar wrote:
> On 15-12-22, 08:34, Julien Grall wrote:
> > This build breakage was introduced by "libxl: add support for generic virtio
> > device". %lu will likely want to be switched to PRIx64.
> >
> > Viresh, we need to unblock OSStest (our CI) a
flight 175272 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175272/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 175173
Tests which
On Fri, Dec 09, 2022 at 09:26, Jason Andryuk wrote:
> xen kbdfront registers itself as being able to deliver *any* key since
> it doesn't know what keys the backend may produce.
>
> Unfortunately, the generated modalias gets too large and uevent creation
> fails with -ENOMEM.
>
> This can lead to
On Thu, Dec 15, 2022 at 07:01:40PM +0530, Viresh Kumar wrote:
> The field 'base' in 'struct libxl_device_virtio' is defined as uint64,
> while we are printing it with '%lu', which is 32bit only 32-bit
> platforms. And so generates a error like:
>
> libxl_internal.h:4388:51: error: format '%lu' e
On 15-12-22, 08:34, Julien Grall wrote:
> This build breakage was introduced by "libxl: add support for generic virtio
> device". %lu will likely want to be switched to PRIx64.
>
> Viresh, we need to unblock OSStest (our CI) as soon as possible. So can you
> look at it and confirm the rest of the
The field 'base' in 'struct libxl_device_virtio' is defined as uint64,
while we are printing it with '%lu', which is 32bit only 32-bit
platforms. And so generates a error like:
libxl_internal.h:4388:51: error: format '%lu' expects argument of type 'long
unsigned int', but argument 3 has type '
Currently, kernel_uimage_probe() does not set info->zimage.start. As a
result, it contains the default value (ie 0). This causes,
kernel_zimage_place() to treat the binary (contained within uImage) as
position independent executable. Thus, it loads it at an incorrect address.
The correct approach
Hi,
On 12/12/2022 09:55, Julien Grall wrote:
From: Julien Grall
Hi all,
Currently, Xen on Arm will switch TTBR whilst the MMU is on. This is
similar to replacing existing mappings with new ones. So we need to
follow a break-before-make sequence.
When switching the TTBR, we need to temporary
flight 175263 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175263/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 175202
test-amd64-amd64-xl-qemuu
flight 175265 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175265/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 175173
Tests which
On 11/12/2022 11:10, Julien Grall wrote:
Hi Stefano,
On 09/12/2022 22:25, Stefano Stabellini wrote:
We have 3 violations of MISRA C Rule 4.1 ("Octal and hexadecimal escape
sequences shall be terminated") in xen/arch/arm/efi/efi-boot.h. Fix them
and take the opportunity to declare them as sta
Hi Stewart,
I was about to commit this patch when I noticed the placement of the
attribute doesn't match what we are usually doing in Xen.
On 13/12/2022 18:18, Stewart Hildebrand wrote:
When building with clang 12 and CONFIG_ARM_SMMU_V3=y, we observe the
following build error:
drivers/passth
On 05/12/2022 13:26, Ayan Kumar Halder wrote:
Hi All,
Hi Ayan,
Please find the following patches to enable GICv3 for AArch32.
This is a pre-requisite to support Xen on Cortex-R52 (AArch32-v8R system)
Let me know your thoughts.
The series is now merged.
Cheers,
--
Julien Grall
flight 175233 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175233/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 8 xen-boot fail REGR. vs. 173462
test-amd64-amd64-xl
flight 175208 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175208/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-intel 8 xen-boot fail REGR. vs. 175148
test-amd64-amd64-d
flight 175258 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175258/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 175173
Tests which
flight 175257 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175257/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 175202
test-amd64-amd64-xl-qemuu
On 15/12/2022 09:34, Julien Grall wrote:
>
>
> Hi,
>
> On 15/12/2022 01:41, osstest service owner wrote:
>> flight 175226 xen-unstable-smoke real [real]
>> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Flogs.test-lab.xenproject.org%2Fosstest%2Flogs%2F175226%2F&data=05%7C01%7
On 15.12.2022 00:11, Demi Marie Obenour wrote:
> --- a/xen/arch/x86/include/asm/x86-defns.h
> +++ b/xen/arch/x86/include/asm/x86-defns.h
> @@ -153,4 +153,15 @@
> (1u << X86_EXC_AC) | (1u << X86_EXC_CP) | \
> (1u << X86_EXC_VC) | (1u << X86_EXC_SX))
>
> +/* Memory
On 15.12.2022 00:11, Demi Marie Obenour wrote:
> get_page_from_l1e() relied on Xen's choice of PAT, which is brittle in
> the face of future PAT changes. Use the proper _PAGE_* constants
> instead. Also, treat the two unused cases as if they are cacheable, as
> future changes may make them cachea
flight 175245 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175245/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 175191
test-armhf-armhf-libvirt-raw 15 saveresto
Hi,
On 15/12/2022 01:41, osstest service owner wrote:
flight 175226 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175226/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xe
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-pvhv2-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 git://xenbits.
On 15/12/2022 08:03, Juergen Gross wrote:
Might be, but do we really want that?
Wouldn't it make more sense to let the user explicitly say that he wants
a lock
to be taken non-recursively? Allowing "spin_lock()" would add some more
risk to
use it by accident e.g. because of copy/paste with
core_set_legacy_ssbd() counts the number of times SSBD is being enabled
via LS_CFG on a core. This assumes that calls there only occur if the
state actually changes. While svm_ctxt_switch_{to,from}() conform to
this, guest_wrmsr() doesn't: It also calls the function when the bit
doesn't actually ch
On 15.12.22 08:48, Jan Beulich wrote:
On 14.12.2022 17:36, Juergen Gross wrote:
On 14.12.22 17:25, Daniel P. Smith wrote:
On 12/14/22 10:31, Juergen Gross wrote:
On 14.12.22 16:03, Daniel P. Smith wrote:
On 9/10/22 11:49, Juergen Gross wrote:
Instead of being able to use normal spinlocks as
100 matches
Mail list logo
