On 26.02.2024 18:39, Oleksii Kurochko wrote:
> This patch doesn't represent a strict lower bound for GCC and
> GNU Binutils; rather, these versions are specifically employed by
> the Xen RISC-V container and are anticipated to undergo continuous
> testing.
Up and until that container would be upda
On 26.02.2024 18:38, Oleksii Kurochko wrote:
> From the unpriviliged doc:
> No standard hints are presently defined.
> We anticipate standard hints to eventually include memory-system spatial
> and temporal locality hints, branch prediction hints, thread-scheduling
> hints, security tags, a
On 26.02.2024 18:38, Oleksii Kurochko wrote:
> The following headers end up the same as asm-generic's version:
> * altp2m.h
> * device.h
> * div64.h
> * hardirq.h
> * hypercall.h
> * iocap.h
> * paging.h
> * percpu.h
> * random.h
> * softirq.h
> * vm_event.h
>
> RISC-V should utilize the asm-gener
On 27.02.2024 01:26, Stefano Stabellini wrote:
> On Mon, 26 Feb 2024, Jan Beulich wrote:
>> On 23.02.2024 10:35, Nicola Vetrini wrote:
>>> Refactor cpu_notifier_call_chain into two functions:
>>> - the variant that is allowed to fail loses the nofail flag
>>> - the variant that shouldn't fail is en
On 27.02.2024 00:48, Stefano Stabellini wrote:
> On Mon, 26 Feb 2024, Jan Beulich wrote:
>> On 23.02.2024 23:36, Stefano Stabellini wrote:
>>> On Fri, 23 Feb 2024, Jan Beulich wrote:
On 23.02.2024 02:32, Stefano Stabellini wrote:
> On Tue, 24 Oct 2023, Jan Beulich wrote:
>> On 24.10.20
On 26.02.2024 23:49, Stefano Stabellini wrote:
> On Mon, 26 Feb 2024, Jan Beulich wrote:
>> On 26.02.2024 09:23, Nicola Vetrini wrote:
>>> On 2024-02-26 09:00, Jan Beulich wrote:
On 23.02.2024 23:56, Stefano Stabellini wrote:
> On Fri, 23 Feb 2024, Nicola Vetrini wrote:
>> These functi
flight 184777 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184777/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 33c81c25bbd55141ad395af89160b4ed4b703cdf
baseline version:
ovmf d25421d0d8cd2493b3021
flight 184771 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184771/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 184762
test-amd64-amd64-xl-qemuu-win7-amd64
flight 184775 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184775/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d25421d0d8cd2493b30215ef80d2424ecb19c870
baseline version:
ovmf 68238d4f948069fc2c6b9
> Subject: Re: question about virtio-vsock on xen
>
>
>
> On 26.02.24 05:09, Peng Fan wrote:
> > Hi Oleksandr,
>
> Hello Peng
>
>
> [snip]
>
> >>
> >> ... Peng, we have vhost-vsock (and vhost-net) Xen PoC. Although
> >> it is non- upstreamable in its current shape (based on old Linux
> >
flight 184774 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184774/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
> Subject: RE: question about virtio-vsock on xen
>
> On Mon, 26 Feb 2024, Peng Fan wrote:
> > Hi Stefano,
> >
> > > Subject: Re: question about virtio-vsock on xen
> > >
> > > Hi Peng,
> > >
> > > We haven't tried to setup virtio-vsock yet.
> > >
> > > In general, I am very supportive of using QE
On Mon, 26 Feb 2024, Jan Beulich wrote:
> On 23.02.2024 10:35, Nicola Vetrini wrote:
> > Refactor cpu_notifier_call_chain into two functions:
> > - the variant that is allowed to fail loses the nofail flag
> > - the variant that shouldn't fail is encapsulated in a call
> > to the failing variant,
On Sat, 24 Feb 2024, Nicola Vetrini wrote:
> Hi Stefano,
>
> On 2024-02-24 00:05, Stefano Stabellini wrote:
> > On Fri, 23 Feb 2024, Nicola Vetrini wrote:
> > > On 2024-02-19 16:14, Nicola Vetrini wrote:
> > > > The cache clearing and invalidation helpers in x86 and Arm didn't
> > > > comply with
On Mon, 26 Feb 2024, Jan Beulich wrote:
> On 23.02.2024 23:36, Stefano Stabellini wrote:
> > On Fri, 23 Feb 2024, Jan Beulich wrote:
> >> On 23.02.2024 02:32, Stefano Stabellini wrote:
> >>> On Tue, 24 Oct 2023, Jan Beulich wrote:
> On 24.10.2023 00:05, Stefano Stabellini wrote:
> > On Mon
On Sat, 24 Feb 2024, Olaf Hering wrote:
> Fri, 23 Feb 2024 15:22:38 -0800 (PST) Stefano Stabellini
> :
>
> > Do you have a successful gitlab pipeline with this patch applied that
> > you can give me as proof of testing and success?
>
> Yes, all of them since the patch went out.
Great thanks!
A
flight 184767 xen-unstable real [real]
flight 184773 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184767/
http://logs.test-lab.xenproject.org/osstest/logs/184773/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Mon, 26 Feb 2024, Jan Beulich wrote:
> On 26.02.2024 09:23, Nicola Vetrini wrote:
> > On 2024-02-26 09:00, Jan Beulich wrote:
> >> On 23.02.2024 23:56, Stefano Stabellini wrote:
> >>> On Fri, 23 Feb 2024, Nicola Vetrini wrote:
> These functions never saw a usage of their return value since
flight 184772 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184772/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 68238d4f948069fc2c6b9cc13863bdced52a84d0
baseline version:
ovmf 44fdc4f3983be77dda709
On Mon, 26 Feb 2024, Peng Fan wrote:
> Hi Stefano,
>
> > Subject: Re: question about virtio-vsock on xen
> >
> > Hi Peng,
> >
> > We haven't tried to setup virtio-vsock yet.
> >
> > In general, I am very supportive of using QEMU for virtio backends. We use
> > QEMU to provide virtio-net, virtio
On 26.02.24 05:09, Peng Fan wrote:
> Hi Oleksandr,
Hello Peng
[snip]
>>
>> ... Peng, we have vhost-vsock (and vhost-net) Xen PoC. Although it is
>> non-
>> upstreamable in its current shape (based on old Linux version, requires some
>> rework and proper integration, most likely requires
Hi Roger,
On 2/7/24 8:55 AM, Roger Pau Monne wrote:
> And use it to replace CODE_ALIGN in assembly. This allows to generalize the
> way the code alignment gets set across all architectures.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Shawn Anastasio
Thank
Hi Stefano,
Sorry for the delay on this.
Acked-by: Shawn Anastasio
Best,
Shawn
On 2/23/24 5:19 PM, Stefano Stabellini wrote:
> Shawn,
>
> I am thinking of committing this, if you disagree please say something
> in the next couple of days
>
>
> On Tue, 19 Dec 2023, Simone Ballarin wrote:
>>
flight 184769 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184769/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
Signed-off-by: Oleksii Kurochko
Reviewed-by: Jan Beulich
---
Changes in V5:
- Nothing changed. Only rebase.
---
Changes in V4:
- drop stubs for irq_actor_none() and irq_actor_none() as common/irq.c is
compiled now.
- drop defintion of max_page in stubs.c as common/page_alloc.c is compiled now
Signed-off-by: Oleksii Kurochko
---
Changes in V5:
- Code style fixes.
- drop introduced TOOLCHAIN_HAS_ZIHINTPAUSE and use as-insn instead and use
as-insn istead.
---
Changes in V4:
- Change message -> subject in "Changes in V3"
- Documentation about system requirement was added. In the fut
Signed-off-by: Oleksii Kurochko
---
Waiting for dependency to be merged: [PATCH v6 0/9] Introduce generic headers
(https://lore.kernel.org/xen-devel/84568b0c24a5ec96244f3f34537e9a148367facf.1707499278.git.oleksii.kuroc...@gmail.com/)
---
Changes in V4/V5:
- Nothing changed. Only rebase.
---
Ch
Signed-off-by: Oleksii Kurochko
---
Changes in V5:
- drop unrelated changes
- assert_failed("unimplmented...") change to BUG_ON()
---
Changes in V4:
- added new stubs which are necessary for compilation after rebase:
__cpu_up(), __cpu_disable(), __cpu_die()
from smpboot.c
- back changes
flight 184768 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184768/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 44fdc4f3983be77dda709d7a0c3fb8905fbf920b
baseline version:
ovmf ba96acd963e794e86633f
This patch doesn't represent a strict lower bound for GCC and
GNU Binutils; rather, these versions are specifically employed by
the Xen RISC-V container and are anticipated to undergo continuous
testing.
While it is feasible to utilize Clang, it's important to note that,
currently, there is no Xen
Initially the patch was introduced by Bobby, who takes the header from
Linux kernel.
The following changes were done on top of Linux kernel header:
- atomic##prefix##_*xchg_*(atomic##prefix##_t *v, c_t n) were updated
to use__*xchg_generic()
- drop casts in write_atomic() as they are unnece
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V5:
- Nothing changed. Only rebase.
---
Changes in V4:
---
- Change message -> subject in "Changes in V3"
- s/BUG/BUG_ON("...")
- Do proper rebase ( pfn_to_paddr() and paddr_to_pfn() aren't removed ).
---
Changes in V3:
- u
Signed-off-by: Oleksii Kurochko
---
Changes in V5:
- Only rebase was done.
---
Changes in V4:
- New patch.
---
xen/arch/riscv/Makefile | 1 +
xen/arch/riscv/vm_event.c | 19 +++
2 files changed, 20 insertions(+)
create mode 100644 xen/arch/riscv/vm_event.c
diff --git a/xen
The definition of __read_mostly should be removed in:
https://lore.kernel.org/xen-devel/f25eb5c9-7c14-6e23-8535-2c66772b3...@suse.com/
The patch introduces it in arch-specific header to not
block enabling of full Xen build for RISC-V.
Signed-off-by: Oleksii Kurochko
---
- [PATCH] move __read_mos
Signed-off-by: Oleksii Kurochko
---
Changes in V5:
- update the comment around "struct domain *domain;" : zero -> NULL
- fix ident. for unsigned long val;
- put page_to_virt() and virt_to_page() close to each other.
- drop unnessary leading underscore
- drop a space before the comment: /* Cou
Taken from Linux-6.4.0-rc1
Xen's bitops.h consists of several Linux's headers:
* linux/arch/include/asm/bitops.h:
* The following function were removed as they aren't used in Xen:
* test_and_set_bit_lock
* clear_bit_unlock
* __clear_bit_unlock
* The following functions
The header was taken from Linux kernl 6.4.0-rc1.
Addionally, were updated:
* add emulation of {cmp}xchg for 1/2 byte types using 32-bit atomic
access.
* replace tabs with spaces
* replace __* variale with *__
* introduce generic version of xchg_* and cmpxchg_*.
Implementation of 4- and 8-byte c
>From the unpriviliged doc:
No standard hints are presently defined.
We anticipate standard hints to eventually include memory-system spatial
and temporal locality hints, branch prediction hints, thread-scheduling
hints, security tags, and instrumentation flags for simulation/emulation.
Al
Add minimal requied things to be able to build full Xen.
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V5:
- Nothing changed. Only rebase.
---
Changes in V4:
- BUG() was changed to BUG_ON("unimplemented");
- Change "xen/bug.h" to "xen/lib.h" as BUG_ON is defined in xen/
The generic hweight() function can be useful for architectures
that don't have corresponding arch-specific instructions.
Signed-off-by: Oleksii Kurochko
---
Changes in V5:
- new patch
---
xen/include/asm-generic/bitops/hweight.h | 13 +
1 file changed, 13 insertions(+)
create mo
The header taken form Linux 6.4.0-rc1 and is based on
arch/riscv/include/asm/mmio.h with the following changes:
- drop forcing of endianess for read*(), write*() functions as
no matter what CPU endianness, what endianness a particular device
(and hence its MMIO region(s)) is using is entirely i
These functions can be useful for architectures that don't
have corresponding arch-specific instructions.
Signed-off-by: Oleksii Kurochko
---
Changes in V5:
- new patch
---
xen/include/asm-generic/bitops/__ffs.h| 47 +++
xen/include/asm-generic/bitops/ffs.h |
This patch disables unnecessary configs for two cases:
1. By utilizing EXTRA_FIXED_RANDCONFIG for randconfig builds (GitLab CI jobs).
2. By using tiny64_defconfig for non-randconfig builds.
Signed-off-by: Oleksii Kurochko
---
Changes in V5:
- Rebase and drop duplicated configs in EXTRA_FIXED_RAN
Signed-off-by: Oleksii Kurochko
---
Changes in V5:
- new patch
---
xen/arch/riscv/include/asm/fence.h | 9 +
1 file changed, 9 insertions(+)
create mode 100644 xen/arch/riscv/include/asm/fence.h
diff --git a/xen/arch/riscv/include/asm/fence.h
b/xen/arch/riscv/include/asm/fence.h
ne
The patch introduces the following generic functions:
* test_bit
* generic___test_and_set_bit
* generic___test_and_clear_bit
* generic___test_and_change_bit
Also, the patch introduces the following generics which are
used by the functions mentioned above:
* BITOP_BITS_PER_WORD
* BITOP_MASK
* BITOP
The generic ffz() can be useful for architectures
that don't have corresponding arch-specific instruction.
Signed-off-by: Oleksii Kurochko
---
Changes in V5:
- new patch
---
xen/include/asm-generic/bitops/ffz.h | 18 ++
1 file changed, 18 insertions(+)
create mode 100644 xen
These functions can be useful for architectures that don't
have corresponding arch-specific instructions.
Signed-off-by: Oleksii Kurochko
---
Changes in V5:
- new patch
---
xen/include/asm-generic/bitops/fls.h | 18 ++
xen/include/asm-generic/bitops/flsl.h | 10 ++
2
The following headers end up the same as asm-generic's version:
* altp2m.h
* device.h
* div64.h
* hardirq.h
* hypercall.h
* iocap.h
* paging.h
* percpu.h
* random.h
* softirq.h
* vm_event.h
RISC-V should utilize the asm-generic's version of the mentioned
headers instead of introducing them in the
This patch series performs all of the additions necessary to drop the
build overrides for RISCV and enable the full Xen build. Except in cases
where compatibile implementations already exist (e.g. atomic.h and
bitops.h), the newly added definitions are simple.
The patch series is based on the foll
On 26/02/2024 4:52 pm, Jan Beulich wrote:
> On 26.02.2024 17:25, Andrew Cooper wrote:
>> This is long overdue, and we need to start somewhere.
>>
>> Signed-off-by: Andrew Cooper
> Acked-by: Jan Beulich
Thanks.
> perhaps (nit) with ...
>
>> --- /dev/null
>> +++ b/docs/faq.rst
>> @@ -0,0 +1,71 @@
On 26.02.2024 17:25, Andrew Cooper wrote:
> This is long overdue, and we need to start somewhere.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
perhaps (nit) with ...
> --- /dev/null
> +++ b/docs/faq.rst
> @@ -0,0 +1,71 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Frequently Ask
... to a field in the capability/controls struct.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -162,7 +162,6 @@ static int cf_check parse_ept_param_runt
/* Dynamic (run-time adjusted) execution control flags. */
struct vmx_cap
On 06/02/2024 1:20 am, George Dunlap wrote:
> Changeset ef3e8db8068 ("x86/hvm: Corrections and improvements to
> unhandled vmexit logging") introduced a printk to the default path of
> the switch statement in nestedsvm_check_intercepts(), complaining of
> an unknown exit reason.
>
> Unfortunately,
... to a field in the capability/controls struct.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -162,7 +162,6 @@ static int cf_check parse_ept_param_runt
/* Dynamic (run-time adjusted) execution control flags. */
struct vmx_cap
... to fields in the capability/controls struct: Take the opportunity
and split the two halves into separate EPT and VPID fields.
Signed-off-by: Jan Beulich
---
v3: Re-base.
v2: New.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -162,7 +162,6 @@ static int cf_check parse
... to a field in the capability/controls struct.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -162,7 +162,6 @@ static int cf_check parse_ept_param_runt
/* Dynamic (run-time adjusted) execution control flags. */
struct vmx_cap
... to a field in the capability/controls struct.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -162,7 +162,6 @@ static int cf_check parse_ept_param_runt
/* Dynamic (run-time adjusted) execution control flags. */
struct vmx_cap
... to a field in the capability/controls struct.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -162,7 +162,6 @@ static int cf_check parse_ept_param_runt
/* Dynamic (run-time adjusted) execution control flags. */
struct vmx_cap
... to a field in the capability/controls struct.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -162,7 +162,6 @@ static int cf_check parse_ept_param_runt
/* Dynamic (run-time adjusted) execution control flags. */
struct vmx_cap
... to a field in the capability/controls struct. Use an instance of
that struct also in vmx_init_vmcs_config().
Signed-off-by: Jan Beulich
---
v3: Add initializer to vmx_init_vmcs_config() new local var.
v2: New.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -162,7 +162
... to a struct field, which is then going to be accompanied by other
capability/control data presently living in individual variables. As
this structure isn't supposed to be altered post-boot, put it in
.data.ro_after_init right away.
Suggested-by: Roger Pau Monné
Signed-off-by: Jan Beulich
---
It's effectively redundant with vmx_basic_msr. For the #define
replacement to work, struct vmcs_struct's respective field name also
needs to change: Drop the not really meaningful "vmcs_" prefix from it.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86
__init{const,data}_cf_clobber can have an effect only for pointers
actually populated in the respective tables. While not the case for SVM
right now, VMX installs a number of pointers only under certain
conditions. Hence the respective functions would have their ENDBR purged
only when those conditi
While generally benign, doing so is still at best misleading.
Signed-off-by: Jan Beulich
---
Using set_in_cr4() seems favorable over updating mmu_cr4_features
despite the resulting redundant CR4 update. But I certainly could be
talked into going the alternative route.
---
v2: Actually clear CR4.V
01: VMX: don't run with CR4.VMXE set when VMX could not be enabled
02: x86/HVM: improve CET-IBT pruning of ENDBR
03: VMX: drop vmcs_revision_id
04: VMX: convert vmx_basic_msr
05: VMX: convert vmx_pin_based_exec_control
06: VMX: convert vmx_cpu_based_exec_control
07: VMX: convert vmx_secondary_exec_
This is long overdue, and we need to start somewhere.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Stefano Stabellini
CC: Wei Liu
CC: Julien Grall
---
docs/faq.rst | 71 +++
docs/glossary.rst | 15 ++
docs/in
On 02/02/2024 3:16 pm, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> Function and macro properties contained in ECLAIR/call_properties.ecl are of
> general interest: this patch moves these annotations in a generaric JSON file
> in docs. In this way, they can be exploited for other purpo
On 26.02.2024 15:49, Anthony PERARD wrote:
> On Mon, Feb 26, 2024 at 10:23:37AM +0100, Jan Beulich wrote:
>> On 20.02.2024 15:07, Anthony PERARD wrote:
>>> --- a/automation/scripts/build-test.sh
>>> +++ b/automation/scripts/build-test.sh
>>> @@ -9,6 +9,37 @@
>>> # Set NON_SYMBOLIC_REF=1 if you wan
On 26/02/2024 2:22 pm, Jan Beulich wrote:
> On 26.02.2024 15:12, Fouad Hilly wrote:
>> From: Pritha Srivastava
>>
>> xl now knows how to drive tapdisk, so modified libxenstat to
>> understand vbd3 statistics.
>>
>> Signed-off-by: Jorge Martin
>> Signed-off-by: Pritha Srivastava
> Just a formal q
On 26/02/2024 2:32 pm, Jan Beulich wrote:
> On 26.02.2024 13:55, Andrew Cooper wrote:
>> restore_all_guest() does a lot of manipulation of the stack after popping the
>> GPRs, and uses raw %rsp displacements to do so. Also, almost all entrypaths
>> use raw %rsp displacements prior to pushing GPRs.
On Mon, Feb 26, 2024 at 10:23:37AM +0100, Jan Beulich wrote:
> On 20.02.2024 15:07, Anthony PERARD wrote:
> > --- a/automation/scripts/build-test.sh
> > +++ b/automation/scripts/build-test.sh
> > @@ -9,6 +9,37 @@
> > # Set NON_SYMBOLIC_REF=1 if you want to use this script in detached HEAD
> > sta
On 21.02.2024 03:45, Stewart Hildebrand wrote:
> From: Oleksandr Andrushchenko
>
> Use the per-domain PCI read/write lock to protect the presence of the
> pci device vpci field. This lock can be used (and in a few cases is used
> right away) so that vpci removal can be performed while holding the
From: Hou Wenlong
Some PVOPS are patched as the native version directly if the guest is
not a XENPV guest. However, this approach will not work after
introducing a PVM guest. To address this, use a new CPU feature to
describe XENPV and PVM, and ensure that those PVOPS are patched only
when it is
On Mon, 2024-02-26 at 15:20 +0100, Jan Beulich wrote:
> On 26.02.2024 13:58, Oleksii wrote:
> > On Mon, 2024-02-26 at 12:28 +0100, Jan Beulich wrote:
> > > On 26.02.2024 12:18, Oleksii wrote:
> > > > On Mon, 2024-02-26 at 10:45 +0100, Jan Beulich wrote:
> > > > > On 23.02.2024 13:23, Oleksii wrote:
From: Hou Wenlong
For a PIE kernel, it runs in a high virtual address in the PVH entry, so
it needs to relocate the kernel image early in the PVH entry for the PVM
guest.
Signed-off-by: Hou Wenlong
Signed-off-by: Lai Jiangshan
---
arch/x86/include/asm/init.h | 5 +
arch/x86/kernel/
On 26.02.2024 13:55, Andrew Cooper wrote:
> restore_all_guest() does a lot of manipulation of the stack after popping the
> GPRs, and uses raw %rsp displacements to do so. Also, almost all entrypaths
> use raw %rsp displacements prior to pushing GPRs.
>
> Provide better mnemonics, to aid readabil
On 26.02.2024 13:55, Andrew Cooper wrote:
> compat_restore_all_guest() already has SPEC_CTRL_EXIT_TO_PV with a documented
> requirement for %rsp to be both regs and cpuinfo.
>
> Use the now-normal annotations and simplify the expressions which happen to be
> a subtraction of 0.
>
> Signed-off-by:
On 26.02.2024 13:54, Andrew Cooper wrote:
> Some retroactive review, for if I'd got to the patch in time.
>
> * The new ASM-friendly BUILD_BUG_ON() should be in a header file.
> * entry_int82() wants the movl->movb treatment too.
>
> Fixes: c144b9e32427 ("x86: Reduce assembly code size of entry
On Mon, Feb 26, 2024 at 2:12 PM Fouad Hilly wrote:
>
> From: Pritha Srivastava
>
> xl now knows how to drive tapdisk, so modified libxenstat to
> understand vbd3 statistics.
>
> Signed-off-by: Jorge Martin
> Signed-off-by: Pritha Srivastava
> Signed-off-by: Fouad Hilly
> ---
> CC: Wei Liu
> C
On 26.02.2024 15:12, Fouad Hilly wrote:
> From: Pritha Srivastava
>
> xl now knows how to drive tapdisk, so modified libxenstat to
> understand vbd3 statistics.
>
> Signed-off-by: Jorge Martin
> Signed-off-by: Pritha Srivastava
Just a formal question (I'm not really qualified to review this c
On 26.02.2024 13:58, Oleksii wrote:
> On Mon, 2024-02-26 at 12:28 +0100, Jan Beulich wrote:
>> On 26.02.2024 12:18, Oleksii wrote:
>>> On Mon, 2024-02-26 at 10:45 +0100, Jan Beulich wrote:
On 23.02.2024 13:23, Oleksii wrote:
>>
> As 1- and 2-byte cases are emulated I decided that i
From: Pritha Srivastava
xl now knows how to drive tapdisk, so modified libxenstat to
understand vbd3 statistics.
Signed-off-by: Jorge Martin
Signed-off-by: Pritha Srivastava
Signed-off-by: Fouad Hilly
---
CC: Wei Liu
CC: Anthony PERARD
CC: Juergen Gross
---
tools/libs/stat/xenstat_linux.c
On 18/12/2023 7:26 am, Jan Beulich wrote:
> Avoid logging all-identical messages for every vCPU, but make sure to
> log unusual events like the vector differing from vCPU 0's (note that
> the respective condition also makes sure vCPU 0 itself will have the
> vector setting logged), or it changing a
On 22/01/2024 1:41 pm, Jan Beulich wrote:
> elf_load_binary() isn't the primary source of brokenness being
> indicated. Therefore make the respective PVH log message there
> conditional (much like PV has it), and add another instance when
> elf_xen_parse() failed (again matching behavior in the PV
On Mon, 2024-02-26 at 12:28 +0100, Jan Beulich wrote:
> On 26.02.2024 12:18, Oleksii wrote:
> > On Mon, 2024-02-26 at 10:45 +0100, Jan Beulich wrote:
> > > On 23.02.2024 13:23, Oleksii wrote:
> > > > >
> > > > > > > > As 1- and 2-byte cases are emulated I decided that is
> > > > > > > > not
> > >
flight 184763 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184763/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 12 debian-hvm-install fail in
184756 pass in 184763
test-armh
Some retroactive review, for if I'd got to the patch in time.
* The new ASM-friendly BUILD_BUG_ON() should be in a header file.
* entry_int82() wants the movl->movb treatment too.
Fixes: c144b9e32427 ("x86: Reduce assembly code size of entry points")
Signed-off-by: Andrew Cooper
---
CC: Jan Be
compat_restore_all_guest() already has SPEC_CTRL_EXIT_TO_PV with a documented
requirement for %rsp to be both regs and cpuinfo.
Use the now-normal annotations and simplify the expressions which happen to be
a subtraction of 0.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
restore_all_guest() does a lot of manipulation of the stack after popping the
GPRs, and uses raw %rsp displacements to do so. Also, almost all entrypaths
use raw %rsp displacements prior to pushing GPRs.
Provide better mnemonics, to aid readability and reduce the chance of errors
when editing.
N
Misc adjustments and cleanup. No functional change.
Andrew Cooper (3):
x86/entry: Adjustments to "reduce assembly code size of entry points"
x86/entry: Simplify expressions in compat_restore_all_guest()
x86/entry: Introduce EFRAME_* constants
xen/arch/x86/include/asm/asm_defns.h | 12
On 26.02.2024 12:07, Roger Pau Monne wrote:
> Now that the thunk built-in enable is printed as part of the "Compiled-in
> support:" line, avoid printing anything in "Xen settings:" if the thunk is
> disabled at build time.
Why "Now that ..."? It's other logging the earlier patch adds there.
> Not
On 26.02.2024 12:07, Roger Pau Monne wrote:
> Attempt to provide a more helpful error message when the user attempts to set
> spec-ctrl=bti-thunk option but the support is build-time disabled.
>
> While there also adjust the command line documentation to mention
> CONFIG_INDIRECT_THUNK instead of
On 26.02.2024 12:07, Roger Pau Monne wrote:
> The current logic to handle the BRANCH_HARDEN option will report it as enabled
> even when build-time disabled. Fix this by only allowing the option to be set
> when support for it is built into Xen.
>
> Fixes: 2d6f36daa086 ('x86/nospec: Introduce CONF
On 26.02.2024 12:07, Roger Pau Monne wrote:
> Just like it's done for INDIRECT_THUNK and SHADOW_PAGING.
>
> Reported-by: Jan Beulich
> Signed-off-by: Roger Pau Monné
In principle
Reviewed-by: Jan Beulich
but ...
> --- a/xen/arch/x86/spec_ctrl.c
> +++ b/xen/arch/x86/spec_ctrl.c
> @@ -466,13 +4
On 26.02.2024 12:32, Roger Pau Monné wrote:
> On Tue, Feb 13, 2024 at 04:58:38PM +0100, Jan Beulich wrote:
>> On 07.02.2024 15:55, Roger Pau Monne wrote:
>>> The minimal function size requirements for an x86 livepatch are either 5
>>> bytes
>>> (for jmp) or 9 bytes (for endbr + jmp), and always 4
flight 184764 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184764/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On 26.02.2024 12:33, Roger Pau Monné wrote:
> On Tue, Feb 13, 2024 at 04:51:13PM +0100, Jan Beulich wrote:
>> On 07.02.2024 15:55, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -29,6 +29,7 @@ config X86
>>> select HAS_UBSAN
>>> select HAS_VPCI i
On Tue, Feb 13, 2024 at 04:51:13PM +0100, Jan Beulich wrote:
> On 07.02.2024 15:55, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/Kconfig
> > +++ b/xen/arch/x86/Kconfig
> > @@ -29,6 +29,7 @@ config X86
> > select HAS_UBSAN
> > select HAS_VPCI if HVM
> > select NEEDS_LIBELF
> > + selec
On Tue, Feb 13, 2024 at 04:58:38PM +0100, Jan Beulich wrote:
> On 07.02.2024 15:55, Roger Pau Monne wrote:
> > The minimal function size requirements for an x86 livepatch are either 5
> > bytes
> > (for jmp) or 9 bytes (for endbr + jmp), and always 4 bytes on Arm. Ensure
> > that
> > distance be
On 26.02.2024 12:18, Oleksii wrote:
> On Mon, 2024-02-26 at 10:45 +0100, Jan Beulich wrote:
>> On 23.02.2024 13:23, Oleksii wrote:
>>> As 1- and 2-byte cases are emulated I decided that is not
>>> to
>>> provide
>>> sfx argument for emulation macros as it will not have to
>
1 - 100 of 148 matches
Mail list logo
