On Thu, 27 Jun 2024 08:02:51 +0200
"h...@lst.de" wrote:
> On Wed, Jun 26, 2024 at 11:58:13PM +, Michael Kelley wrote:
> > > This patch trades off making many of the core swiotlb APIs take
> > > an additional argument in order to avoid duplicating calls to
> > > swiotlb_find_pool(). The curren
Hi Georges,
> On 26 Jun 2024, at 17:19, George Dunlap wrote:
>
> Remain a Reviewer on the golang bindings and scheduler for now (using
> a xenproject.org alias), since there may be architectural decisions I
> can shed light on.
>
> Remove the XENTRACE section entirely, as there's no obvious can
On Wed, Jun 26, 2024 at 11:58:13PM +, Michael Kelley wrote:
> > This patch trades off making many of the core swiotlb APIs take
> > an additional argument in order to avoid duplicating calls to
> > swiotlb_find_pool(). The current code seems rather wasteful in
> > making 6 calls per round-trip,
On 26.06.24 17:19, George Dunlap wrote:
Remain a Reviewer on the golang bindings and scheduler for now (using
a xenproject.org alias), since there may be architectural decisions I
can shed light on.
Remove the XENTRACE section entirely, as there's no obvious candidate
to take it over; having the
On 26.06.24 18:47, Lonnie Cumberland wrote:
Hello All,
I hope that everyone is doing well today.
Currently, I am investigating and researching the ideas of "Disaggregating" Dom0
and have the Xoar Xen patches ("Breaking Up is Hard to Do: Security and
Functionality in a Commodity Hypervisor" 20
On Thu, Jun 27, 2024 at 10:35:38AM +0800, Oliver Sang wrote:
>
> I failed to apply patch in your previous reply to 1122c0c1cc or current tip
> of axboe-block/for-next:
> c1440ed442a58 (axboe-block/for-next) Merge branch 'for-6.11/block' into
> for-next
That already includes it.
>
> but it's ok
flight 186517 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186517/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186510
test-amd64-amd64-xl-qemut-win7-amd64
hi, Christoph Hellwig,
On Tue, Jun 25, 2024 at 08:39:50PM -0700, Christoph Hellwig wrote:
> On Wed, Jun 26, 2024 at 10:10:49AM +0800, Oliver Sang wrote:
> > I'm not sure I understand this test request. as in title, we see a good
> > improvement of aim7 for 1122c0c1cc, and we didn't observe other i
On Wed, 26 Jun 2024, Stefano Stabellini wrote:
> So, after thinking about it and also talking to the safety manager, I
> think we should:
> - implement ASSERT_UNREACHABLE with a warning in release builds
> - have "return -EPERM;" or similar for defensive programming
Federico, as Jan agrees already
On Wed, 26 Jun 2024, Jan Beulich wrote:
> On 26.06.2024 03:11, Stefano Stabellini wrote:
> > On Tue, 25 Jun 2024, Jan Beulich wrote:
> >> On 25.06.2024 02:54, Stefano Stabellini wrote:
> >>> On Mon, 24 Jun 2024, Federico Serafini wrote:
> Add break or pseudo keyword fallthrough to address viol
On Wed, 26 Jun 2024, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-06-25 at 08:39 +0200, Jan Beulich wrote:
> > On 25.06.2024 02:47, Stefano Stabellini wrote:
> > > I would like to ask for a release-ack as the patch series makes
> > > very few
> > > changes outside of the static analysis configu
On Wed, 26 Jun 2024, Nicola Vetrini wrote:
> From: Alessandro Zucchelli
>
> This addresses violations of MISRA C:2012 Rule 5.3 which states as
> following: An identifier declared in an inner scope shall not hide an
> identifier declared in an outer scope.
>
> In this case the gloabl variable bei
On Wed, 26 Jun 2024, Federico Serafini wrote:
> Add pseudo keyword fallthrough to meet the requirements to deviate
> a violation of MISRA C Rule 16.3 ("An unconditional `break'
> statement shall terminate every switch-clause").
>
> No functional change.
>
> Signed-off-by: Federico Serafini
Revi
On Wed, 26 Jun 2024, Federico Serafini wrote:
> MISRA C Rule 16.3 states that "An unconditional `break' statement shall
> terminate every switch-clause".
>
> Add pseudo keyword fallthrough or missing break statement
> to address violations of the rule.
>
> As a defensive measure, return -EOPNOTSU
On Wed, 26 Jun 2024, Federico Serafini wrote:
> Add break or pseudo keyword fallthrough to address violations of
> MISRA C Rule 16.3: "An unconditional `break' statement shall terminate
> every switch-clause".
>
> No functional change.
>
> Signed-off-by: Federico Serafini
> ---
> Changes in v3:
On Wed, 26 Jun 2024, Federico Serafini wrote:
> Add missing break statements to address violations of MISRA C Rule
> 16.3: "An unconditional `break' statement shall terminate every
> switch-clause".
>
> No functional change.
>
> Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
On Wed, 26 Jun 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe
On Wed, 26 Jun 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses".
>
> The helper macro bitmap_switch has parameters that cannot be parenthesized
> in order to comply with the rule, as that would
On Wed, 26 Jun 2024, Federico Serafini wrote:
> Update ECLAIR configuration to take into account the deviations
> agreed during the MISRA meetings.
>
> While doing this, remove the obsolete "Set [123]" comments.
>
> Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
release-ack
On Wed, 26 Jun 2024, Federico Serafini wrote:
> On 26/06/24 09:37, Oleksii wrote:
> > On Tue, 2024-06-25 at 18:59 -0700, Stefano Stabellini wrote:
> > > > +-doc_begin="The conversion from a function pointer to unsigned
> > > > long or (void *) does not lose any information, provided that the
> > >
From: mhkelle...@gmail.com Sent: Thursday, June 6, 2024
8:14 PM
>
> With CONFIG_SWIOTLB_DYNAMIC enabled, each round-trip map/unmap pair
> in the swiotlb results in 6 calls to swiotlb_find_pool(). In multiple
> places, the pool is found and used in one function, and then must
> found again in the
On Wed, 26 Jun 2024, Julien Grall wrote:
> Hi Michal,
>
> On 26/06/2024 09:04, Michal Orzel wrote:
> > Memory node probing is done as part of early_scan_node() that is called
> > for each node with depth >= 1 (root node is at depth 0). According to
> > Devicetree Specification v0.4, chapter 3.4, /
flight 186515 xen-4.17-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186515/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 186135
test-armhf-armhf-libvirt 16
flight 186523 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186523/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 186520 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186520/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ae09721a65ab3294439f6fa233adaf3b897f702f
baseline version:
ovmf 89377ece8f1c7243d25fd
flight 186514 xen-4.18-testing real [real]
flight 186524 xen-4.18-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186514/
http://logs.test-lab.xenproject.org/osstest/logs/186524/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
On 26/06/2024 1:03 pm, Jan Beulich wrote:
> On 25.06.2024 21:07, Andrew Cooper wrote:
>> --- a/xen/include/xen/bitops.h
>> +++ b/xen/include/xen/bitops.h
>> @@ -56,6 +56,16 @@ static always_inline __pure unsigned int ffs64(uint64_t x)
>> return !x || (uint32_t)x ? ffs(x) : ffs(x >> 32) + 3
On 20/06/2024 9:39 am, Jan Beulich wrote:
> On 19.06.2024 21:10, Andrew Cooper wrote:
>> --- a/docs/misc/xen-command-line.pandoc
>> +++ b/docs/misc/xen-command-line.pandoc
>> @@ -2390,7 +2390,7 @@ By default SSBD will be mitigated at runtime (i.e
>> `ssbd=runtime`).
>> > {ibrs,ibpb,s
Hi Michal,
On 26/06/2024 09:04, Michal Orzel wrote:
Memory node probing is done as part of early_scan_node() that is called
for each node with depth >= 1 (root node is at depth 0). According to
Devicetree Specification v0.4, chapter 3.4, /memory node can only exists
as a top level node. However,
On Wed, 26 Jun 2024, George Dunlap wrote:
> Remain a Reviewer on the golang bindings and scheduler for now (using
> a xenproject.org alias), since there may be architectural decisions I
> can shed light on.
>
> Remove the XENTRACE section entirely, as there's no obvious candidate
> to take it over
flight 186518 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186518/
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
On 26/06/2024 11:24 am, Jan Beulich wrote:
> On 25.06.2024 21:07, Andrew Cooper wrote:
>> In all 3 examples, we're iterating over a scaler. No caller can pass the
>> COMPRESSED flag in, so the upper bound of 63, as opposed to 64, doesn't
>> matter.
> Not sure, maybe more a language question (for m
flight 186519 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186519/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 6 kernel-build fail REGR. vs. 186516
build-amd64-xsm
On Tue, 2024-06-25 at 08:39 +0200, Jan Beulich wrote:
> On 25.06.2024 02:47, Stefano Stabellini wrote:
> > I would like to ask for a release-ack as the patch series makes
> > very few
> > changes outside of the static analysis configuration. The few
> > changes to
> > the Xen code are very limited,
On Wed, 2024-06-26 at 09:53 +0200, Jan Beulich wrote:
> On 25.06.2024 23:10, Andrew Cooper wrote:
> > On 25/06/2024 3:49 pm, Jan Beulich wrote:
> > > On 25.06.2024 15:51, Oleksii Kurochko wrote:
> > > > --- a/xen/arch/riscv/include/asm/cmpxchg.h
> > > > +++ b/xen/arch/riscv/include/asm/cmpxchg.h
>
On Wed, 2024-06-26 at 10:31 +0200, Jan Beulich wrote:
> On 25.06.2024 15:51, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/bitops.h
> > @@ -0,0 +1,137 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/* Copyright (C) 2012 Regents of the University of California *
On Wed Jun 26, 2024 at 5:43 PM BST, Andrew Cooper wrote:
> On 26/06/2024 5:28 pm, Alejandro Vallejo wrote:
> > hvmloader's cpuid() implementation deviates from Xen's in that the value
> > passed
> > on ecx is unspecified. This means that when used on leaves that implement
> > subleaves it's unspec
Hello All,
I hope that everyone is doing well today.
Currently, I am investigating and researching the ideas of
"Disaggregating" Dom0 and have the Xoar Xen patches ("Breaking Up is
Hard to Do: Security and Functionality in a Commodity Hypervisor" 2011)
available which were developed against v
On 6/11/2024 4:54 PM, Jeff Johnson wrote:
> With ARCH=x86, make allmodconfig && make W=1 C=1 reports:
> WARNING: modpost: missing MODULE_DESCRIPTION() in
> drivers/xen/xen-pciback/xen-pciback.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/xen/xen-evtchn.o
> WARNING: modpost: missing
On 26/06/2024 5:28 pm, Alejandro Vallejo wrote:
> hvmloader's cpuid() implementation deviates from Xen's in that the value
> passed
> on ecx is unspecified. This means that when used on leaves that implement
> subleaves it's unspecified which one you get; though it's more than likely an
> invalid
On Wed Jun 26, 2024 at 4:17 PM BST, Jan Beulich wrote:
> On 26.06.2024 15:54, Alejandro Vallejo wrote:
> > I'm late to the party but there's something bothering me a little.
> >
> > On Tue Jan 16, 2024 at 7:25 PM GMT, Elias El Yandouzi wrote:
> >> diff --git a/xen/common/vmap.c b/xen/common/vmap.c
Have toolstack populate the new x2APIC ID in the LAPIC save record with the
proper IDs intended for each vCPU.
Signed-off-by: Alejandro Vallejo
---
v4:
* New patch. Replaced v3's method of letting Xen find out via the same
algorithm toolstack uses.
---
tools/libs/guest/xg_dom_x86.c | 37 ++
While doing this, factor out checks common to architectural and hidden state.
Signed-off-by: Alejandro Vallejo
Reviewed-by: Roger Pau Monné
---
This puts essential LAPIC information in the stream. It's technically a feature
but it makes 4.19 guests a lot more future-proof. I think this should go
This greatly simplifies a later patch that makes use of HVM contexts to upload
LAPIC data. The idea is to reuse MTRR setting procedure to avoid code
duplication. It's currently only used for PVH, but there's no real reason to
overcomplicate the toolstack preventing them being set for HVM too when
h
Implements the helper for mapping vcpu_id to x2apic_id given a valid
topology in a policy. The algo is written with the intention of extending
it to leaves 0x1f and extended 0x26 in the future.
Toolstack doesn't set leaf 0xb and the HVM default policy has it cleared,
so the leaf is not implemented
I've added the patches most critical to get into 4.19 at the head. They are
pretty well reviewed already and shouldn't be very contentious anymore.
v3 -> v4:
* Fixed cpuid() bug in hvmloader, causing UB in v3
* Fixed a bogus assert in hvmloader, also causing a crash in v3
* Used HVM contexts
This patch is a precondition for a later patch in which toolstack uses HVM
contexts to upload LAPIC data to a newly constructed domain.
If toolstack were to upload LAPIC contexts as part of domain creation as-is it
would encounter a problem were the architectural state does not reflect the APIC
ID
This allows the initial x2APIC ID to be sent on the migration stream. This
allows further changes to topology and APIC ID assignment without breaking
existing hosts. Given the vlapic data is zero-extended on restore, fix up
migrations from hosts without the field by setting it to the old convention
Expose sensible topologies in leaf 0xb. At the moment it synthesises non-HT
systems, in line with the previous code intent.
Leaf 0xb in the host policy is no longer zapped and the guest {max,def} policies
have their topology leaves zapped instead. The intent is for toolstack to
populate them. Ther
Add a helper to populate topology leaves in the cpu policy from
threads/core and cores/package counts. It's unit-tested in test-cpu-policy.c,
but it's not connected to the rest of the code yet.
Adds the ASSERT() macro to xen/lib/x86/private.h, as it was missing.
Signed-off-by: Alejandro Vallejo
hvmloader's cpuid() implementation deviates from Xen's in that the value passed
on ecx is unspecified. This means that when used on leaves that implement
subleaves it's unspecified which one you get; though it's more than likely an
invalid one.
Import Xen's implementation so there are no surprises
Make it so the APs expose their own APIC IDs in a LUT. We can use that LUT to
populate the MADT, decoupling the algorithm that relates CPU IDs and APIC IDs
from hvmloader.
While at this also remove ap_callin, as writing the APIC ID may serve the same
purpose.
Signed-off-by: Alejandro Vallejo
---
flight 186516 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186516/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 89377ece8f1c7243d25fd84488dcd03e37b9e661
baseline version:
ovmf dc002d4f2d76bdd826359
Remain a Reviewer on the golang bindings and scheduler for now (using
a xenproject.org alias), since there may be architectural decisions I
can shed light on.
Remove the XENTRACE section entirely, as there's no obvious candidate
to take it over; having the respective parts fall back to the tools
a
forgot to add that this patch series is rebased on top of staging
Teddy
Teddy Astie | Vates XCP-ng Intern
XCP-ng & Xen Orchestra - Vates solutions
web: https://vates.tech
On 26.06.2024 15:54, Alejandro Vallejo wrote:
> I'm late to the party but there's something bothering me a little.
>
> On Tue Jan 16, 2024 at 7:25 PM GMT, Elias El Yandouzi wrote:
>> diff --git a/xen/common/vmap.c b/xen/common/vmap.c
>> index 171271fae3..966a7e763f 100644
>> --- a/xen/common/vmap.
From: Teddy Astie
Based on docs/designs/iommu-contexts.md, implement the redesigned IOMMU
subsystem.
Signed-off-by Teddy Astie
---
Changed in V2:
* cleanup some unneeded includes
* fix dangling devices in context on detach
---
xen/arch/x86/domain.c| 2 +-
xen/arch/x86/mm/p2m
From: Teddy Astie
Port the driver with guidances specified in iommu-contexts.md.
Add a arena-based allocator for allocating a fixed chunk of memory and
split it into 4k pages for use by the IOMMU contexts. This chunk size
is configurable with X86_ARENA_ORDER and dom0-iommu=arena-order=N.
Signed
From: Teddy Astie
Current IOMMU subsystem has some limitations that make PV-IOMMU practically
impossible.
One of them is the assumtion that each domain is bound to a single "IOMMU
domain", which
also causes complications with quarantine implementation.
Moreover, current IOMMU subsystem is not
This work has been presented at Xen Summit 2024 during the
IOMMU paravirtualization and Xen IOMMU subsystem rework
design session.
Operating systems may want to have access to a IOMMU in order to do DMA
protection or implement certain features (e.g VFIO on Linux).
VFIO support is mandatory for
From: Teddy Astie
Introduce a new pv interface to manage the underlying IOMMU and manage contexts
and devices. This interface allows creation of new contexts from Dom0 and
addition of IOMMU mappings using guest PoV.
This interface doesn't allow creation of mapping to other domains.
Signed-off-b
From: Teddy Astie
Some operating systems want to use IOMMU to implement various features (e.g
VFIO) or DMA protection.
This patch introduce a proposal for IOMMU paravirtualization for Dom0.
Signed-off-by Teddy Astie
---
docs/designs/pv-iommu.md | 105 +++
1
Hi Tamas,
On 26/06/2024 14:20, Tamas K Lengyel wrote:
On Wed, Jun 26, 2024 at 8:41 AM Julien Grall wrote:
Hi Tamas,
On 24/06/2024 23:18, Tamas K Lengyel wrote:
On Mon, Jun 24, 2024 at 5:58 PM Julien Grall wrote:
Hi,
On 21/06/2024 20:14, Tamas K Lengyel wrote:
The build integration scri
Hi Michal,
> On 26 Jun 2024, at 09:04, Michal Orzel wrote:
>
> Memory node probing is done as part of early_scan_node() that is called
> for each node with depth >= 1 (root node is at depth 0). According to
> Devicetree Specification v0.4, chapter 3.4, /memory node can only exists
> as a top lev
flight 186513 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186513/
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
On 2024-06-26 15:38, Anthony PERARD wrote:
On Wed, Jun 26, 2024 at 12:31:42PM +0200, Jan Beulich wrote:
On 26.06.2024 12:25, Nicola Vetrini wrote:
> On 2024-06-26 11:26, Jan Beulich wrote:
>> On 26.06.2024 11:20, Nicola Vetrini wrote:
>>> On 2024-06-26 11:06, Jan Beulich wrote:
On 25.06.202
On Tue, Jun 25, 2024 at 10:02:42PM +0100, Andrew Cooper wrote:
> On 03/06/2024 3:59 pm, Matthew Barnes wrote:
> > xen-hvmcrash would previously save records, overwrite the instruction
> > pointer with a bogus value, and then restore them to crash a domain
> > just enough to cause the guest OS to me
On Wed, Jun 26, 2024 at 2:57 PM George Dunlap wrote:
>
> This is my work-in-progress series for getting nested virt working
> again on AMD.
Forgot to add, this can be found at this branch:
https://gitlab.com/xen-project/people/gdunlap/xen/-/commits/working/amd-nested-virt
-George
There are already "HVM handler" trace records for writing to XCRs in
the context of an HVM guest. This trace is currently taken in
hvmemul_write_xcr.
However, both VMX and SVM vmexits call hvm_handle_xsetbv as a result
of an XSETBV vmexit, and hvm_handle_xsetbv calls x86emul_write_xcr
directly, b
Unfortunately I've forgotten exactly why I made this change. I
suspect that there were other traces (like MMIO traces) which were
being put before the NPF trace; but to understand the trace record
you'd want to have the NPF information first.
Signed-off-by: George Dunlap
---
xen/arch/x86/hvm/sv
Signed-off-by: George Dunlap
---
xen/arch/x86/hvm/svm/nestedsvm.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index 35a2cbfd7d..dca06f2a6c 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hv
Basically this means adding VMEXIT strings for XSETBV exit, and adding
the handlers and strings for them.
Signed-off-by: George Dunlap
---
tools/xentrace/xenalyze.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
Adding an HVM_TRAP trace record is redundant for EXCEPTION_AC: it adds
trace volume without adding any information, and xenalyze already
knows not to expect it. Remove it.
Signed-off-by: George Dunlap
---
xen/arch/x86/hvm/svm/svm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/arch/x86
This is my work-in-progress series for getting nested virt working
again on AMD.
The first patch is an early draft to integrate the SVM bits into the
CPUID framework. It will be partially superseded by a series Andrew
has posted but which has not yet been checked in.
The second patch is a workar
Note that this trace is SVM-specific. Most HVM handler traces are
shared between VMX and SVM because the underlying instruction set is
largely the equivalent; but in this case, the instructions are
different enough that there's no sensible way to share HVM handler
traces between them.
Keeping the
VMX combines all exceptions into a single VMEXIT exit reason, and so
needs a separate HVM_HANDLER trace record (HVM_TRAP) to say which
exception happened; but for a number of exceptions, no further
information is put into the trace log.
SVM, by contrast, has a separate VMEXIT exit reason for each
There's a general issue with both PIO and MMIO reads (as detailed in
the comment); do a work-around for now.
Signed-off-by: George Dunlap
---
tools/xentrace/xenalyze.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
in
The non-nested HVM code knows how to provide PCID functionality
(non-zero values in the lower 12 bits of CR3 when running in 64-bit
mode), but the nested code doesn't. If the L2 decides to use the PCID
functionality, the L0 will fail the next L1 VMENTRY.
Long term we definitely want to enable thi
hvmemul_read_cr ends up being called fairly freqently during
emulation; these are generally not necessary for understanding a
trace, and make processing more complicated (because they show up as
extra trace records within a vmexit/entry "arc" that must be
classified).
Leave the trace in write_cr,
Commit 37f074a3383 ("x86/msr: introduce guest_rdmsr()") introduced a
function to combine the MSR_READ handling between PV and HVM.
Unfortunately, by returning directly, it skipped the trace generation,
leading to gaps in the trace record, as well as xenalyze errors like
this:
hvm_generic_postproce
On SVM, VMEXIT that occur in when an L1 is in non-root mode ("nested
exits") are tagged with the TRC_HVM_NESTEDFLAG flag. Expand xenalyze
to do basic handling of these records:
- Refactor hvm_process to filter out both TRC_HVM_NESTEDFLAG and
TRC_64_FLAG when deciding how to process
- Create se
Generally speaking, a VMEXIT/VMENTRY cycle should have at least three
trace records: the VMEXIT trace (which contains the processor-specific
exit code), a more generic Xen-based Xen event (an HVM_HANDLER trace
record), and a VMEXIT trace; and any given VMEXIT exit reason should
only have a single H
NOTE: This patch is be partially superseded by Andrew Cooper's "x86:
AMD CPUID handling improvements" series.
Currently, the CPUID leaf for SVM features (extd 0xa.edx) is manually
twiddled:
- hvm_max_policy takes host_policy and clamps it to supported
features (with some features unilaterally
I'm late to the party but there's something bothering me a little.
On Tue Jan 16, 2024 at 7:25 PM GMT, Elias El Yandouzi wrote:
> diff --git a/xen/common/vmap.c b/xen/common/vmap.c
> index 171271fae3..966a7e763f 100644
> --- a/xen/common/vmap.c
> +++ b/xen/common/vmap.c
> @@ -245,6 +245,11 @@ void
flight 186510 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186510/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186499
test-amd64-amd64-xl-qemut-win7-amd64
Hello Robin,
Le 26/06/2024 à 14:09, Robin Murphy a écrit :
> On 2024-06-24 3:36 pm, Teddy Astie wrote:
>> Hello Robin,
>> Thanks for the thourough review.
>>
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 0af39bbbe3a3..242cefac77c9 100644
--- a/drivers/iommu/Kconfi
Hi all,
Our next community call is on 4th July 2024. As this is a national holiday
in the US, I propose we move our call to the same time on *11th July 2024*
if there are no objections.
Details and agenda links will be sent that week.
Many thanks,
Kelly Choi
Community Manager
Xen Project
On Wed, Jun 26, 2024 at 12:31:42PM +0200, Jan Beulich wrote:
> On 26.06.2024 12:25, Nicola Vetrini wrote:
> > On 2024-06-26 11:26, Jan Beulich wrote:
> >> On 26.06.2024 11:20, Nicola Vetrini wrote:
> >>> On 2024-06-26 11:06, Jan Beulich wrote:
> On 25.06.2024 21:31, Nicola Vetrini wrote:
> >>>
On 2024-06-26 15:28, Nicola Vetrini wrote:
Hi all,
this series addresses several violations of Rule 20.7, as well as a
small fix to the ECLAIR integration scripts that do not influence
the current behaviour, but were mistakenly part of the upstream
configuration.
Note that by applying this seri
Hi all,
this series addresses several violations of Rule 20.7, as well as a
small fix to the ECLAIR integration scripts that do not influence
the current behaviour, but were mistakenly part of the upstream
configuration.
Note that by applying this series the rule has a few leftover violations.
Mo
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses".
The local helpers GRP2 and XADD in the x86 emulator use their first
argument as the constant expression for a case label. This pattern
is deviated project-wide, because it is
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
Remove from the ECLAIR integration scripts an unused option, which
was already ignored, and make the help texts consistent
with the rest of the scripts.
No functional change.
Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
---
automation/eclair_analysis/ECLAIR/analyze.sh | 3 +--
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses".
The helper macro bitmap_switch has parameters that cannot be parenthesized
in order to comply with the rule, as that would break its functionality.
Moreover, the risk of misus
On Wed, Jun 26, 2024 at 8:41 AM Julien Grall wrote:
>
> Hi Tamas,
>
> On 24/06/2024 23:18, Tamas K Lengyel wrote:
> > On Mon, Jun 24, 2024 at 5:58 PM Julien Grall wrote:
> >>
> >> Hi,
> >>
> >> On 21/06/2024 20:14, Tamas K Lengyel wrote:
> >>> The build integration script for oss-fuzz targets.
>
On 26.06.2024 15:04, Andrew Cooper wrote:
> One final thing.
>
> This logic here depends on interrupts not being enabled between these
> atomic actions, and entering non-root mode.
>
> Specifically, Xen must not service a pending delivery-notification
> vector between this point and the VMEntry m
On 26/06/2024 1:54 pm, Andrew Cooper wrote:
> On 26/06/2024 10:49 am, Jan Beulich wrote:
>> On 25.06.2024 21:07, Andrew Cooper wrote:
>>> There are two issues. First, pi_test_and_clear_on() pulls the cache-line to
>>> the CPU and dirties it even if there's nothing outstanding, but the final
>>> fo
1 - 100 of 152 matches
Mail list logo
