flight 186105 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186105/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 186078
Tests which did
On Fri, 24 May 2024, Julien Grall wrote:
> Hi Henry,
>
> On 23/05/2024 08:40, Henry Wang wrote:
> > Currently, the number of SPIs allocated to the domain is only
> > configurable for Dom0less DomUs. Xen domains are supposed to be
> > platform agnostics and therefore the numbers of SPIs for libxl
On Thu, 23 May 2024, Julien Grall wrote:
> Hi Henry,
>
> On 23/05/2024 08:40, Henry Wang wrote:
> > In order to support the dynamic dtbo device assignment to a running
> > VM, the add/remove of the DT overlay and the attach/detach of the
> > device from the DT overlay should happen separately.
On Thu, 23 May 2024, Julien Grall wrote:
> Hi Henry,
>
> On 23/05/2024 08:40, Henry Wang wrote:
> > From: Vikram Garhwal
> >
> > Signed-off-by: Vikram Garhwal
> > Signed-off-by: Stefano Stabellini
> > Signed-off-by: Henry Wang
> > ---
> > v4:
> > - No change.
> > v3:
> > - No change.
> > v2:
On Fri, 24 May 2024, Julien Grall wrote:
> Hi Henry,
>
> On 23/05/2024 08:40, Henry Wang wrote:
> > With the XEN_DOMCTL_dt_overlay DOMCTL added, users should be able to
> > attach/detach devices from the provided DT overlay to domains.
> > Support this by introducing a new set of "xl dt-overlay"
From: Vikram Garhwal
Signed-off-by: Vikram Garhwal
Signed-off-by: Stefano Stabellini
Signed-off-by: Henry Wang
---
docs/misc/arm/overlay.txt | 82 +++
1 file changed, 82 insertions(+)
create mode 100644 docs/misc/arm/overlay.txt
diff --git
From: Henry Wang
Fix the name mismatch in the xl dt-overlay command, the
command name should be "dt-overlay" instead of "dt_overlay".
Add the missing "," in the cmdtable.
Fix the exit code of the dt-overlay command, use EXIT_FAILURE
instead of ERROR_FAIL.
Fixes: 61765a07e3d8 ("tools/xl: Add
From: Henry Wang
In order to support the dynamic dtbo device assignment to a running
VM, the add/remove of the DT overlay and the attach/detach of the
device from the DT overlay should happen separately. Therefore,
repurpose the existing XEN_SYSCTL_dt_overlay to only add the DT
overlay to Xen
From: Henry Wang
Currently, adding physical interrupts are only allowed at
the domain creation time. For use cases such as dynamic device
tree overlay addition, the adding of physical IRQ to
running domains should be allowed.
Drop the above-mentioned domain creation check. Since this
will
From: Henry Wang
With the XEN_DOMCTL_dt_overlay DOMCTL added, users should be able to
attach (in the future also detach) devices from the provided DT overlay
to domains. Support this by introducing a new "xl dt-overlay" command
and related documentation, i.e. "xl dt-overlay attach. Slightly
From: Henry Wang
Currently, the number of SPIs allocated to the domain is only
configurable for Dom0less DomUs. Xen domains are supposed to be
platform agnostics and therefore the numbers of SPIs for libxl
guests should not be based on the hardware.
Introduce a new xl config entry for Arm to
From: Henry Wang
There are some use cases in which the dom0less domUs need to have
the XEN_DOMCTL_CDF_iommu set at the domain construction time. For
example, the dynamic dtbo feature allows the domain to be assigned
a device that is behind the IOMMU at runtime. For these use cases,
we need to
Hi all,
This is the remaining series for the full functional "dynamic node
programming using overlay dtbo" feature. The first part [1] has
already been merged.
Quoting from the original series, the first part has already made
Xen aware of new device tree node which means updating the dt_host
On Thu, 23 May 2024, Henry Wang wrote:
> Fix the name mismatch in the xl dt-overlay command, the
> command name should be "dt-overlay" instead of "dt_overlay".
> Add the missing "," in the cmdtable.
>
> Fix the exit code of the dt-overlay command, use EXIT_FAILURE
> instead of ERROR_FAIL.
>
>
flight 186109 xen-4.17-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186109/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 185864
build-amd64
On Thu, 23 May 2024, Jan Beulich wrote:
> On 23.05.2024 15:07, Sergiy Kibrik wrote:
> > 16.05.24 14:12, Jan Beulich:
> >> On 15.05.2024 11:12, Sergiy Kibrik wrote:
> >>> --- a/xen/arch/x86/include/asm/cpufeature.h
> >>> +++ b/xen/arch/x86/include/asm/cpufeature.h
> >>> @@ -81,7 +81,8 @@ static
Hi Henry,
On 23/05/2024 08:40, Henry Wang wrote:
With the XEN_DOMCTL_dt_overlay DOMCTL added, users should be able to
attach/detach devices from the provided DT overlay to domains.
Support this by introducing a new set of "xl dt-overlay" commands and
related documentation, i.e. "xl dt-overlay
Hi Henry,
On 23/05/2024 08:40, Henry Wang wrote:
Currently, the number of SPIs allocated to the domain is only
configurable for Dom0less DomUs. Xen domains are supposed to be
platform agnostics and therefore the numbers of SPIs for libxl
guests should not be based on the hardware.
Introduce a
flight 186103 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186103/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 186052
build-amd64
Hi Henry,
On 23/05/2024 08:40, Henry Wang wrote:
From: Vikram Garhwal
Signed-off-by: Vikram Garhwal
Signed-off-by: Stefano Stabellini
Signed-off-by: Henry Wang
---
v4:
- No change.
v3:
- No change.
v2:
- Update the content based on the changes in this version.
---
Hi Henry,
On 23/05/2024 08:40, Henry Wang wrote:
Similarly as the device attachment from DT overlay to domain, this
commit implements the device detachment from domain. The DOMCTL
XEN_DOMCTL_dt_overlay op is extended to have the operation
XEN_DOMCTL_DT_OVERLAY_DETACH. The detachment of the
Hi Henry,
On 23/05/2024 08:40, Henry Wang wrote:
In order to support the dynamic dtbo device assignment to a running
VM, the add/remove of the DT overlay and the attach/detach of the
device from the DT overlay should happen separately. Therefore,
repurpose the existing XEN_SYSCTL_dt_overlay to
On 23/05/2024 08:40, Henry Wang wrote:
Hi all,
Hi Henry,
This is the remaining series for the full functional "dynamic node
programming using overlay dtbo" feature. The first part [1] has
already been merged.
Quoting from the original series, the first part has already made
Xen aware of
Hi Henry,
On 23/05/2024 08:40, Henry Wang wrote:
Currently, adding physical interrupts are only allowed at
the domain creation time. For use cases such as dynamic device
tree overlay addition, the adding of physical IRQ to
running domains should be allowed.
Drop the above-mentioned domain
Hi Henry,
On 23/05/2024 08:40, Henry Wang wrote:
There are some use cases in which the dom0less domUs need to have
the XEN_DOMCTL_CDF_iommu set at the domain construction time. For
example, the dynamic dtbo feature allows the domain to be assigned
a device that is behind the IOMMU at runtime.
flight 186117 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186117/
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
flight 186099 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186099/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 186070
build-amd64
On 08/05/2024 1:39 pm, Alejandro Vallejo wrote:
> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
> index 8a24419c..2f06bff1b2cc 100644
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -1573,35 +1573,54 @@ static void lapic_load_fixup(struct vlapic
On Thu, 23 May 2024, Edgar E. Iglesias wrote:
> On Thu, May 23, 2024 at 9:47 AM Manos Pitsidianakis
> wrote:
> On Thu, 16 May 2024 18:48, "Edgar E. Iglesias"
> wrote:
> >From: "Edgar E. Iglesias"
> >
> >Add a second mapcache for grant mappings. The mapcache for
>
On Thu, 23 May 2024, Roger Pau Monné wrote:
> On Fri, May 17, 2024 at 03:33:51PM +0200, Roger Pau Monne wrote:
> > Enabling it using an HVM param is fragile, and complicates the logic when
> > deciding whether options that interact with altp2m can also be enabled.
> >
> > Leave the HVM param
From: "Edgar E. Iglesias"
I was scanning for code that we could potentially move from the
.text section into .init.text and found a few candidates.
I'm not sure if this makes sense, perhaps we don't want to mark
these functions for other reasons but my scripts found this chain
of SMMUv3 init
From: "Edgar E. Iglesias"
Move more functions that are only called at init to
the .init.text section.
Signed-off-by: Edgar E. Iglesias
---
xen/drivers/passthrough/arm/smmu-v3.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git
On Wed, May 08, 2024 at 01:39:25PM +0100, Alejandro Vallejo wrote:
> Add a helper to populate topology leaves in the cpu policy from
> threads/core and cores/package counts.
>
> No functional change, as it's not connected to anything yet.
There is a functional change in test-cpu-policy.c.
Maybe
On Thu, 2024-05-23 at 15:33 +0100, Julien Grall wrote:
>
>
> On 23/05/2024 15:11, Oleksii K. wrote:
> > On Thu, 2024-05-23 at 14:00 +0100, Julien Grall wrote:
> > > Hi Oleksii,
> > Hi Julien,
> >
> > >
> > > On 17/05/2024 14:54, Oleksii Kurochko wrote:
> > > > diff --git
flight 186108 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186108/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 186064
Tests which
On 23.05.2024 13:16, Andrew Cooper wrote:
> First, if XSAVE is available in hardware but not visible to the guest, the
> dynamic leaves shouldn't be filled in.
>
> Second, the comment concerning XSS state is wrong. VT-x doesn't manage
> host/guest state automatically, but there is provision for
On Wed, May 08, 2024 at 01:39:24PM +0100, Alejandro Vallejo wrote:
> 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
On 23.05.2024 13:16, Andrew Cooper wrote:
> @@ -611,6 +587,40 @@ static bool valid_xcr0(uint64_t xcr0)
> return true;
> }
>
> +unsigned int xstate_uncompressed_size(uint64_t xcr0)
> +{
> +unsigned int size = XSTATE_AREA_MIN_SIZE, i;
> +
> +ASSERT((xcr0 & ~X86_XCR0_STATES) == 0);
On 23.05.2024 13:16, Andrew Cooper wrote:
> With the exception of one case in read_bndcfgu() which can use ilog2(),
> the *_POS defines are unused.
>
> X86_XCR0_X87 is the name used by both the SDM and APM, rather than
> X86_XCR0_FP.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
On 23.05.2024 13:16, Andrew Cooper wrote:
> This is a tangle, but it's a small step in the right direction.
>
> xstate_init() is shortly going to want data from the Raw policy.
> calculate_raw_cpu_policy() is sufficiently separate from the other policies to
> be safe to do.
>
> No functional
Hi all,
The next community call is on Thursday 6th June 2024, which clashes with
Xen Summit in Lisbon.
I propose we move the call a week later to *Thursday 13th June 2024, 4-5pm
(UK time). *
Many thanks,
Kelly Choi
Community Manager
Xen Project
On 23.05.2024 13:16, Andrew Cooper wrote:
> Right now, xstate_ctxt_size() performs a cross-check of size with CPUID in for
> every call. This is expensive, being used for domain create/migrate, as well
> as to service certain guest CPUID instructions.
>
> Instead, arrange to check the sizes once
On 23.05.2024 13:16, Andrew Cooper wrote:
> The clobbering of this_cpu(xcr0) and this_cpu(xss) to architecturally invalid
> values is to force the subsequent set_xcr0() and set_msr_xss() to reload the
> hardware register.
>
> While XCR0 is reloaded in xstate_init(), MSR_XSS isn't. This causes
>
On Thu, May 09, 2024 at 06:50:57PM +0100, Andrew Cooper wrote:
> Now that we're using hypercalls to start APs, we can replace the 'ap_cpuid'
> global with a regular function parameter. This requires telling the compiler
> that we'd like the parameter in a register rather than on the stack.
>
>
On 23/05/2024 3:10 pm, George Dunlap wrote:
> A long-standing usability sub-optimality with xenalyze is the
> necessity to specify `--svm-mode` when analyzing AMD processors. This
> fundamentally comes about because the same trace event ID is used for
> both VMX and SVM, but the contents of the
On 23.05.2024 16:40, osstest service owner wrote:
> flight 186087 xen-4.17-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/186087/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64
On Thu, May 23, 2024 at 04:40:06PM +0200, Jan Beulich wrote:
> On 23.05.2024 16:37, Roger Pau Monné wrote:
> > On Wed, May 08, 2024 at 01:39:21PM +0100, Alejandro Vallejo wrote:
> >> --- a/xen/arch/x86/include/asm/hvm/hvm.h
> >> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
> >> @@ -798,6 +798,12 @@
On Wed, May 08, 2024 at 01:39:22PM +0100, Alejandro Vallejo wrote:
> While at it, add a check for the reserved field in the hidden save area.
>
> Signed-off-by: Alejandro Vallejo
> ---
> v2:
> * New patch. Addresses the missing check for rsvd_zero in v1.
Oh, it would be better if this was
On 23.05.2024 15:07, Sergiy Kibrik wrote:
> 16.05.24 14:12, Jan Beulich:
>> On 15.05.2024 11:12, Sergiy Kibrik wrote:
>>> --- a/xen/arch/x86/include/asm/cpufeature.h
>>> +++ b/xen/arch/x86/include/asm/cpufeature.h
>>> @@ -81,7 +81,8 @@ static inline bool boot_cpu_has(unsigned int feat)
>>>
On 23.05.2024 12:44, Sergiy Kibrik wrote:
> 16.05.24 14:01, Jan Beulich:
>> On 15.05.2024 11:10, Sergiy Kibrik wrote:
>>> --- a/xen/arch/x86/include/asm/hvm/hvm.h
>>> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
>>> @@ -670,7 +670,7 @@ static inline bool hvm_hap_supported(void)
>>> /* returns true
flight 186087 xen-4.17-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186087/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 185864
On 23.05.2024 16:37, Roger Pau Monné wrote:
> On Wed, May 08, 2024 at 01:39:21PM +0100, Alejandro Vallejo wrote:
>> --- a/xen/arch/x86/include/asm/hvm/hvm.h
>> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
>> @@ -798,6 +798,12 @@ static inline void hvm_update_vlapic_mode(struct vcpu
>> *v)
>>
On Wed, May 08, 2024 at 01:39:21PM +0100, Alejandro Vallejo wrote:
> Otherwise it's not possible to call functions described in hvm/vlapic.h from
> the
> inline functions of hvm/hvm.h.
>
> This is because a static inline in vlapic.h depends on hvm.h, and pulls it
> transitively through vpt.h.
On 23.05.2024 15:45, osstest service owner wrote:
> flight 186107 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/186107/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-armhf
On 23/05/2024 15:11, Oleksii K. wrote:
On Thu, 2024-05-23 at 14:00 +0100, Julien Grall wrote:
Hi Oleksii,
Hi Julien,
On 17/05/2024 14:54, Oleksii Kurochko wrote:
diff --git a/xen/arch/arm/arm64/livepatch.c
b/xen/arch/arm/arm64/livepatch.c
index df2cebedde..4bc8ed9be5 100644
---
On Wed, May 08, 2024 at 01:39:20PM +0100, Alejandro Vallejo wrote:
> This allows the initial x2APIC ID to be sent on the migration stream. The
> hardcoded mapping x2apic_id=2*vcpu_id is maintained for the time being.
> Given the vlapic data is zero-extended on restore, fix up migrations from
>
On 23.05.2024 16:22, Marek Marczykowski-Górecki wrote:
> On Wed, May 22, 2024 at 05:39:02PM +0200, Marek Marczykowski-Górecki wrote:
>> On older systems, XHCI xcap had a layout that no other (interesting)
>> registers
>> were placed on the same page as the debug capability, so Linux was fine with
A long-standing usability sub-optimality with xenalyze is the
necessity to specify `--svm-mode` when analyzing AMD processors. This
fundamentally comes about because the same trace event ID is used for
both VMX and SVM, but the contents of the trace must be interpreted
differently.
Instead,
To unify certain common sanity checks, checks are done very early in
processing based only on the top-level type.
Unfortunately, when TRC_HVM_EMUL was introduced, it broke some of the
assumptions about how the top-level types worked. Namely, traces of
this type will show up outside of HVM
On Wed, May 22, 2024 at 05:39:02PM +0200, Marek Marczykowski-Górecki wrote:
> On older systems, XHCI xcap had a layout that no other (interesting) registers
> were placed on the same page as the debug capability, so Linux was fine with
> making the whole page R/O. But at least on Tiger Lake and
On Thu, 2024-05-23 at 14:00 +0100, Julien Grall wrote:
> Hi Oleksii,
Hi Julien,
>
> On 17/05/2024 14:54, Oleksii Kurochko wrote:
> > diff --git a/xen/arch/arm/arm64/livepatch.c
> > b/xen/arch/arm/arm64/livepatch.c
> > index df2cebedde..4bc8ed9be5 100644
> > --- a/xen/arch/arm/arm64/livepatch.c
>
On Thu, May 23, 2024 at 03:59:43PM +0200, Thomas Gleixner wrote:
> On Wed, Apr 10 2024 at 15:48, Jason Andryuk wrote:
> > ---
> > arch/x86/kernel/head_64.S| 22 ++
> > arch/x86/kernel/pgtable_64_helpers.h | 28
>
> That's the wrong
On Wed, Apr 10 2024 at 15:48, Jason Andryuk wrote:
> ---
> arch/x86/kernel/head_64.S| 22 ++
> arch/x86/kernel/pgtable_64_helpers.h | 28
That's the wrong place as you want to include it from arch/x86/platform.
flight 186107 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186107/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 186064
Tests which
Hi,
On 22/05/2024 09:15, Jan Beulich wrote:
On 22.05.2024 09:37, Oleksii K. wrote:
On Tue, 2024-05-21 at 13:18 +0200, Jan Beulich wrote:
On 17.05.2024 15:54, Oleksii Kurochko wrote:
To avoid the compilation error below, it is needed to update to
places
in common/page_alloc.c where flsl() is
16.05.24 14:12, Jan Beulich:
On 15.05.2024 11:12, Sergiy Kibrik wrote:
--- a/xen/arch/x86/include/asm/cpufeature.h
+++ b/xen/arch/x86/include/asm/cpufeature.h
@@ -81,7 +81,8 @@ static inline bool boot_cpu_has(unsigned int feat)
#define cpu_has_sse3boot_cpu_has(X86_FEATURE_SSE3)
Hi Oleksii,
On 17/05/2024 14:54, Oleksii Kurochko wrote:
diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
index df2cebedde..4bc8ed9be5 100644
--- a/xen/arch/arm/arm64/livepatch.c
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -10,7 +10,6 @@
#include
#include
Hi Oleksii,
On 23/05/2024 09:04, Oleksii K. wrote:
On Wed, 2024-05-22 at 21:50 +0100, Julien Grall wrote:
Hi,
Adding Oleksii as the release manager.
On 22/05/2024 19:27, Tamas K Lengyel wrote:
On Fri, May 10, 2024 at 8:32 AM Alessandro Zucchelli
wrote:
In order to comply to MISRA C:2012
On 10.04.24 21:48, Jason Andryuk wrote:
The PVH entry point is 32bit. For a 64bit kernel, the entry point must
switch to 64bit mode, which requires a set of page tables. In the past,
PVH used init_top_pgt.
This works fine when the kernel is loaded at LOAD_PHYSICAL_ADDR, as the
page tables are
Le 23/05/2024 à 11:52, Roger Pau Monné a écrit :
> The #ifdef and #endif processor directives shouldn't be indented.
>
> Would you mind adding /* CONFIG_{AMD,INTEL}_IOMMU */ comments in the
> #endif directives?
>
Sure, will change it for v2.
> I wonder if we could move the definitions of those
On 10.04.24 21:48, Jason Andryuk wrote:
The PVH entry point will need an additional set of prebuild page tables.
Move the macros and defines to a new header so they can be re-used.
Signed-off-by: Jason Andryuk
With the one nit below addressed:
Reviewed-by: Juergen Gross
...
diff --git
On Fri, May 17, 2024 at 03:33:51PM +0200, Roger Pau Monne wrote:
> Enabling it using an HVM param is fragile, and complicates the logic when
> deciding whether options that interact with altp2m can also be enabled.
>
> Leave the HVM param value for consumption by the guest, but prevent it from
>
With the exception of one case in read_bndcfgu() which can use ilog2(),
the *_POS defines are unused.
X86_XCR0_X87 is the name used by both the SDM and APM, rather than
X86_XCR0_FP.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
v3:
* New
---
This is a tangle, but it's a small step in the right direction.
xstate_init() is shortly going to want data from the Raw policy.
calculate_raw_cpu_policy() is sufficiently separate from the other policies to
be safe to do.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
Make use of xstate_uncompressed_size() helper rather than maintaining the
running calculation while accumulating feature components.
The rest of the CPUID data can come direct from the raw cpu policy. All
per-component data form an ABI through the behaviour of the X{SAVE,RSTOR}*
instructions.
The clobbering of this_cpu(xcr0) and this_cpu(xss) to architecturally invalid
values is to force the subsequent set_xcr0() and set_msr_xss() to reload the
hardware register.
While XCR0 is reloaded in xstate_init(), MSR_XSS isn't. This causes
get_msr_xss() to return the invalid value, and logic
First, if XSAVE is available in hardware but not visible to the guest, the
dynamic leaves shouldn't be filled in.
Second, the comment concerning XSS state is wrong. VT-x doesn't manage
host/guest state automatically, but there is provision for "host only" bits to
be set, so the implications are
We're soon going to need a compressed helper of the same form.
The size of the uncompressed image depends on the single element with the
largest offset + size. Sadly this isn't always the element with the largest
index.
Name the per-xstate-component cpu_policy struture, for legibility of the
Right now, xstate_ctxt_size() performs a cross-check of size with CPUID in for
every call. This is expensive, being used for domain create/migrate, as well
as to service certain guest CPUID instructions.
Instead, arrange to check the sizes once at boot. See the code comments for
details. Right
This has grown somewhat from v2, but is better for it IMO.
The headline change is patch 2 performing all the cross-checking at boot time.
This turned into needing prepare the Raw CPU policy earlier on boot (to avoid
further-adding to scheme we're already looking to retire).
The end result has
On 10.04.24 21:48, Jason Andryuk wrote:
phys_base needs to be set for __pa() to work in xen_pvh_init() when
finding the hypercall page. Set it before calling into
xen_prepare_pvh(), which calls xen_pvh_init(). Clear it afterward to
avoid __startup_64() adding to it and creating an incorrect
flight 186104 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186104/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 186064
Tests which
On Tue, Apr 9, 2024 at 3:19 PM Ross Lagerwall wrote:
>
> On Tue, Apr 9, 2024 at 11:20 AM Anthony PERARD
> wrote:
> >
> > On Thu, Apr 04, 2024 at 03:08:33PM +0100, Ross Lagerwall wrote:
> > > diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c
> > > index 1627da739822..1116b3978938
On Thu, May 23, 2024 at 10:41:30AM +0100, Alejandro Vallejo wrote:
> Factor out policy getters/setters from both (CPUID and MSR) policy override
> functions. Additionally, use host policy rather than featureset when
> preparing the cur policy, saving one hypercall and several lines of
>
16.05.24 14:01, Jan Beulich:
On 15.05.2024 11:10, Sergiy Kibrik wrote:
@@ -38,7 +38,10 @@ static inline bool altp2m_active(const struct domain *d)
}
/* Only declaration is needed. DCE will optimise it out when linking. */
+void altp2m_vcpu_initialise(struct vcpu *v);
+void
On Thu, May 23, 2024 at 9:47 AM Manos Pitsidianakis <
manos.pitsidiana...@linaro.org> wrote:
> On Thu, 16 May 2024 18:48, "Edgar E. Iglesias"
> wrote:
> >From: "Edgar E. Iglesias"
> >
> >Add a second mapcache for grant mappings. The mapcache for
> >grants needs to work with XC_PAGE_SIZE
On Thu, May 23, 2024 at 10:41:29AM +0100, Alejandro Vallejo wrote:
> The idea is to use xc_cpu_policy_t as a single object containing both the
> serialised and deserialised forms of the policy. Note that we need lengths
> for the arrays, as the serialised policies may be shorter than the array
>
On Thu, May 23, 2024 at 09:19:53AM +, Teddy Astie wrote:
> If some platform driver isn't compiled in, remove its related union
> entries as they are not used.
>
> Signed-off-by Teddy Astie
> ---
> xen/arch/x86/include/asm/iommu.h | 4
> xen/arch/x86/include/asm/pci.h | 4
> 2
Factor out policy getters/setters from both (CPUID and MSR) policy override
functions. Additionally, use host policy rather than featureset when
preparing the cur policy, saving one hypercall and several lines of
boilerplate.
No functional change intended.
Signed-off-by: Alejandro Vallejo
---
The idea is to use xc_cpu_policy_t as a single object containing both the
serialised and deserialised forms of the policy. Note that we need lengths
for the arrays, as the serialised policies may be shorter than the array
capacities.
* Add the serialised lengths to the struct so we can
v2 -> v3:
* Style adjustments
* Revert of loop index scope refactors
v1 -> v2:
* Removed xc_cpu_policy from xenguest.h (dropped v1/patch1)
* Added accessors for xc_cpu_policy so the serialised form can be extracted.
* Modified xen-cpuid to use accessors.
Original cover letter
flight 186078 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186078/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-qcow2 8 xen-boot fail in 186066 pass in 186078
test-armhf-armhf-xl-multivcpu
If some platform driver isn't compiled in, remove its related union
entries as they are not used.
Signed-off-by Teddy Astie
---
xen/arch/x86/include/asm/iommu.h | 4
xen/arch/x86/include/asm/pci.h | 4
2 files changed, 8 insertions(+)
diff --git a/xen/arch/x86/include/asm/iommu.h
On 16.05.24 20:58, Andrew Cooper wrote:
There are no more users, and we want to disuade people from introducing new
users just for sd_notify() and friends. Drop the dependency.
We still want the overall --with{,out}-systemd to gate the generation of the
service/unit/mount/etc files.
Rerun
On 23/05/2024 9:27 am, Jürgen Groß wrote:
> On 16.05.24 20:58, Andrew Cooper wrote:
>> diff --git a/automation/build/archlinux/current.dockerfile
>> b/automation/build/archlinux/current.dockerfile
>> index 3e37ab5c40c1..d29f1358c2bd 100644
>> --- a/automation/build/archlinux/current.dockerfile
>>
On 16.05.24 20:58, Andrew Cooper wrote:
There are no more users, and we want to disuade people from introducing new
users just for sd_notify() and friends. Drop the dependency.
We still want the overall --with{,out}-systemd to gate the generation of the
service/unit/mount/etc files.
Rerun
On 16.05.24 20:58, Andrew Cooper wrote:
Use the local freestanding wrapper instead.
Signed-off-by: Andrew Cooper
Reviewed-by: Juergen Gross # tools/xenstored
Juergen
---
CC: Anthony PERARD
CC: Juergen Gross
CC: George Dunlap
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
On 22.05.2024 17:39, Marek Marczykowski-Górecki wrote:
> Not the whole page, which may contain other registers too. The XHCI
> specification describes DbC as designed to be controlled by a different
> driver, but does not mandate placing registers on a separate page. In fact
> on Tiger Lake and
On 16.05.24 20:58, Andrew Cooper wrote:
... in order to avoid linking against the whole of libsystemd.
Only minimal changes to the upstream copy, to function as a drop-in
replacement for sd_notify() and as a header-only library.
Signed-off-by: Andrew Cooper
With
On Wed, 2024-05-22 at 12:17 +0200, Jan Beulich wrote:
> The emulation_count field is set only conditionally right now.
> Convert
> all field setting to an initializer, thus guaranteeing that field to
> be
> set to 0 (default initialized) when GUEST_PAGING_LEVELS != 3.
>
> While there also drop
1 - 100 of 119 matches
Mail list logo
