On Thu Oct 10, 2024 at 8:54 AM BST, Jan Beulich wrote:
> On 09.10.2024 19:57, Alejandro Vallejo wrote:
> > On Wed Oct 9, 2024 at 3:45 PM BST, Jan Beulich wrote:
> >> On 01.10.2024 14:38, Alejandro Vallejo wrote:
> >>> --- a/xen/lib/x86/policy.c
> >>> +++
On Wed Oct 9, 2024 at 3:53 PM BST, Jan Beulich wrote:
> On 01.10.2024 14:38, 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 to leaves 0x1f
Hi,
On Wed Oct 9, 2024 at 10:40 AM BST, Jan Beulich wrote:
> On 01.10.2024 14:37, Alejandro Vallejo wrote:
> > --- a/xen/lib/x86/policy.c
> > +++ b/xen/lib/x86/policy.c
> > @@ -15,7 +15,16 @@ int x86_cpu_policies_are_compatible(const struct
> > cpu_policy *ho
Hi,
On Wed Oct 9, 2024 at 2:12 PM BST, Jan Beulich wrote:
> On 01.10.2024 14:37, Alejandro Vallejo wrote:
> > @@ -311,18 +310,15 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
> >
> > case 0xb:
> > /*
> > - * In principle, this
On Wed Oct 9, 2024 at 2:28 PM BST, Jan Beulich wrote:
> On 01.10.2024 14:38, Alejandro Vallejo wrote:
> > If toolstack were to upload LAPIC contexts as part of domain creation it
>
> If it were to - yes. But it doesn't, an peeking ahead in the series I also
> couldn't
On Tue Oct 8, 2024 at 4:41 PM BST, Jan Beulich wrote:
> On 01.10.2024 14:37, Alejandro Vallejo wrote:
> > While doing this, factor out checks common to architectural and hidden
> > state.
> >
> > Signed-off-by: Alejandro Vallejo
> > Reviewed-by: Roger Pau Monné
On Wed Oct 9, 2024 at 3:45 PM BST, Jan Beulich wrote:
> On 01.10.2024 14:38, Alejandro Vallejo wrote:
> > --- a/xen/include/xen/lib/x86/cpu-policy.h
> > +++ b/xen/include/xen/lib/x86/cpu-policy.h
> > @@ -542,6 +542,22 @@ int x86_cpu_policies_are_compatible(const struct
Hi,
On Wed Oct 9, 2024 at 3:03 PM BST, Jan Beulich wrote:
> On 01.10.2024 14:38, 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 AP
On Wed Oct 9, 2024 at 3:25 PM BST, Jan Beulich wrote:
> On 01.10.2024 14:38, Alejandro Vallejo wrote:
> > @@ -148,7 +148,7 @@ static struct acpi_20_madt *construct_madt(struct
> > acpi_ctxt *ctxt,
> > lapic->length = sizeof(*lapic);
> > /* Pro
On Tue Oct 8, 2024 at 8:47 AM BST, Frediano Ziglio wrote:
> On Mon, Oct 7, 2024 at 4:52 PM Alejandro Vallejo
> wrote:
> >
> > fpu_ctxt is either a pointer to the legacy x87/SSE save area (used by
> > FXSAVE) or
> > a pointer aliased with xsave_area that points
On Tue Oct 8, 2024 at 7:37 AM BST, Jan Beulich wrote:
> On 07.10.2024 17:52, Alejandro Vallejo wrote:
> > It was trying to do too many things at once and there was no clear way of
> > defining what it was meant to do. This commit splits the function in two.
> >
> >
On Fri, Oct 11, 2024 at 09:52:44AM +0100, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio
> ---
> xen/arch/x86/boot/reloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
> index e50e161b27..e725cfb6eb 100644
On Wed Oct 9, 2024 at 3:25 PM BST, Jan Beulich wrote:
> On 01.10.2024 14:38, Alejandro Vallejo wrote:
> > @@ -148,7 +148,7 @@ static struct acpi_20_madt *construct_madt(struct
> > acpi_ctxt *ctxt,
> > lapic->length = sizeof(*lapic);
> > /* Pro
Hi,
On Thu Oct 3, 2024 at 8:38 PM BST, Andrew Cooper wrote:
> On 13/08/2024 3:21 pm, Alejandro Vallejo wrote:
> > @@ -299,44 +299,14 @@ void save_fpu_enable(void)
> > /* Initialize FPU's context save area */
> > int vcpu_init_fpu(struct vcpu *v)
> > {
&
).
Signed-off-by: Alejandro Vallejo
--
v4:
* Amend commit message with extra note about deduping vcpu_init_fpu()
* Remove comment on top of cpu_user_regs (though I really think there
ought to be a credible one, in one form or another).
* Remove cast from blk.c so FXSAVE_AREA is "void
he
manuals and starts as 0xFF
Signed-off-by: Alejandro Vallejo
Reviewed-by: Jan Beulich
--
@Jan: The patch changed substantially. Are you still ok with this R-by?
v4:
* Reworded commit message and title
* Remove vcpu_default_fpu() and replaced its uses with vcpu_reset_fpu()
* s
d another to set a reset state.
===========
Alejandro Vallejo (3):
x86/fpu: Combine fpu_ctxt and xsave_area in arch_vcpu
x86/fpu: Rework fpu_setup_fpu() uses to split it in two
x86/fpu: Remove remaining uses of FCW_DEFAULT
xen/arch/x86/domain.c | 7 ++-
xen/arch/x86/domctl.c
Hi,
On Fri Oct 4, 2024 at 7:08 AM BST, Jan Beulich wrote:
> On 03.10.2024 15:54, Alejandro Vallejo wrote:
> > On Tue Aug 13, 2024 at 5:33 PM BST, Alejandro Vallejo wrote:
> >> On Tue Aug 13, 2024 at 3:32 PM BST, Jan Beulich wrote:
> >>> On 13.08.2024 16:21, Alejandr
On Wed Oct 16, 2024 at 8:46 AM BST, Jan Beulich wrote:
> Another leftover from the dropping of Xeon Phi support.
>
> Signed-off-by: Jan Beulich
> ---
> Note: I'm deliberately not switching to use of the conditional operator,
> as the form as is resulting now is what we'll want for APX (which is
>
On Wed Oct 16, 2024 at 10:15 AM BST, Oleksii Kurochko wrote:
> Implement the `maddr_to_virt()` function to convert a machine address
> to a virtual address. This function is specifically designed to be used
> only for the DIRECTMAP region, so a check has been added to ensure that
> the address does
On Wed Oct 16, 2024 at 8:45 AM BST, Jan Beulich wrote:
> For some reason I entirely consistently screwed these up.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Alejandro Vallejo
We should really give another push to the clang-format effort. This whole class
of mistakes would be a thi
On Wed Oct 16, 2024 at 11:54 AM BST, Jan Beulich wrote:
> On 16.10.2024 12:34, Alejandro Vallejo wrote:
> > On Wed Oct 16, 2024 at 8:46 AM BST, Jan Beulich wrote:
> >> --- a/tools/tests/x86_emulator/evex-disp8.c
> >> +++ b/tools/tests/x86_emulator/evex-disp8.c
> >&
On Wed Oct 16, 2024 at 11:15 AM BST, Jan Beulich wrote:
> On 16.10.2024 12:06, Alejandro Vallejo wrote:
> > On Wed Oct 16, 2024 at 8:45 AM BST, Jan Beulich wrote:
> >> For some reason I entirely consistently screwed these up.
> >>
> >> Signed-off-by: Jan Beulic
On Mon Oct 21, 2024 at 3:51 PM BST, Andrew Cooper wrote:
> On 21/10/2024 3:06 pm, Roger Pau Monné wrote:
> > On Mon, Oct 21, 2024 at 12:34:37PM +0100, David Woodhouse wrote:
> >> On Fri, 2024-10-18 at 10:08 +0200, Roger Pau Monne wrote:
> >>> When using AMD-VI interrupt remapping the vector field i
On Fri Oct 18, 2024 at 2:17 PM BST, oleksii.kurochko wrote:
> On Thu, 2024-10-17 at 16:55 +0200, Jan Beulich wrote:
> > On 16.10.2024 11:15, Oleksii Kurochko wrote:
> > > --- a/xen/arch/riscv/include/asm/mm.h
> > > +++ b/xen/arch/riscv/include/asm/mm.h
> > > @@ -25,8 +25,12 @@
> > >
> > > static
On Fri Oct 18, 2024 at 9:08 AM BST, Roger Pau Monne wrote:
> When using AMD-VI interrupt remapping the vector field in the IO-APIC RTE is
> repurposed to contain part of the offset into the remapping table. Previous
> to
For my own education. Is that really a repurpose? Isn't the RTE vector fiel
On Mon Oct 21, 2024 at 12:32 PM BST, David Woodhouse wrote:
> On Mon, 2024-10-21 at 10:55 +0100, Alejandro Vallejo wrote:
> > On Fri Oct 18, 2024 at 9:08 AM BST, Roger Pau Monne wrote:
> > > When using AMD-VI interrupt remapping the vector field in the IO-APIC RTE
> >
On Mon Oct 21, 2024 at 10:17 AM BST, oleksii.kurochko wrote:
> On Mon, 2024-10-21 at 08:56 +0100, Alejandro Vallejo wrote:
> > On Fri Oct 18, 2024 at 2:17 PM BST, oleksii.kurochko wrote:
> > > On Thu, 2024-10-17 at 16:55 +0200, Jan Beulich wrote:
> > > > On 16.10.2024
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
---
v7:
* Preserve output for CPUID[0xb].edx on PV rather than nullify it.
* s/v
. Note that
bringing up the APs doesn't need the APIC in hvmloader becasue it always
runs virtualized and uses the PV interface.
While at this, exploit the assumption that CPU0 always has APICID0 to
remove ap_callin, as writing the APIC ID may serve the same purpose.
Signed-off-by: Alejandro Va
).
Signed-off-by: Alejandro Vallejo
---
v7:
* Changes to commit message
---
tools/tests/cpu-policy/test-cpu-policy.c | 68 +
xen/include/xen/lib/x86/cpu-policy.h | 11
xen/lib/x86/policy.c | 76
3 files changed, 155
APIC ID in both is consistent.
Signed-off-by: Alejandro Vallejo
---
v7:
* Rework the commit message so it explains a follow-up patch rather
than hypothetical behaviour.
---
xen/arch/x86/hvm/vlapic.c | 20
1 file changed, 20 insertions(+)
diff --git a/xen/arch/x86/hvm
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
---
v7:
* Unchanged
---
tools/libs/guest/xg_dom_x86.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/tools
intended, because the same mappings are preserved.
Signed-off-by: Alejandro Vallejo
---
v7:
* NOTE: didn't add assert to libacpi as initially accepted in order to
protect libvirt from an assert failure.
* s/uint32_t/unsigned int/ in for loop of libxl.
* turned Xen-style loop in lib
. There's no current use for the topology
information in the host policy, but it makes no harm.
Signed-off-by: Alejandro Vallejo
---
v7:
* No changes
---
tools/include/xenguest.h| 3 +++
tools/libs/guest/xg_cpuid_x86.c | 29 -
tools/libs/light/libxl_dom.c
e of real world data for how it might behave) this
implementation takes the view that those counts should clip to their
maximum values on overflow. Just like lppp and NC.
Adds the ASSERT() macro to xen/lib/x86/private.h, as it was missing.
Signed-off-by: Alejandro Vallejo
---
v7:
* MAX/MIN ->
://lore.kernel.org/xen-devel/cover.1715102098.git.alejandro.vall...@cloud.com/
v1:
https://lore.kernel.org/xen-devel/20240109153834.4192-1-alejandro.vall...@cloud.com/
Alejandro Vallejo (10):
lib/x86: Bump max basic leaf in {pv,hvm}_max_policy
xen/x86: Add initial x2APIC ID to the per-vLAPIC
this patch shouldn't affect functionality. An extra record
(the MTRR) is sent to the hypervisor per vCPU on HVM, but these records
are identical to those retrieved in the first place so there's no
expected functional change.
Signed-off-by: Alejandro Vallejo
---
v7:
* Unchanged
-
Bump it to ARRAY_SIZE() so toolstack is able to extend a policy past
host limits (i.e: to emulate a feature not present in the host)
Signed-off-by: Alejandro Vallejo
---
v7:
* Replaces v6/patch1("Relax checks about policy compatibility")
* Bumps basic.max_leaf to ARRAY_SIZE(bas
Hi,
The subject was probably meant to have a v3?
On Tue Oct 22, 2024 at 11:10 AM BST, Bernhard Kaindl wrote:
> From: Bernhard Kaindl
>
> Some admin tools like 'xl info -n' like to display the total memory
> for each NUMA node. The Xen backend[1] of hwloc comes to mind too.
>
> The total amount o
On Fri, Oct 11, 2024 at 02:08:37PM +0100, Frediano Ziglio wrote:
> On Fri, Oct 11, 2024 at 1:56 PM Alejandro Vallejo
> wrote:
> >
> > On Fri, Oct 11, 2024 at 09:52:44AM +0100, Frediano Ziglio wrote:
> > > Signed-off-by: Frediano Ziglio
> > > ---
> > &g
On Fri Oct 11, 2024 at 2:58 PM BST, Frediano Ziglio wrote:
> On Fri, Oct 11, 2024 at 2:38 PM Andrew Cooper
> wrote:
> >
> > On 11/10/2024 2:28 pm, Alejandro Vallejo wrote:
> > > On Fri, Oct 11, 2024 at 02:08:37PM +0100, Frediano Ziglio wrote:
> > >> On
On Tue Oct 29, 2024 at 8:37 AM GMT, Jan Beulich wrote:
> On 28.10.2024 16:49, Alejandro Vallejo wrote:
> > --- a/xen/arch/x86/xstate.c
> > +++ b/xen/arch/x86/xstate.c
> > @@ -300,9 +300,8 @@ void compress_xsave_states(struct vcpu *v, const void
> &
On Tue Oct 29, 2024 at 8:13 AM GMT, Jan Beulich wrote:
> On 28.10.2024 18:16, Andrew Cooper wrote:
> > On 28/10/2024 3:49 pm, Alejandro Vallejo wrote:
> >> The asserts' intent was to establish whether the xsave instruction was
> >> usable or not, which at th
On Tue Oct 29, 2024 at 8:26 AM GMT, Jan Beulich wrote:
> On 28.10.2024 16:49, Alejandro Vallejo wrote:
> > --- a/xen/arch/x86/xstate.c
> > +++ b/xen/arch/x86/xstate.c
> > @@ -993,7 +993,12 @@ int handle_xsetbv(u32 index, u64 new_bv)
> >
> > clts();
&g
On Tue Oct 29, 2024 at 8:19 AM GMT, Jan Beulich wrote:
> On 28.10.2024 16:49, Alejandro Vallejo wrote:
> > --- a/xen/arch/x86/include/asm/xstate.h
> > +++ b/xen/arch/x86/include/asm/xstate.h
> > @@ -143,4 +143,24 @@ static inline bool xstate_all(const struct vcpu *
Hi,
On Mon Oct 28, 2024 at 5:20 PM GMT, Andrew Cooper wrote:
> On 28/10/2024 3:49 pm, Alejandro Vallejo wrote:
> > diff --git a/xen/arch/x86/include/asm/xstate.h
> > b/xen/arch/x86/include/asm/xstate.h
> > index 07017cc4edfd..36260459667c 100644
> > --- a/xen/ar
On Tue Oct 29, 2024 at 1:28 PM GMT, Jan Beulich wrote:
> On 29.10.2024 12:57, Alejandro Vallejo wrote:
> > On Mon Oct 28, 2024 at 5:20 PM GMT, Andrew Cooper wrote:
> >> On 28/10/2024 3:49 pm, Alejandro Vallejo wrote:
> >>> diff --git a/xen/arch/x86/include/asm/
On Tue Oct 29, 2024 at 1:24 PM GMT, Frediano Ziglio wrote:
> On Tue, Oct 29, 2024 at 11:58 AM Alejandro Vallejo
> wrote:
> >
> > Hi,
> >
> > On Mon Oct 28, 2024 at 5:20 PM GMT, Andrew Cooper wrote:
> > > On 28/10/2024 3:49 pm, Alejandro Vallejo wrote:
> &
... and remove the macros that no longer exist.
No functional change.
Signed-off-by: Alejandro Vallejo
---
xen/common/domain.c | 6 +++---
xen/common/grant_table.c | 3 +--
xen/include/xen/grant_table.h | 4 ++--
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/xen
On Tue Oct 29, 2024 at 1:31 PM GMT, Jan Beulich wrote:
> On 29.10.2024 14:00, Alejandro Vallejo wrote:
> > On Tue Oct 29, 2024 at 8:26 AM GMT, Jan Beulich wrote:
> >> On 28.10.2024 16:49, Alejandro Vallejo wrote:
> >>> --- a/xen/arch/x86/xstate.c
> >>> +
ejandro had some better suggestions in the
> > thread on the matter.
> >
> > ~Andrew
>
> Hi,
> changed to "Starts at the end of the relocated trampoline space and
> allocates backwards".
>
> See
> https://gitlab.com/xen-project/people/fziglio/xen/-/commit/21be0b9d2813db9c578e8a6ace76eee2445908f5.
>
> Frediano
with that:
Reviewed-by: Alejandro Vallejo
Cheers,
Alejandro
... and remove the macros that no longer exist.
No functional change.
Signed-off-by: Alejandro Vallejo
---
tools/ocaml/libs/xc/xenctrl_stubs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c
b/tools/ocaml/libs/xc/xenctrl_stubs.c
index
... and remove the macros that no longer exist.
No functional change.
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 177f4024abca..a9130161969b 100644
--- a/xen/arch
... and remove the macros that no longer exist.
No functional change.
Signed-off-by: Alejandro Vallejo
---
xen/arch/arm/dom0less-build.c | 4 ++--
xen/arch/arm/domain_build.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm
... and remove the macros that no longer exist.
No functional change
Signed-off-by: Alejandro Vallejo
---
tools/helpers/init-xenstore-domain.c | 2 +-
tools/libs/light/libxl_create.c | 2 +-
tools/python/xen/lowlevel/xc/xc.c| 2 +-
tools/tests
de to
follow through with this particular case. As I said before, the split is
artificial for review.
Alejandro Vallejo (6):
xen/domctl: Refine grant_opts into grant_version
tools: Rename grant_opts to grant_version
tools/ocaml: Rename grant_opts to grant_version
xen/arm: Rename grant_opts t
ctets worth of padding is not an ABI
breakage.
No functional change
Signed-off-by: Alejandro Vallejo
---
xen/include/public/domctl.h | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 353f831
ogy in leaf 0xb even on older hardware.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Alejandro Vallejo
Cheers,
Alejandro
On Tue Oct 29, 2024 at 6:16 PM GMT, Alejandro Vallejo wrote:
> Non-boolean bitfields in the hypercall ABI make it fairly inconvenient to
> create bindings for any language because (a) they are always ad-hoc and are
> subject to restrictions regular fields are not (b) require boilerp
unmap is required (e.g: when there's
no ASI) and remove the transient maping if one was required.
Follow-up patches replace all uses of raw v->arch.xsave_area by this
mechanism in preparation to add the beforementioned dispatch logic to be
added at a later time.
Signed-off-by: Alejandro Va
After edb48e76458b("x86/fpu: Combine fpu_ctxt and xsave_area in arch_vcpu"),
v->arch.xsave_area is always present and we can just remove these asserts.
Fixes: edb48e76458b("x86/fpu: Combine fpu_ctxt and xsave_area in arch_vcpu")
Signed-off-by: Alejandro Vallejo
---
v2:
No functional change.
Signed-off-by: Alejandro Vallejo
---
v2:
* No change
---
xen/arch/x86/i387.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/i387.c b/xen/arch/x86/i387.c
index 3add0025e495..a6ae323fa95f 100644
--- a/xen/arch/x86/i387.c
No functional change.
Signed-off-by: Alejandro Vallejo
---
v2:
* No change
---
xen/arch/x86/domctl.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 5f0619da..3044f706de1c 100644
--- a/xen/arch/x86/domctl.c
No functional change.
Signed-off-by: Alejandro Vallejo
---
v2:
* const-ified v
---
xen/arch/x86/i387.c | 16 ++--
xen/arch/x86/include/asm/xstate.h | 2 +-
xen/arch/x86/xstate.c | 3 +--
3 files changed, 12 insertions(+), 9 deletions(-)
diff --git a
No functional change.
Signed-off-by: Alejandro Vallejo
---
v2:
* No change
---
xen/arch/x86/hvm/hvm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 018d44a08b6b..c90654697cb1 100644
--- a/xen/arch/x86/hvm
No functional change.
Signed-off-by: Alejandro Vallejo
---
v2:
* const-ified v in fpu_xrstor()
---
xen/arch/x86/i387.c | 26 --
xen/arch/x86/include/asm/xstate.h | 2 +-
xen/arch/x86/xstate.c | 10 ++
3 files changed, 23 insertions
No functional change.
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/i387.c | 9 +
xen/arch/x86/include/asm/xstate.h | 5 +++--
xen/arch/x86/xstate.c | 2 +-
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/i387.c b/xen/arch/x86
No functional change.
Signed-off-by: Alejandro Vallejo
---
v2:
* Added comments highlighting fastpath for current
---
xen/arch/x86/hvm/emulate.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index
No functional change.
Signed-off-by: Alejandro Vallejo
---
v2:
* No change
---
xen/arch/x86/xstate.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index 401bdad2eb0d..6db7ec2ea6a9 100644
--- a/xen/arch/x86/xstate.c
t of feedback. Explained in each patch.
Alejandro Vallejo (13):
x86/xstate: Remove stale assertions in fpu_x{rstor,save}()
x86/xstate: Create map/unmap primitives for xsave areas
x86/hvm: Map/unmap xsave area in hvm_save_cpu_ctxt()
x86/fpu: Map/umap xsave area in vcpu_{reset,setup}_fpu()
x8
Adds an UNMAP primitive to make use of vcpu_unmap_xsave_area() when
linked into xen. unmap is a no-op during tests.
Signed-off-by: Alejandro Vallejo
---
v2:
* Added comments highlighting fastpath on `current`
---
xen/arch/x86/x86_emulate/blk.c | 11 ++-
1 file changed, 10 insertions
No functional change.
Signed-off-by: Alejandro Vallejo
---
v2:
* s/ret/bndcfgu
---
xen/arch/x86/xstate.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index 6db7ec2ea6a9..9ecbef760277 100644
--- a/xen/arch/x86
No functional change.
Signed-off-by: Alejandro Vallejo
---
v2:
* Added comment highlighting fastpath for current
---
xen/arch/x86/xstate.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index af9e345a7ace
On Sat Nov 2, 2024 at 3:18 PM GMT, Daniel P. Smith wrote:
> On 11/1/24 16:16, Stewart Hildebrand wrote:
> > +Daniel (XSM mention)
> >
> > On 10/28/24 13:02, Jan Beulich wrote:
> >> On 18.10.2024 22:39, Stewart Hildebrand wrote:
> >>> Add links between a VF's struct pci_dev and its associated PF st
In the course of preparing this answer I just noticed that altp2m_opts suffers
from the exact same annoyance, with the exact same fix. I just noticed while
rebasing my Rust branch.
On Wed Oct 30, 2024 at 9:14 AM GMT, Jan Beulich wrote:
> On 29.10.2024 19:16, Alejandro Vallejo wrote:
>
Hi,
On Wed Oct 30, 2024 at 9:08 AM GMT, Jan Beulich wrote:
> On 29.10.2024 19:16, Alejandro Vallejo wrote:
> > grant_opts is overoptimizing for space packing in a hypercall that
> > doesn't warrant the effort. Tweak the ABI without breaking it in order
> > to remove th
On Wed Oct 30, 2024 at 8:45 AM GMT, Christian Lindig wrote:
>
>
> > On 29 Oct 2024, at 18:16, Alejandro Vallejo
> > wrote:
> >
> >
> > The invariant I'd like to (slowly) introduce and discuss is that fields may
> > have bitflags (e.g: a pack
On Wed Oct 30, 2024 at 3:13 PM GMT, Roger Pau Monné wrote:
> On Wed, Oct 30, 2024 at 02:45:19PM +, Andrew Cooper wrote:
> > On 30/10/2024 11:03 am, Roger Pau Monné wrote:
> > > On Wed, Oct 30, 2024 at 10:39:12AM +, Andrew Cooper wrote:
> > >> On 30/10/2024 8:59 am, Roger Pau Monné wrote:
>
Hi,
On Wed Oct 30, 2024 at 6:37 AM GMT, Jan Beulich wrote:
> On 29.10.2024 21:30, Andrew Cooper wrote:
> > On 21/10/2024 4:45 pm, Alejandro Vallejo wrote:
> >> @@ -310,19 +309,16 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
> >> break
I'm fine with all suggestions, with one exception that needs a bit more
explanation...
On Tue Oct 29, 2024 at 8:30 PM GMT, Andrew Cooper wrote:
> On 21/10/2024 4:45 pm, Alejandro Vallejo wrote:
> > This allows the initial x2APIC ID to be sent on the migration stream.
> >
On Fri Nov 1, 2024 at 7:06 AM GMT, Jürgen Groß wrote:
> On 31.10.24 12:58, Alejandro Vallejo wrote:
> > On Wed Oct 23, 2024 at 3:27 PM BST, Juergen Gross wrote:
> >> On 23.10.24 16:08, Alejandro Vallejo wrote:
> >>> On Wed Oct 23, 2024 at 2:10 PM BST, Juergen G
On Wed Oct 23, 2024 at 1:28 PM BST, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
Reviewed-by: Alejandro Vallejo
With a single nit that I don't care much about, but...
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
>
> I found this hiding in other microcode
On Wed Oct 23, 2024 at 2:10 PM BST, Juergen Gross wrote:
> Xenstore is referencing domains by their domid, but reuse of a domid
> can lead to the situation that Xenstore can't tell whether a domain
> with that domid has been deleted and created again without Xenstore
> noticing the domain is a new
No functional change.
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/xstate.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index 4019ca4aae83..2a54da2823cf 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86
ert is that the host supports XSAVE.
Fixes: edb48e76458b("x86/fpu: Combine fpu_ctxt and xsave_area in arch_vcpu")
Signed-off-by: Alejandro Vallejo
---
I'd also be ok with removing the assertions altogether. They serve very
little purpose there after the merge of xsave and fpu_ctxt
No functional change.
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/xstate.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index 60e752a245ca..4019ca4aae83 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86
No functional change.
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/xstate.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index af9e345a7ace..60e752a245ca 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86
No functional change.
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/hvm/emulate.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index f2bc6967dfcb..a6ddc9928f16 100644
--- a/xen/arch/x86/hvm/emulate.c
I), some perma-mapped vCPU-local area (see series (b) at the top) or
implemented as a transient mapping in the style of {un,}map_domain_page() for
glacially cold accesses to non-current vCPUs. Importantly, writing the final
macros involve the other series going in.
Alejandro Vallejo (14):
x86
No functional change.
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/i387.c | 9 +
xen/arch/x86/include/asm/xstate.h | 5 +++--
xen/arch/x86/xstate.c | 2 +-
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/i387.c b/xen/arch/x86
No functional change.
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/i387.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/i387.c b/xen/arch/x86/i387.c
index 375a8274f632..a571bcb23c91 100644
--- a/xen/arch/x86/i387.c
+++ b/xen/arch/x86/i387.c
No functional change.
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/i387.c | 26 --
xen/arch/x86/include/asm/xstate.h | 2 +-
xen/arch/x86/xstate.c | 10 ++
3 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/xen/arch
No functional change.
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/domctl.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 5f0619da..8f6075bc84b8 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86
Adds an UNMAP primitive to make use of vcpu_unmap_xsave_area() when
linked into xen. unmap is a no-op during tests.
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/x86_emulate/blk.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/x86_emulate/blk.c b
unmap is required (e.g: when there's
no ASI) and remove the transient maping if one was required.
Follow-up patches replace all uses of raw v->arch.xsave_area by this
mechanism in preparation to add the beforementioned dispatch logic to be
added at a later time.
Signed-off-by: Alejandro Vall
No functional change.
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/i387.c | 16 ++--
xen/arch/x86/include/asm/xstate.h | 2 +-
xen/arch/x86/xstate.c | 3 +--
3 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/i387.c b/xen
No functional change.
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/hvm/hvm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 018d44a08b6b..77b975f07f32 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86
Hi,
On Sun Oct 27, 2024 at 2:43 PM GMT, Bernhard Kaindl wrote:
> From: Bernhard Kaindl
>
> At the moment, Xen keeps track of the spans of PFNs of the NUMA nodes.
> But the PFN span sometimes includes large MMIO holes, so these values
> might not be an exact representation of the total usable RAM
1 - 100 of 706 matches
Mail list logo
