On 11.01.2024 19:25, Elias El Yandouzi wrote:
>
>
> 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:
Hi Julien,
On 11/01/2024 19:34, Julien Grall wrote:
>
>
> 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
On 11.01.2024 17:53, Roger Pau Monné wrote:
> 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
+ Few Linaro folks.
Hi Andrei,
On 11-01-24, 15:32, Andrei Cherechesu (OSS) wrote:
> 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 t
Some type of domain don't have PIRQ, like PVH, when
passthrough a device to guest on PVH dom0, callstack
pci_add_dm_done->XEN_DOMCTL_irq_permission will failed
at domain_pirq_to_irq.
So, add a new hypercall to grant/revoke gsi permission
when dom0 is not PV or dom0 has not PIRQ flag.
Co-developed
On PVH dom0, the gsis don't get registered, but
the gsi of a passthrough device must be configured for it to
be able to be mapped into a hvm domU.
On Linux kernel side, it calles PHYSDEVOP_setup_gsi for
passthrough devices to register gsi when dom0 is PVH.
So, add PHYSDEVOP_setup_gsi for above purp
In PVH dom0, it uses the linux local interrupt mechanism,
when it allocs irq for a gsi, it is dynamic, and follow
the principle of applying first, distributing first. And
the irq number is alloced from small to large, but the
applying gsi number is not, may gsi 38 comes before gsi
28, that causes t
If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
a passthrough device by using gsi, see
xen_pt_realize->xc_physdev_map_pirq and
pci_add_dm_done->xc_physdev_map_pirq. Then xc_physdev_map_pirq
will call into Xen, but in hvm_physdev_op, PHYSDEVOP_map_pirq
is not allowed because currd is
When a device has been reset on dom0 side, the vpci on Xen
side won't get notification, so the cached state in vpci is
all out of date compare with the real device state.
To solve that problem, add a new hypercall to clear all vpci
device state. When the state of device is reset on dom0 side,
dom0
Hi All,
This is v5 series to support passthrough when dom0 is PVH
v4->v5 changes:
* patch#1: add pci_lock wrap function vpci_reset_device_state
* patch#2: move the check of self map_pirq to physdev.c, and change to check if
the caller has PIRQ flag, and just break for PHYSDEVOP_(un)map_pirq in
hv
flight 184328 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184328/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2bce85bd862e54cede2b59b48972c9f05e2e733d
baseline version:
ovmf 58355ec1926563efc9548
flight 184319 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184319/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-installfail pass in 184311
Tests which did not succeed, but
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
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
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
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
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
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
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
... 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
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
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
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
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
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
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 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
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
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
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
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 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: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: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 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
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 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
>
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 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 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 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 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 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 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 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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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: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
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
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
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 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 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_
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
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:
> 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
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 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.]
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 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
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: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
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 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
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 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
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 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: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
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 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
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 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.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 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/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
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
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-
1 - 100 of 112 matches
Mail list logo
