Hi Roger,
On 10/1/24 17:21, Roger Pau Monné wrote:
On Wed, Jan 10, 2024 at 03:47:12PM +0200, Xenia Ragiadakou wrote:
On 10/1/24 12:26, Jan Beulich wrote:
On 10.01.2024 10:53, Roger Pau Monne wrote:
The HVM pirq feature allows routing interrupts from both physical and emulated
devices over e
On Wed, Jan 10, 2024 at 05:41:41PM +, Andrew Cooper wrote:
> On 10/01/2024 4:58 pm, Roger Pau Monné wrote:
> > On Wed, Jan 10, 2024 at 03:52:49PM +, Andrew Cooper wrote:
> >> On 10/01/2024 3:34 pm, Roger Pau Monne wrote:
> >>> When Architectural Performance Monitoring is available, the
> >
On 10.01.2024 17:58, Roger Pau Monné wrote:
> On Wed, Jan 10, 2024 at 03:52:49PM +, Andrew Cooper wrote:
>> On 10/01/2024 3:34 pm, Roger Pau Monne wrote:
>>> When Architectural Performance Monitoring is available, the PERF_GLOBAL_CTRL
>>> MSR contains per-counter enable bits that is ANDed with
On 11.01.2024 03:29, Patrick Plenefisch wrote:
> Hi,
>
> I ran into a memory allocation issue, I think. It is the same as
> https://github.com/QubesOS/qubes-issues/issues/8791 and I saw at the end it
> was recommended (by marmarek) that the issue reporter forward the issue to
> this list. I search
1: x86emul: support LKGS
2: x86emul: support CMPccXADD
3: VMX: tertiary execution control infrastructure
4: x86emul+VMX: support {RD,WR}MSRLIST
5: x86: introduce x86_seg_sys
6: x86emul: support USER_MSR instructions
7: x86/cpu-policy: re-arrange no-VMX logic
8: VMX: support USER_MSR
Jan
Provide support for this insn, which is a prereq to FRED. CPUID-wise
introduce both its and FRED's bit at this occasion, thus allowing to
also express the dependency right away.
While adding a testcase, also add a SWAPGS one. In order to not affect
the behavior of pre-existing tests, install write
Unconditionally wire this through the ->rmw() hook. Since x86_emul_rmw()
now wants to construct and invoke a stub, make stub_exn available to it
via a new field in the emulator state structure.
Signed-off-by: Jan Beulich
---
v3: Add dependency on LM. Re-base.
v2: Use X86_EXC_*. Move past introduc
This is a prereq to enabling the MSRLIST feature.
Note that the PROCBASED_CTLS3 MSR is different from other VMX feature
reporting MSRs, in that all 64 bits report allowed 1-settings.
vVMX code is left alone, though, for the time being.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86
These are "compound" instructions to issue a series of RDMSR / WRMSR
respectively. In the emulator we can therefore implement them by using
the existing msr_{read,write}() hooks. The memory accesses utilize that
the HVM ->read() / ->write() hooks are already linear-address
(x86_seg_none) aware (by
To represent the USER-MSR bitmap access, a new segment type needs
introducing, behaving like x86_seg_none in terms of address treatment,
but behaving like a system segment for page walk purposes (implicit
supervisor-mode access).
Signed-off-by: Jan Beulich
---
This feels a little fragile: Of cour
While UWRMSR probably isn't of much use as long as we don't support
UINTR, URDMSR may well be useful to guests even without that (depending
on what OSes are willing to permit access to).
Since the two VEX encodings introduce a lonely opcode point in map 7,
for now don't bother introducing a full 2
Move the PKS check into an "else" for the corresponding "if()", such
that further adjustments (like for USER_MSR) can easily be put there as
well.
Signed-off-by: Jan Beulich
---
v4: New.
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -665,19 +665,20 @@ static void __init calc
Hook up the new VM exit codes and handle guest accesses, context switch,
and save/restore. At least for now don't allow the guest direct access
to the control MSR; this may need changing if guests were to frequently
access it (e.g. on their own context switch path).
While there also correct a one-
When Architectural Performance Monitoring is available, the PERF_GLOBAL_CTRL
MSR contains per-counter enable bits that is ANDed with the enable bit in the
counter EVNTSEL MSR in order for a PMC counter to be enabled.
So far the watchdog code seems to have relied on the PERF_GLOBAL_CTRL enable
bits
On 11/1/24 10:37, Jan Beulich wrote:
On 11.01.2024 03:29, Patrick Plenefisch wrote:
Hi,
I ran into a memory allocation issue, I think. It is the same as
https://github.com/QubesOS/qubes-issues/issues/8791 and I saw at the end it
was recommended (by marmarek) that the issue reporter forward th
On 11/01/2024 08:31, Jan Beulich wrote:
>
>
> Unlike (synchronous) exception handlers, interrupt handlers don't normally
> have a need to know the outer context's register state. Similarly, the vast
> majority of key handlers has no need for such.
>
> 1: keyhandler: don't pass cpu_user_regs a
On 11.01.2024 10:52, Michal Orzel wrote:
> On 11/01/2024 08:31, Jan Beulich wrote:
>> Unlike (synchronous) exception handlers, interrupt handlers don't normally
>> have a need to know the outer context's register state. Similarly, the vast
>> majority of key handlers has no need for such.
>>
>> 1:
On 11.01.2024 10:08, Roger Pau Monne wrote:
> When Architectural Performance Monitoring is available, the PERF_GLOBAL_CTRL
> MSR contains per-counter enable bits that is ANDed with the enable bit in the
> counter EVNTSEL MSR in order for a PMC counter to be enabled.
>
> So far the watchdog code se
Hi Jan,
On Mon, Jan 8, 2024 at 5:53 PM Jan Beulich wrote:
>
> On 02.01.2024 10:51, Carlo Nonato wrote:
> > This commit adds the Last Level Cache (LLC) coloring common header, Kconfig
> > options and functions. Since this is an arch specific feature, actual
> > implementation is postponed to later
On 11.01.2024 10:08, Roger Pau Monne wrote:
> When Architectural Performance Monitoring is available, the PERF_GLOBAL_CTRL
> MSR contains per-counter enable bits that is ANDed with the enable bit in the
> counter EVNTSEL MSR in order for a PMC counter to be enabled.
>
> So far the watchdog code se
On 11.01.24 09:37, Jan Beulich wrote:
On 11.01.2024 03:29, Patrick Plenefisch wrote:
Hi,
I ran into a memory allocation issue, I think. It is the same as
https://github.com/QubesOS/qubes-issues/issues/8791 and I saw at the end it
was recommended (by marmarek) that the issue reporter forward the
On 11.01.2024 11:10, Carlo Nonato wrote:
> On Mon, Jan 8, 2024 at 5:53 PM Jan Beulich wrote:
>> On 02.01.2024 10:51, Carlo Nonato wrote:
>>> --- a/xen/include/xen/sched.h
>>> +++ b/xen/include/xen/sched.h
>>> @@ -626,6 +626,11 @@ struct domain
>>>
>>> /* Holding CDF_* constant. Internal flags
Hi Julien,
> > > +bool __init llc_coloring_init(void)
> > > +{
> > > +if ( !llc_way_size && !(llc_way_size = get_llc_way_size()) )
> > > +{
> > > +printk(XENLOG_ERR
> > > + "Probed LLC way size is 0 and no custom value
> > > provided\n");
> > > +return false;
On Thu, Jan 11, 2024 at 11:00:28AM +0100, Jan Beulich wrote:
> On 11.01.2024 10:08, Roger Pau Monne wrote:
> > When Architectural Performance Monitoring is available, the PERF_GLOBAL_CTRL
> > MSR contains per-counter enable bits that is ANDed with the enable bit in
> > the
> > counter EVNTSEL MSR
On 11.01.2024 11:32, Roger Pau Monné wrote:
> On Thu, Jan 11, 2024 at 11:00:28AM +0100, Jan Beulich wrote:
>> On 11.01.2024 10:08, Roger Pau Monne wrote:
>>> When Architectural Performance Monitoring is available, the PERF_GLOBAL_CTRL
>>> MSR contains per-counter enable bits that is ANDed with the
On Thu, Jan 11, 2024 at 11:11:07AM +0100, Jan Beulich wrote:
> On 11.01.2024 10:08, Roger Pau Monne wrote:
> > When Architectural Performance Monitoring is available, the PERF_GLOBAL_CTRL
> > MSR contains per-counter enable bits that is ANDed with the enable bit in
> > the
> > counter EVNTSEL MSR
On 11/01/2024 10:17, Carlo Nonato wrote:
Hi Julien,
Hi Carlo,
+bool __init llc_coloring_init(void)
+{
+if ( !llc_way_size && !(llc_way_size = get_llc_way_size()) )
+{
+printk(XENLOG_ERR
+ "Probed LLC way size is 0 and no custom value provided\n");
+ret
Hi,
On 22/12/2022 13:24, Jan Beulich wrote:
That said, I think this change comes too early in the series, or there is
something missing.
At first, I had the same feeling but looking at the rest of the series,
I can see that the option is needed in follow-up patches.
As said in reply to pa
On Wed, Jan 10, 2024 at 12:25:57PM -0800, Vikram Garhwal wrote:
> Hi Javi,
> Thank you for spotting and fixing this.
Hi Vikram,
> On Tue, Jan 09, 2024 at 03:31:55PM +, Julien Grall wrote:
> > On 09/01/2024 14:19, Javi Merino wrote:
> > > In remove_nodes(), overlay_node is dereferenced when pr
flight 184311 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184311/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184299
test-amd64-amd64-xl-qemut-win7-amd64
On 11.01.2024 11:40, Roger Pau Monné wrote:
> On Thu, Jan 11, 2024 at 11:11:07AM +0100, Jan Beulich wrote:
>> On 11.01.2024 10:08, Roger Pau Monne wrote:
>>> When Architectural Performance Monitoring is available, the PERF_GLOBAL_CTRL
>>> MSR contains per-counter enable bits that is ANDed with the
On 11/01/2024 7:31 am, Jan Beulich wrote:
> There are exactly two handlers which care about the registers.
Which two? dump regs and trap to debugger?
[Edit, oh yes, this is clear in the patch, but IMO it would be helpful
to state them here.]
> Have
> handle_keypress() make the pointer available
On 11.01.2024 11:47, Elias El Yandouzi wrote:
> On 22/12/2022 13:24, Jan Beulich wrote:
>> That said, I think this change comes too early in the series, or there is
>> something missing.
>
> At first, I had the same feeling but looking at the rest of the series,
> I can see that the option is ne
In remove_nodes(), overlay_node is dereferenced when printing the
error message even though it is known to be NULL. Return without
printing as an error message is already printed by the caller.
The semantic patch that spots this code is available in
https://git.kernel.org/pub/scm/linux/kernel/gi
On 11.01.2024 12:49, Andrew Cooper wrote:
> On 11/01/2024 7:31 am, Jan Beulich wrote:
>> There are exactly two handlers which care about the registers.
>
> Which two? dump regs and trap to debugger?
>
> [Edit, oh yes, this is clear in the patch, but IMO it would be helpful
> to state them here.]
On 11/01/2024 7:32 am, Jan Beulich wrote:
> Move functions (and their data) to common code, and invoke the functions
> on Arm as well. This is in preparation of dropping the register
> parameters from handler functions.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper with one wording
s
On 11/01/2024 7:33 am, Jan Beulich wrote:
> In the one place where it's needed, get_irq_regs() can be used instead.
> This is in preparation of dropping the register parameters from IRQ
> handler functions.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.8-rc1-tag
xen: branch for v6.8-rc1
It contains:
- a patch updating some Xen PV interface related headers
- a patch fixing some kernel-doc comments in the xenbus driver
- a patch fix
On 11/01/2024 7:33 am, Jan Beulich wrote:
> It's not needed anymore. This is in preparation of dropping the register
> parameters from IRQ handler functions.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On Thu, Jan 11, 2024 at 12:34:45PM +0100, Jan Beulich wrote:
> On 11.01.2024 11:40, Roger Pau Monné wrote:
> > On Thu, Jan 11, 2024 at 11:11:07AM +0100, Jan Beulich wrote:
> >> On 11.01.2024 10:08, Roger Pau Monne wrote:
> >>> When Architectural Performance Monitoring is available, the
> >>> PERF_
Hi Jan,
On 11/01/2024 11:53, Jan Beulich wrote:
On 11.01.2024 11:47, Elias El Yandouzi wrote:
On 22/12/2022 13:24, Jan Beulich wrote:
That said, I think this change comes too early in the series, or there is
something missing.
At first, I had the same feeling but looking at the rest of the s
On 12/8/23 10:38, Yann Dirson wrote:
> Current status:
> - primary goal: to have one guest agent all downstreams can use, in all
> guests (with Linux and FreeBSD already supported), as efficient as
> possible (with Netlink already supported on Linux)
> - developed at https://gitlab.com/xen-project/
Hi Jan,
On 10/01/2024 14:31, Jan Beulich wrote:
Address the TODO regarding first_valid_mfn by making the variable static
when NUMA=y, thus also addressing a Misra C:2012 rule 8.4 concern (on
x86). To carry this out, introduce two new IS_ENABLED()-like macros
conditionally inserting "static". One
When Architectural Performance Monitoring is available, the PERF_GLOBAL_CTRL
MSR contains per-counter enable bits that is ANDed with the enable bit in the
counter EVNTSEL MSR in order for a PMC counter to be enabled.
So far the watchdog code seems to have relied on the PERF_GLOBAL_CTRL enable
bits
On 11.01.2024 13:22, Roger Pau Monné wrote:
> Oh, indeed, can adjust on this same patch if that's OK (seeing as the
> issue was already there previous to my change).
Well, I'm getting the impression that it was deliberate there, i.e. set
setting of the feature flag may want to remain thus constrai
On Wed, Jan 10, 2024 at 03:57:06PM +0100, Jan Beulich wrote:
> ..., at least as reasonably feasible without making a check hook
> mandatory (in particular strict vs relaxed/zero-extend length checking
> can't be done early this way).
>
> Note that only one of the two uses of "real" hvm_load() is a
On 11.01.2024 13:25, Julien Grall wrote:
> Hi Jan,
>
> On 11/01/2024 11:53, Jan Beulich wrote:
>> On 11.01.2024 11:47, Elias El Yandouzi wrote:
>>> On 22/12/2022 13:24, Jan Beulich wrote:
That said, I think this change comes too early in the series, or there is
something missing.
>>>
>>>
On Thu, Jan 11, 2024 at 03:01:01PM +0100, Jan Beulich wrote:
> On 11.01.2024 13:22, Roger Pau Monné wrote:
> > Oh, indeed, can adjust on this same patch if that's OK (seeing as the
> > issue was already there previous to my change).
>
> Well, I'm getting the impression that it was deliberate there
Hi Jan,
On 11/01/2023 14:11, Jan Beulich wrote:
As to using pmap - assuming you've done an audit and the number of
simultaneous mappings that can be in use can be proven to not exceed
the number of slots available, can you please say so in the description?
I don't know if any audit has been ma
These three related patches were previously part of the AMX series,
which has been stuck for about 3 years. For AVX10 some of this is
going to be needed too, though, hence I'm now refreshing these
separately. Neither of the three is strictly a functional prereq,
but two of the three introduce new f
A maximum extended leaf input value with the high half different from
0x8000 should not be considered valid - all leaves should be cleared in
this case.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
TBD: Andrew suggested to drop this patch, but that sub-thread still has
a loos
Zapping leaf data for out of range leaves is just one half of it: To
avoid guests (bogusly or worse) inferring information from mere leaf
presence, also shrink maximum indicators such that the respective
trailing entry is not all blank (unless of course it's the initial
subleaf of a leaf that's not
Break out this logic from calculate_host_policy() to also use it in the
x86 emulator harness, where subsequently we'll want to avoid open-coding
AMX maximum palette bounding as well as AVX10 sub-feature pruning.
Signed-off-by: Jan Beulich
---
v4: Mark x86_cpu_policy_bound_max_leaves() __init. Add
flight 184320 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184320/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ebf378a1ada6d128dbf32aec76b3911895747bbb
baseline version:
ovmf 889535caf8869e3d4818b
AVX10.1 is just a re-branding of certain AVX512 (sub)features, i.e.
adds no new instructions. Therefore it's mostly relaxation that needs
doing, plus dealing with the 256-bit-only case that AVX512 itself
does not allow for. Luckily an unnecessary restriction on the mask
register insns was taken out
This requires bumping the number of basic leaves we support. Apart from
this the logic is modeled as closely as possible after that of leaf 7
handling.
Signed-off-by: Jan Beulich
---
The gen-cpuid.py adjustment is merely the minimum needed. It's not
really clear to me whether someone turning off
In preparation of introducing a const struct cpu_policy * local in
x86_emulate(), rename that global variable to something more suitable:
"cp" is our commonly used name for function parameters or local
variables of type struct cpu_policy *, and the present name of the
global could hence have interf
While of little effect right here, future patches (AVX10, AMX,
KeyLocker) will benefit more significantly.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1232,6 +1232,7 @@ x86_emulate(
{
/* Shadow copy of register st
This requires relaxing various pre-existing AVX512* checks, as AVX10.1
covers all AVX512* except except PF, ER, 4FMAPS, 4VNNIW, and
VP2INTERSECT. Yet potentially with only less than 512-bit vector width,
while otoh guaranteeing more narrow widths being available when wider
are (i.e. unlike AVX512VL
In preparation for having these also cover AVX10, use the helper
functions in preference of open-coded cpu_has_avx512* for those features
that AVX10 includes. Introduce a couple further helper functions where
they weren't previously needed.
Note that this way simd_check_avx512f_sha_vl() gains an A
AVX512VL not being a standalone feature anyway, but always needing
to be combined with some other AVX512*, replace uses of
cpu_has_avx512vl by just the feature bit check.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -1031,7
Re-use respective AVX512 tests, by suitably adjusting the predicate
functions. This leaves test names ("Testing ... NN-bit code sequence")
somewhat misleading, but I think we can live with that.
Note that the AVX512{BW,DQ} opmask tests cannot be run as-is for the
AVX10/256 case, as they include 51
Now that we have machinery in testcase.mk to set vector length dependent
flags for AVX512 tests, let's avoid using a pragma to enable AVX512VL
insns for the compiler. This way, correct settings are in place from the
very beginning of compilation.
No change to the generated test blobs, and hence no
On 11/01/2024 12:11 pm, Jan Beulich wrote:
>>> Have
>>> handle_keypress() make the pointer available via a per-CPU variable,
>>> thus eliminating the need to pass it to all IRQ key handlers, making
>>> sure that a console-invoked key's handling can still nest inside a
>>> sysctl-invoked one's.
>> I
Hello,
As I've mentioned in previous discussion threads in the xen-devel
community, we are running Xen 4.17 (uprev to 4.18 in progress) on NXP
S32G automotive processors (Cortex-A53 cores) and we wanted to know more
about the support for various VirtIO device types in Xen.
In the Xen 4.17 release
On 11.01.2024 16:24, Andrew Cooper wrote:
> On 11/01/2024 12:11 pm, Jan Beulich wrote:
Have
handle_keypress() make the pointer available via a per-CPU variable,
thus eliminating the need to pass it to all IRQ key handlers, making
sure that a console-invoked key's handling can st
On 11.01.2024 15:15, Roger Pau Monné wrote:
> On Thu, Jan 11, 2024 at 03:01:01PM +0100, Jan Beulich wrote:
>> On 11.01.2024 13:22, Roger Pau Monné wrote:
>>> Oh, indeed, can adjust on this same patch if that's OK (seeing as the
>>> issue was already there previous to my change).
>>
>> Well, I'm get
On 22.12.2023 16:12, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
> ---
> Changes in V3:
> - update the commit message
There (still) is none - what is the above about?
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/guest_atomics.h
> @@ -0,0 +1,49 @@
> +/* SPDX-License-Identifie
On 22.12.2023 16:12, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/system.h
> @@ -0,0 +1,90 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef _ASM_RISCV_BARRIER_H
> +#define _ASM_RISCV_BARRIER_H
s/BARRIER/SYSTEM/ ?
With that taken care of (which I'd be
On 11/01/2024 3:49 pm, Jan Beulich wrote:
> On 11.01.2024 16:24, Andrew Cooper wrote:
>> On 11/01/2024 12:11 pm, Jan Beulich wrote:
>> It does occur to me that we're trying to accommodate for two behaviours
>> here.
>>
>> For a real keypress, we want to dump from the the point the interrupt
>> hit
On 11.01.2024 17:08, Andrew Cooper wrote:
> On 11/01/2024 3:49 pm, Jan Beulich wrote:
>> On 11.01.2024 16:24, Andrew Cooper wrote:
>>> On 11/01/2024 12:11 pm, Jan Beulich wrote:
>>> It does occur to me that we're trying to accommodate for two behaviours
>>> here.
>>>
>>> For a real keypress, we wan
On 22.12.2023 16:12, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
> ---
> Changes in V3:
> - drop cpu_is_offline() as it was moved to xen/smp.h.
Hmm.
> - add SPDX.
> - drop unnessary #ifdef.
> - fix "No new line"
> - update the commit message
And another hmm.
> --- /dev/null
On 22.12.2023 17:32, Oleksii wrote:
>> +#define PFN_ORDER(_pfn) ((_pfn)->v.free.order)
> I missed saving these changes. It should be _pfn -> pfn_. (Just a
> reminder for me).
And what purpose would the trailing underscore serve here?
Jan
On Thu, Jan 11, 2024 at 04:52:04PM +0100, Jan Beulich wrote:
> On 11.01.2024 15:15, Roger Pau Monné wrote:
> > On Thu, Jan 11, 2024 at 03:01:01PM +0100, Jan Beulich wrote:
> >> On 11.01.2024 13:22, Roger Pau Monné wrote:
> >>> Oh, indeed, can adjust on this same patch if that's OK (seeing as the
>
flight 184322 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184322/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0765ee6cd36aef02236ae431a7097624d17762d9
baseline version:
ovmf ebf378a1ada6d128dbf32
On Wed, 2024-01-10 at 11:26 +0100, Jan Beulich wrote:
> On 10.01.2024 10:53, Roger Pau Monne wrote:
> > The HVM pirq feature allows routing interrupts from both physical and
> > emulated
> > devices over event channels, this was done a performance improvement.
> > However
> > its usage is fully
On 11/01/2024 7:34 am, Jan Beulich wrote:
> In the the polling functions (ab)using set_irq_regs() is necessary
> to balance the change.
I have to admit that I don't know what "balance the change" is supposed
to refer to in this context.
> --- a/xen/drivers/char/ehci-dbgp.c
> +++ b/xen/drivers/cha
On 11/01/2024 7:35 am, Jan Beulich wrote:
> It's simply not needed anymore. Note how Linux made this change many
> years ago already, in 2.6.19 (late 2006, see [1]).
>
> Signed-off-by: Jan Beulich
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=7d12e780e003f
On 11/01/2024 7:36 am, Jan Beulich wrote:
> The vendor functions don't use the respective parameters at all. In
> vpmu_do_interrupt() there's only a very limited area where the
> outer context's state would be needed, retrievable by get_irq_regs().
>
> This is in preparation of dropping the registe
On 11/01/2024 7:36 am, Jan Beulich wrote:
> The only place it was needed is in the spurious handler, and there we
> can use get_irq_regs() instead.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
I'd forgotten that we'd abused SPIV like that, but oh well.
On 11/01/2024 14:09, Jan Beulich wrote:
On 11.01.2024 13:25, Julien Grall wrote:
Hi Jan,
On 11/01/2024 11:53, Jan Beulich wrote:
On 11.01.2024 11:47, Elias El Yandouzi wrote:
On 22/12/2022 13:24, Jan Beulich wrote:
That said, I think this change comes too early in the series, or there is
From: Julien Grall
Hi all,
This small series is based on some debugging I added while investigating
f5a49eb7f8b3 ("xen/arm32: head: Add mising isb in
switch_to_runtime_mapping()").
This will make easier to narrow down where the CPU is stuck while
enabling the MMU.
Cheers,
Julien Grall (2):
From: Julien Grall
The sequence to enable the MMU on arm32 is quite complex as we may need
to jump to a temporary mapping to map Xen.
Recently, we had one bug in the logic (see f5a49eb7f8b3 ("xen/arm32:
head: Add mising isb in switch_to_runtime_mapping()") and it was
a pain to debug because ther
From: Julien Grall
Since commit 5e213f0f4d2c ("xen/arm32: head: Widen the use of the
temporary mapping"), boot_second (used to cover regions like Xen and
the fixmap) will not be mapped if the identity mapping overlap.
So it is ok to prepare the fixmap table and link it in boot_second
earlier. Wi
flight 184314 linux-linus real [real]
flight 184321 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184314/
http://logs.test-lab.xenproject.org/osstest/logs/184321/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
When livepatching is enabled, this function is used all the time. Really do
check the fastpath first, and annotate it likely() as this is the right answer
100% of the time (to many significant figures). This cuts out 3 pointer
dereferences in the "nothing to do path".
However, GCC still needs so
flight 184316 libvirt real [real]
flight 184323 libvirt real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184316/
http://logs.test-lab.xenproject.org/osstest/logs/184323/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-li
On Thu, Jan 11, 2024 at 12:09:27PM +, Javi Merino wrote:
> In remove_nodes(), overlay_node is dereferenced when printing the
> error message even though it is known to be NULL. Return without
> printing as an error message is already printed by the caller.
>
> The semantic patch that spots th
Hi Julien
On 1/9/24 12:14 PM, Julien Grall wrote:
> (+ Stefano)
>
> Hi Shawn,
>
> On 15/12/2023 02:43, Shawn Anastasio wrote:
>> The early_print_info routine in bootfdt.c incorrectly stores the result
>> of a call to fdt_num_mem_rsv() in an unsigned int, which results in the
>> negative error co
Hi Oleksii,
On 12/22/23 9:13 AM, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
> ---
> Changes in V3:
> - add SPDX
> - drop unneeded for now p2m types.
> - return false in all functions implemented with BUG() inside.
> - update the commit message
> ---
> Changes in V2:
> - Nothin
Fixes for two bugs initially reported to the Xen Security Team, but determined
not have an impact in security-supported configurations.
The Xen Security Team would like to thank Ishiisan for engaging in responsible
disclsoure.
As a reminder to the rest of the Xen community, please do ask you're n
... rather than having them spread out. Explain consicely why each is empty.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: George Dunlap
v2:
* New.
---
xen/arch/x86/hvm/vmx/vmx.c | 21 ++---
1 file changed, 6 in
Right now, vvmx will blindly copy L12's ACTIVITY_STATE into the L02 VMCS and
enter the vCPU. Luckily for us, nested-virt is explicitly unsupported for
security bugs.
The inactivity states are HLT, SHUTDOWN and WAIT-FOR-SIPI, and as noted by the
SDM in Vol3 27.7 "Special Features of VM Entry":
When receiving an INIT, a prior bugfix tried to ignore the INIT and continue
onwards.
Unfortunately it's not safe to return at that point in vmx_vmexit_handler().
Just out of context in the first hunk is a local_irqs_enabled() which is
depended-upon by the return-to-guest path, causing the followi
The early_print_info routine in bootfdt.c incorrectly stores the result
of a call to fdt_num_mem_rsv() in an unsigned int, which results in the
negative error code being interpreted incorrectly in a subsequent loop
in the case where the device tree is malformed. Fix this by properly
checking the re
On Wed, 10 Jan 2024, Jan Beulich wrote:
> On 10.01.2024 01:46, Stefano Stabellini wrote:
> > On Tue, 9 Jan 2024, Jan Beulich wrote:
> >> On 02.01.2024 10:51, Carlo Nonato wrote:
> >>> This commit adds a new memory page allocator that implements the cache
> >>> coloring mechanism. The allocation alg
Hi Andrei,
Great that you are working with Xen and virtio. We at AMD are very
interested in it as well.
I'll let Artem (CCed) and his team comment about the xen-troops
repository.
I can share that from our side we are working toward adding complete
support for using QEMU as virtio-backends provi
Hi Andrei & Stefano,
On Thu, Jan 11, 2024 at 04:35:22PM -0800, Stefano Stabellini wrote:
> Hi Andrei,
>
> Great that you are working with Xen and virtio. We at AMD are very
> interested in it as well.
>
> I'll let Artem (CCed) and his team comment about the xen-troops
> repository.
>
> I can sha
flight 184318 linux-5.4 real [real]
flight 184326 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184318/
http://logs.test-lab.xenproject.org/osstest/logs/184326/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
t
flight 184325 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184325/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 58355ec1926563efc954821a2851365182a4ebd4
baseline version:
ovmf 0765ee6cd36aef02236ae
1 - 100 of 112 matches
Mail list logo
