On Fri Jul 26, 2024 at 4:21 PM BST, Roger Pau Monne wrote:
> In preparation for the function being called from contexts where no domain is
> present.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
> ---
> xen/arch/x86/include/asm/mm.h | 4 +++-
> xen/arch/x86/mm.c
temp variable of yet another type that is
potentially neither "typeof(arg)" nor "unsigned long". No need to create a 3
body problem, where 2 is enough. Adjusting BUILD_BUG_ON() to use the same temp
type seems sensible, but I don't mind very much.
With the stale comment adjusted:
Reviewed-by: Alejandro Vallejo
Cheers,
Alejandro
On Fri Jul 26, 2024 at 5:25 PM BST, Alejandro Vallejo wrote:
> On Fri Jul 26, 2024 at 4:18 PM BST, Roger Pau Monné wrote:
> > On Fri, Jul 26, 2024 at 03:25:08PM +0100, Alejandro Vallejo wrote:
> > > On Fri Jul 26, 2024 at 3:17 PM BST, Alejandro Vallejo wrote:
> > > >
On Fri Jul 26, 2024 at 4:11 PM BST, Paul Durrant wrote:
> On 26/07/2024 15:52, Alejandro Vallejo wrote:
> > It's sadically misleading to show an error without letters and expect
> > the dmesg reader to understand it's in hex.
>
> That depends on who's doing the reading.
>
On Fri Jul 26, 2024 at 4:18 PM BST, Roger Pau Monné wrote:
> On Fri, Jul 26, 2024 at 03:25:08PM +0100, Alejandro Vallejo wrote:
> > On Fri Jul 26, 2024 at 3:17 PM BST, Alejandro Vallejo wrote:
> > > On Fri Jul 26, 2024 at 9:05 AM BST, Jan Beulich wrote:
> > > > On 26.
the guest
asking the hypervisor for a sudden shutdown because it crashed, and
stating why.
Signed-off-by: Alejandro Vallejo
---
Still going through its Gitlab pipeline
---
xen/arch/x86/hvm/viridian/synic.c| 2 +-
xen/arch/x86/hvm/viridian/viridian.c | 9 +
2 files changed, 6 insert
On Fri Jul 26, 2024 at 3:17 PM BST, Alejandro Vallejo wrote:
> On Fri Jul 26, 2024 at 9:05 AM BST, Jan Beulich wrote:
> > On 26.07.2024 09:52, Roger Pau Monné wrote:
> > > On Fri, Jul 26, 2024 at 09:36:15AM +0200, Jan Beulich wrote:
> > >> On 26.07.2024 09:31, Roger P
On Fri Jul 26, 2024 at 9:05 AM BST, Jan Beulich wrote:
> On 26.07.2024 09:52, Roger Pau Monné wrote:
> > On Fri, Jul 26, 2024 at 09:36:15AM +0200, Jan Beulich wrote:
> >> On 26.07.2024 09:31, Roger Pau Monné wrote:
> >>> On Thu, Jul 25, 2024 at 05:00:22PM +0200, Jan Beulich wrote:
> On
On Wed Jul 24, 2024 at 2:01 PM BST, Jan Beulich wrote:
> On 24.07.2024 14:51, Matthew Barnes wrote:
> > On Wed, Jul 24, 2024 at 07:42:19AM +0200, Jan Beulich wrote:
> >> (re-adding xen-devel@)
> >>
> >> On 23.07.2024 14:57, Matthew Barnes wrote:
> >>> On Mon, Jul 22, 2024 at 01:37:11PM +0200, Jan
On Wed Jul 24, 2024 at 6:42 AM BST, Jan Beulich wrote:
> On 23.07.2024 15:47, Alejandro Vallejo wrote:
> > On Mon Jul 22, 2024 at 11:18 AM BST, Andrew Cooper wrote:
> >> +if ( (eax >> 16) != 0x8000 || eax < 0x8000U )
> >> +blexit(L"In
On Tue Jul 23, 2024 at 5:09 PM BST, Roger Pau Monné wrote:
> On Tue, Jul 23, 2024 at 04:37:12PM +0100, Alejandro Vallejo wrote:
> > On Tue Jul 23, 2024 at 10:31 AM BST, Roger Pau Monne wrote:
> > > Clang will generate machine code that only resets the low 8 bits of %rdi
> &
On Tue Jul 23, 2024 at 10:31 AM BST, Roger Pau Monne wrote:
> Yet another clang code generation issue when using altcalls.
>
> The issue this time is with using loop constructs around alternative_{,v}call
> instances using parameter types smaller than the register size.
>
> Given the following
boot when CONFIG_REQUIRE_NX is active.
>
> Fixes: fc3090a47b21 ("x86/boot: Clear XD_DISABLE from the early boot path")
> Link: https://xcp-ng.org/forum/post/80520
> Reported-by: Gene Bright
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
&
; CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Daniel P. Smith
> CC: Marek Marczykowski-Górecki
> CC: Alejandro Vallejo
> CC: Gene Bright
> ---
> xen/arch/x86/efi/efi-boot.h | 31 ---
> 1 file changed, 16 insertions(+), 15 deletions(-)
>
>
On Wed Jul 17, 2024 at 4:51 PM BST, Teddy Astie wrote:
> If for some reason, xmalloc fails after having mapped the
> reserved regions, a error is reported, but the regions are
> actually mapped in p2m.
>
> Move the allocation before trying to map the regions, in
> case the allocation fails, no
On Tue Jun 25, 2024 at 11:47 PM BST, Tamas K Lengyel wrote:
> The build integration script for oss-fuzz targets. Future fuzzing targets can
> be added to this script and those targets will be automatically picked up by
> oss-fuzz without having to open separate PRs on the oss-fuzz repo.
>
>
On Thu Jul 18, 2024 at 1:19 PM BST, Jan Beulich wrote:
> On 09.07.2024 17:52, Alejandro Vallejo wrote:
> > It's doing too many things at once and there's no clear way of defining what
> > it's meant to do. This patch splits the function in two.
> >
> > 1. A re
On Thu Jul 18, 2024 at 12:49 PM BST, Jan Beulich wrote:
> On 09.07.2024 17:52, Alejandro Vallejo wrote:
> > --- a/xen/arch/x86/domctl.c
> > +++ b/xen/arch/x86/domctl.c
> > @@ -1343,7 +1343,8 @@ void arch_get_info_guest(struct vcpu *v,
> > vcpu_guest_context_u c)
>
On Thu Jul 18, 2024 at 12:23 PM BST, Jan Beulich wrote:
> On 09.07.2024 17:52, Alejandro Vallejo wrote:
> > Making the union non-anonymous causes a lot of headaches,
>
> Maybe better "would cause", as that's not what you're doing here?
Yes, sounds better.
>
> >
On Tue Jul 16, 2024 at 6:06 PM BST, Alejandro Vallejo wrote:
> On Mon May 13, 2024 at 2:40 PM BST, Elias El Yandouzi wrote:
> > From: Wei Liu
> >
> > It is going to be needed by HVM and idle domain as well, because without
> > the direct map, both need a mapcache to map
On Mon May 13, 2024 at 2:40 PM BST, Elias El Yandouzi wrote:
> From: Wei Liu
>
> It is going to be needed by HVM and idle domain as well, because without
> the direct map, both need a mapcache to map pages.
>
> This commit lifts the mapcache variable up and initialise it a bit earlier
> for PV
On Thu Jul 11, 2024 at 3:04 PM BST, Teddy Astie wrote:
> 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
Disclaimer: I haven't looked at the code yet.
On Thu Jul 11, 2024 at 3:04 PM BST, Teddy Astie wrote:
> 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
0less-arm32.sh | 2 +-
> automation/scripts/qemu-smoke-dom0less-arm64.sh | 2 +-
> automation/scripts/qemu-xtf-dom0less-arm64.sh | 2 +-
> automation/scripts/xilinx-smoke-dom0less-arm64.sh | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
lgtm,
Reviewed-by: Alejandro Vallejo
host supporting it or not. The rationale is that the memory savings are
negligible and not worth the extra complexity.
Patch 4 is a non-trivial split of the vcpu_setup_fpu() into 2 separate
functions. One to override x87/SSE state, and another to set a reset state.
Alejandro Vallejo (4):
x86/xstate: Use compress
union at the head of
the XSAVE area and uses it instead of typeof().
No functional change.
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/hvm/emulate.c| 5 ++---
xen/arch/x86/i387.c | 8
xen/arch/x86/include/asm/xstate.h | 2 ++
xen/arch/x86/xstate.c
into a single XSAVE area. In
the very rare case in which the host doesn't support XSAVE all we're doing is
wasting a tiny amount of memory and trading those for a lot more simplicity in
the code.
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/domctl.c | 3 ++-
xen/arch/x86/hvm/emulate.c
to the
default values present during vCPU creation.
2. A x87/SSE state loader (equivalent to the old function when it took a data
pointer).
Signed-off-by: Alejandro Vallejo
---
I'm still not sure what the old function tries to do. The state we start vCPUs
in is _similar_ to the after-finit
Minor refactor to make xstate_all() use a helper rather than poking directly
into the XSAVE header.
No functional change
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/include/asm/xstate.h | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x86
On Tue Jul 9, 2024 at 1:21 PM BST, Michal Orzel wrote:
> Switch to using https://gitlab.com/xen-project/imagebuilder.git which
> should be considered official ImageBuilder repo.
>
> Signed-off-by: Michal Orzel
> ---
> automation/scripts/qemu-smoke-dom0-arm32.sh | 2 +-
>
On Mon Jul 1, 2024 at 9:57 AM BST, Jan Beulich wrote:
> On 26.06.2024 11:28, Federico Serafini wrote:
> > Add defensive return statement at the end of an unreachable
> > default case. Other than improve safety, this meets the requirements
> > to deviate a violation of MISRA C Rule 16.3: "An
I'll pitch in, seeing as I created the GitLab ticket.
On Tue Jul 9, 2024 at 7:40 AM BST, Jan Beulich wrote:
> On 08.07.2024 17:42, Matthew Barnes wrote:
> > Currently, OVMF is hard-coded to set up a maximum of 64 vCPUs on
> > startup.
> >
> > There are efforts to support a maximum of 128 vCPUs,
On Wed Jul 3, 2024 at 12:58 PM BST, Jan Beulich wrote:
> On 03.07.2024 13:19, Alejandro Vallejo wrote:
> > +/*
> > + * Unmaps a range of virtually contiguous memory from one of the vmap
> > regions
> > + *
> > + * The system remembers internally how wide the
In it's current form it's rather cryptic for uninitiated, so this patch
documents everything in there to make it more palatable.
No functional change.
Signed-off-by: Alejandro Vallejo
---
v2:
* Removed Doxygen-style markers on comments.
* Added some missing documentations for the return
On Wed Jul 3, 2024 at 8:41 AM BST, Jan Beulich wrote:
> On 02.07.2024 15:03, Alejandro Vallejo wrote:
> > --- a/xen/include/xen/vmap.h
> > +++ b/xen/include/xen/vmap.h
> > @@ -1,34 +1,131 @@
> > +/*
> > + * Interface to map physical memory onto contiguous virtual
In it's current form it's rather cryptic for uninitiated, so this patch
documents everything in there to make it more palatable.
No functional change.
Signed-off-by: Alejandro Vallejo
---
xen/include/xen/vmap.h | 100 +
1 file changed, 100 insertions
On Thu Jun 27, 2024 at 10:42 AM BST, Jan Beulich wrote:
> On 26.06.2024 18:28, Alejandro Vallejo wrote:
> > 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
> >
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 impleme
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/
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
hvmloader will override them anyway.
While at it, add a missing "goto out" to what was the error condition in the
loop.
Signed-off-by: Alejandro Vallejo
---
v4:
* New patch
---
tools/libs/guest/xg_dom_x86.c | 83 ++-
1 file changed, 43 inserti
is not implemented. In that case, the new helper just returns
the legacy mapping.
Signed-off-by: Alejandro Vallejo
---
v2->v4 (v3 was not reviewed):
* Rewrite eXX notation for CPUID leaves as "extended XX"
* Newlines and linewraps
* In the unit-test, reduce the scope of `policy`
* In the un
estanding environments
(e.g: hvmloader)
Patch 4: Remove old assumptions about vcpu_id<->apic_id relationship in
hvmloader
Patch 5: Add logic to derive x2APIC IDs given a CPU policy and vCPU IDs
Patch 6: Includes a simple topology generator for toolstack so new guests
have topo
ID in the hidden state. This patch ensures updates to the hidden state trigger
an update in the architectural registers so the APIC ID in both is consistent.
Signed-off-by: Alejandro Vallejo
---
v4:
* New patch
---
xen/arch/x86/hvm/vlapic.c | 20
1 file changed, 20
convention if
zero.
The hardcoded mapping x2apic_id=2*vcpu_id is kept for the time being, but it's
meant to be overriden by toolstack on a later patch with appropriate values.
Signed-off-by: Alejandro Vallejo
---
Same rationale as previous patch for inclusion in 4.19
Roger replied to v3 with an R
. There's no current use for the topology information in the host
policy, but it makes no harm.
Signed-off-by: Alejandro Vallejo
---
This patch MUST NOT go in without the following intimately related one
"Set topologically correct x2APIC IDs for each vCPU"
Otherwise we expose on
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
there are no surprises.
Signed-off-by: Alejandro Vallejo
---
This is a fix for a latent bug. Should go into 4.19.
v4
* New patch
---
tools/firmware/hvmloader/util.c | 9 -
tools/firmware/hvmloader/util.h | 27 ---
2 files changed, 24 insertions(+), 12 deletions(-)
diff --git
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
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 @@
On 31/05/2024 00:59, Andrew Cooper wrote:
> On 29/05/2024 3:30 pm, Alejandro Vallejo wrote:
>> diff --git a/tools/include/xenguest.h b/tools/include/xenguest.h
>> index e01f494b772a..85d56f26537b 100644
>> --- a/tools/include/xenguest.h
>> +++ b/tools/include/xengu
On 30/05/2024 12:08, Andrew Cooper wrote:
> On 29/05/2024 3:32 pm, Alejandro Vallejo wrote:
>> diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c
>> index f033d22785be..b70b22d55fcf 100644
>> --- a/xen/lib/x86/policy.c
>> +++ b/xen/lib/x86/policy.c
>> @
On 29/05/2024 17:16, Alejandro Vallejo wrote:
> On 29/05/2024 15:32, Alejandro Vallejo wrote:
>> +static uint32_t read_apic_id(void)
>> +{
>> +uint32_t apic_id;
>> +
>> +if ( has_x2apic )
>> +cpuid(0xb, NULL, NULL, NULL, _id);
>> +
On 29/05/2024 15:32, Alejandro Vallejo wrote:
> +static uint32_t read_apic_id(void)
> +{
> +uint32_t apic_id;
> +
> +if ( has_x2apic )
> +cpuid(0xb, NULL, NULL, NULL, _id);
> +else
> +{
> +cpuid(1, NULL, _id, NULL, NULL)
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
. There's no current use for the topology information in the host
policy, but it makes no harm.
Signed-off-by: Alejandro Vallejo
---
v3:
* Formatting adjustments.
* Restored previous topology logic and gated it through the "restore" variable
* Print return code on topo generatio
5: Add logic to derive x2APIC IDs given a CPU policy and vCPU IDs
Patch 6: Includes a simple topology generator for toolstack so new guests
have topologically consistent information in CPUID
Alejandro Vallejo (6):
x86/vlapic: Move lapic migration checks to the check hooks
xen/x
While doing this, factor out checks common to architectural and hidden state.
Signed-off-by: Alejandro Vallejo
---
v3:
* Moved from v2/patch3.
* Added check hook for the architectural state as well.
* Use domain_vcpu() rather than the previous open coded checks for vcpu range.
---
xen
is not implemented. In that case, the new helper just returns
the legacy mapping.
Signed-off-by: Alejandro Vallejo
---
v3:
* Formatting adjustments.
* Replace a conditional in x86_topo_from_parts() with MIN()
* Was meant to happen in v2, but fell between the cracks.
* Moved the `policy` variable
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
IDs are calculated from the CPU policy where the guest topology is
defined. For the time being, the function simply returns the old
relationship, but will eventually return results consistent with the
topology.
Signed-off-by: Alejandro Vallejo
---
v3:
* Added rsvd_zero check to the check hook
erialise to/from the internal buffers of xc_cpu_policy_t. The
struct is suitably expanded to hold extra information required.
Patch 3: Performs the refactor of the policy manipulation code so that it
follows a strict: PULL_POLICIES, MUTATE_POLICY (n times), PUSH_POLICY.
Alej
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
allocating dynamic
memory aside from the policy objects in xen-cpuid. Also minor cleanup
in the policy print call sites.
No functional change intended.
Signed-off-by: Alejandro Vallejo
Acked-by: Roger Pau Monné
---
v4:
* Clarify with a comment the semantics of the serialised buffer
On 27/05/2024 09:20, Roger Pau Monné wrote:
> On Fri, May 24, 2024 at 06:16:01PM +0100, Alejandro Vallejo wrote:
>> On 24/05/2024 09:58, Roger Pau Monné wrote:
>>> On Wed, May 08, 2024 at 01:39:27PM +0100, Alejandro Vallejo wrote:
>>>
>>>> +
On 23/05/2024 17:50, Roger Pau Monné wrote:
> 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 no
On 27/05/2024 09:52, Roger Pau Monné wrote:
>> My intent here was to prevent the compiler omitting the write (though in
>> practice it didn't). I think the barrier is still required to prevent
>> reordering according to the spec.
>
> Yes, my understating is that you added the ACCESS_ONCE() to
On 24/05/2024 09:58, Roger Pau Monné wrote:
> On Wed, May 08, 2024 at 01:39:27PM +0100, Alejandro Vallejo wrote:
>> Expose sensible topologies in leaf 0xb. At the moment it synthesises non-HT
>> systems, in line with the previous code intent.
>>
>> Signed-off-by: Alej
On 24/05/2024 09:39, Roger Pau Monné wrote:
> On Wed, May 08, 2024 at 01:39:26PM +0100, Alejandro Vallejo wrote:
>> 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 t
On 23/05/2024 17:13, Roger Pau Monné wrote:
> 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
&g
On 24/05/2024 08:21, Roger Pau Monné wrote:
> 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
&g
On 23/05/2024 15:50, Roger Pau Monné wrote:
> 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:
>> *
On 23/05/2024 15:32, Roger Pau Monné wrote:
>> case 0xb:
>> -/*
>> - * In principle, this leaf is Intel-only. In practice, it is
>> tightly
>> - * coupled with x2apic, and we offer an x2apic-capable APIC
>> emulation
>> - * to guests on AMD hardware as well.
On 23/05/2024 11:21, Roger Pau Monné wrote:
> 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
&g
On 23/05/2024 11:47, Roger Pau Monné wrote:
>> -static xen_cpuid_leaf_t *find_leaf(
>> -xen_cpuid_leaf_t *leaves, unsigned int nr_leaves,
>> -const struct xc_xend_cpuid *xend)
>> +static xen_cpuid_leaf_t *find_leaf(xc_cpu_policy_t *p,
>> + const struct
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
allocating dynamic
memory aside from the policy objects in xen-cpuid. Also minor cleanup
in the policy print call sites.
No functional change intended.
Signed-off-by: Alejandro Vallejo
---
v3:
* Better context scoping in xg_sr_common_x86.
* Can't be const because write_record() takes non
h 3: Performs the refactor of the policy manipulation code so that it
follows a strict: PULL_POLICIES, MUTATE_POLICY (n times), PUSH_POLICY.
Subject: [PATCH v3 0/2] *** SUBJECT HERE ***
*** BLURB HERE ***
Alejandro Vallejo (2):
tools/xg: Streamline cpu policy serialise/deserialise calls
On 20/05/2024 13:45, Roger Pau Monné wrote:
> On Fri, May 17, 2024 at 05:08:33PM +0100, Alejandro Vallejo wrote:
>> v2:
>> * Removed xc_cpu_policy from xenguest.h
>> * Added accessors for xc_cpu_policy so the serialised form can be
>> extracted.
>> * Mo
On 22/05/2024 10:33, Jan Beulich wrote:
> On 08.05.2024 14:39, 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 vla
On 20/05/2024 14:47, Roger Pau Monné wrote:
>> @@ -917,17 +922,14 @@ int xc_cpu_policy_set_domain(xc_interface *xch,
>> uint32_t domid,
>> xc_cpu_policy_t *policy)
>> {
>> uint32_t err_leaf = -1, err_subleaf = -1, err_msr = -1;
>> -unsigned int nr_leaves =
On 20/05/2024 16:02, Roger Pau Monné wrote:
>> -
>> static int xc_msr_policy(xc_interface *xch, domid_t domid,
>> - const struct xc_msr *msr)
>> + const struct xc_msr *msr,
>> + xc_cpu_policy_t *host,
>> +
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
ES, MUTATE_POLICY (n times), PUSH_POLICY.
Alejandro Vallejo (2):
tools/xg: Streamline cpu policy serialise/deserialise calls
tools/xg: Clean up xend-style overrides for CPU policies
tools/include/xenguest.h| 8 +-
tools/libs/guest/xg_cpuid_x86.c | 537 ++--
allocating dynamic
memory aside from the policy objects in xen-cpuid. Also minor cleanup
in the policy print call sites.
No functional change intended.
Signed-off-by: Alejandro Vallejo
---
v2:
* Removed v1/patch1.
* Added the accessors suggested in feedback.
---
tools/include/xenguest.h
On 30/04/2024 15:13, Anthony PERARD wrote:
> On Wed, Feb 07, 2024 at 05:39:55PM +0000, Alejandro Vallejo wrote:
>> diff --git a/tools/include/xenguest.h b/tools/include/xenguest.h
>> index e01f494b772a..4e9078fdee4d 100644
>> --- a/tools/include/xenguest.h
>> +++
On 16/05/2024 16:37, Alejandro Vallejo wrote:
> On 30/04/2024 15:42, Anthony PERARD wrote:
>> On Wed, Feb 07, 2024 at 05:39:57PM +, Alejandro Vallejo wrote:
>>> diff --git a/tools/libs/guest/xg_cpuid_x86.c
>>> b/tools/libs/guest/xg_cpuid_x86.c
>>> ind
On 30/04/2024 15:42, Anthony PERARD wrote:
> On Wed, Feb 07, 2024 at 05:39:57PM +0000, Alejandro Vallejo wrote:
>> diff --git a/tools/libs/guest/xg_cpuid_x86.c
>> b/tools/libs/guest/xg_cpuid_x86.c
>> index 5699a26b946e..cee0be80ba5b 100644
>> --- a/tools/libs/guest/xg
Hi,
On 16/05/2024 13:37, Jan Beulich wrote:
> On 16.05.2024 14:29, Alejandro Vallejo wrote:
>> On 16/05/2024 12:35, Roger Pau Monné wrote:
>>> On Thu, May 16, 2024 at 12:07:10PM +0100, Alejandro Vallejo wrote:
>>>> Bring test_x86_emulator in line with other tests by
Hi,
On 16/05/2024 12:16, Jan Beulich wrote:
> On 16.05.2024 13:07, Alejandro Vallejo wrote:
>> Bring test_x86_emulator in line with other tests by adding
>> install/uninstall rules.
>>
>> Signed-off-by: Alejandro Vallejo
>
> I'd expect such a change to
On 16/05/2024 12:35, Roger Pau Monné wrote:
> On Thu, May 16, 2024 at 12:07:10PM +0100, Alejandro Vallejo wrote:
>> Bring test_x86_emulator in line with other tests by adding
>> install/uninstall rules.
>>
>> Signed-off-by: Alejandro Vallejo
>> ---
>>
Bring test_x86_emulator in line with other tests by adding
install/uninstall rules.
Signed-off-by: Alejandro Vallejo
---
tools/tests/x86_emulator/Makefile | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/tools/tests/x86_emulator/Makefile
b/tools/tests
On 14/05/2024 09:03, Jan Beulich wrote:
> On 13.05.2024 17:27, Roger Pau Monné wrote:
>> On Mon, May 13, 2024 at 11:10:59AM +, Elias El Yandouzi wrote:
>>> @@ -317,6 +317,14 @@ extern unsigned long xen_phys_start;
>>> #define ARG_XLAT_START(v)\
>>> (ARG_XLAT_VIRT_START +
While adjusting, rename to cpu_setup(). It's always been used on the BSP,
> making the name ap_start() specifically misleading.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Alejandro Vallejo
>
> This is a trick I found for XTF, n
On 08/05/2024 20:13, Andrew Cooper wrote:
> On 08/05/2024 1:39 pm, Alejandro Vallejo wrote:
>> Removes a needless assembly entry point and simplifies the codebase by
>> allowing
>> hvmloader to wake APs it doesn't know the APIC ID of.
>>
>> Signed-off-by: Alejandr
. In that case, the new helper just returns
the legacy mapping.
Signed-off-by: Alejandro Vallejo
---
v2:
* const-ify the test definitions
* Cosmetic changes (newline + parameter name in prototype)
---
tools/tests/cpu-policy/test-cpu-policy.c | 63
xen/include/xen/lib/x86/cpu
, so break the cycle moving the guilty inline into hvm.h.
No functional change.
Signed-off-by: Alejandro Vallejo
---
v2:
* New patch. Prereq to moving vlapic_cpu_policy_changed() onto hvm.h
---
xen/arch/x86/hvm/irq.c| 6 +++---
xen/arch/x86/hvm/vlapic.c | 4 ++--
xe
IDs are calculated from the CPU policy where the guest topology is
defined. For the time being, the function simply returns the old
relationship, but will eventually return results consistent with the
topology.
Signed-off-by: Alejandro Vallejo
---
v2:
* Removed usage of SET_xAPIC_ID
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
1 - 100 of 376 matches
Mail list logo
