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 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 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.
> >
> >
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.
>
> Signed-
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 mapp
; 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(-)
>
>
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é
&
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 exam
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 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 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 B
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 25.07.2
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
ly not what goes on. It's 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 +-
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.
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 th
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:
> > > >
be thrilled to create a 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 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
In case EFI not multiboot rolling back relocation is done in
efi_arch_post_exit_boot, called by efi_start however this is
not done in multiboot code path.
Do it also for this path to make it work correctly.
Signed-off-by: Frediano Ziglio
---
xen/arch/x86/boot/head.S | 29 +++---
xen
--
(This series is work from Frediano. He's having some issues with his dev
environment and asked me to push it to xen-devel on his behalf)
--
Tes
This change allows to put the trampoline in a separate, not executable
section. The trampoline contains a mix of code and data (data which
is modified from C code during early start so must be writable).
This is in preparation for W^X patch in order to satisfy UEFI CA
memory mitigation requirements
Instead of relocate the value at that position compute it
entirely and write it.
During EFI boots sym_offs(SYMBOL) are potentially relocated
causing the values to be corrupted.
For PVH and BIOS the change won't be necessary but keep the
code consistent.
Signed-off-by: Frediano Ziglio
---
xen/arc
If code is loaded by EFI the loader will relocate the image
under 4GB. This cause offsets in x86 code generated by
sym_offs(SYMBOL) to be relocated too (basically they won't be
offsets from image base). In order to get real offset the
formulae "sym_offs(SYMBOL) - sym_offs(__image_base__)" is
used i
No reason to wait, if Xen image is loaded by EFI (not multiboot
EFI path) these are set in efi_arch_load_addr_check, but
not in the multiboot EFI code path.
This change makes the 2 code paths more similar and allows
the usage of these variables if needed.
Signed-off-by: Frediano Ziglio
---
xen/a
Hi. Sorry, I've been busy and couldn't get back to this sooner.
On Fri Jul 19, 2024 at 10:14 AM BST, Jan Beulich wrote:
> On 18.07.2024 18:54, Alejandro Vallejo wrote:
> > On Thu Jul 18, 2024 at 12:49 PM BST, Jan Beulich wrote:
> >> On 09.07.2024 17:52, Alejandro Va
reset 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).
While at it, make sure the abridged tag is consistent with the manuals and
start as 0xFF.
Signed-off-by: Alejandro Vallejo
---
v2
igible 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 (2):
x86/f
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
---
v2:
* Added BUILD_BUG_ON(sizeof(x) != sizeof(fpusse_t)) o
->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 topologically consistent information in CPUID
Alejandro Vallejo (10):
tools/hvmloader: Fix non-det
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
---
v5:
* No change
---
tools/libs/guest/xg_dom_x86.c | 38 ++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff
mentation so there are no surprises.
Fixes: 318ac791f9f9 ("Add utilities needed for SMBIOS generation to
hvmloader")
Signed-off-by: Alejandro Vallejo
---
v5:
* Added Fixes tag
* Cosmetic changes to static inline, as proposed by Andrew
---
tools/firmware/hvmloader/util.c | 9 -
t
While doing this, factor out checks common to architectural and hidden
state.
Signed-off-by: Alejandro Vallejo
Reviewed-by: Roger Pau Monné
---
v5:
* No change
---
xen/arch/x86/hvm/vlapic.c | 81 +--
1 file changed, 53 insertions(+), 28 deletions(-)
diff
. There's no current use for the topology
information in the host policy, but it makes no harm.
Signed-off-by: Alejandro Vallejo
---
v5:
* No change
---
tools/libs/guest/xg_cpuid_x86.c | 24 +++-
xen/arch/x86/cpu-policy.c | 9 ++---
2 files changed, 29 insertions(
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
is consistent.
Signed-off-by: Alejandro Vallejo
---
We could also let toolstack synthesise architectural registers, but
that would be adding logic on how architectural state operates to
software that really shouldn't care. I could be persuaded to do it the
other way, but I think it's g
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
---
v5:
* No change
---
xen/arch/x86/cpuid.c | 14 +-
xen
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: Alejand
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
---
v5:
* Ensure MTRRs are o
s not implemented. In that case, the new helper
just returns the legacy mapping.
Signed-off-by: Alejandro Vallejo
---
v5:
* No change
---
tools/tests/cpu-policy/test-cpu-policy.c | 68 +
xen/include/xen/lib/x86/cpu-policy.h | 11
xen/lib/x86/policy.c
On Thu Aug 8, 2024 at 3:10 PM BST, Jan Beulich wrote:
> On 08.08.2024 15:42, 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
> > imple
On Thu Aug 8, 2024 at 2:02 PM BST, Jan Beulich wrote:
> On 08.08.2024 14:43, GitLab wrote:
> >
> >
> > Pipeline #1405649318 has failed!
> >
> > Project: xen ( https://gitlab.com/xen-project/hardware/xen )
> > Branch: staging (
> > https://gitlab.com/xen-project/hardware/xen/-/commits/staging )
On Fri Aug 9, 2024 at 11:09 AM BST, Sergiy Kibrik wrote:
> With specific config option INTEL in place and most of the code that depends
> on intel.c now can be optionally enabled/disabled it's now possible to put
> the whole intel.c under INTEL option as well. This will allow for a Xen build
> with
This warning only makes sense when developing using a compiler with C99
support on a codebase meant to be built with C89 compilers too, and
that's no longer the case (nor should it be, as it's been 25 years since
C99 came out already).
Signed-off-by: Alejandro Vallejo
---
Yes, I'
On Mon Aug 12, 2024 at 10:58 AM BST, Jan Beulich wrote:
> On 12.08.2024 11:40, Sergiy Kibrik wrote:
> > 09.08.24 13:36, Alejandro Vallejo:
> >> On Fri Aug 9, 2024 at 11:09 AM BST, Sergiy Kibrik wrote:
> >>> --- a/xen/arch/x86/cpu/Makefile
> >>> +++ b/xen/
ve a lot more exposure to it than I do.
I'm quite curious about what its preference is and the rationale for it.
>
> On Fri, 9 Aug 2024, Alejandro Vallejo wrote:
> > This warning only makes sense when developing using a compiler with C99
> > support on a codebase meant to be
Hi,
On Thu Aug 8, 2024 at 9:49 AM BST, Jan Beulich wrote:
> A few dozen lines down from here we repeatedly use a pattern involving
> just a single (conditional) branch. Do so also when checking for the
> boot loader magic value.
>
> Signed-off-by: Jan Beulich
> ---
> I further question the placem
Hi,
On Mon Aug 12, 2024 at 3:43 PM BST, Jan Beulich wrote:
> On 12.08.2024 16:34, Alejandro Vallejo wrote:
> > On Thu Aug 8, 2024 at 9:49 AM BST, Jan Beulich wrote:
> >> A few dozen lines down from here we repeatedly use a pattern involving
> >> just a single (condition
On Mon Aug 12, 2024 at 4:16 PM BST, Jan Beulich wrote:
> On 08.08.2024 15:41, Alejandro Vallejo wrote:
> > --- a/xen/arch/x86/domctl.c
> > +++ b/xen/arch/x86/domctl.c
> > @@ -1344,7 +1344,10 @@ void arch_get_info_guest(struct vcpu *v,
> > vcpu_guest_context_u c)
>
On Mon Aug 12, 2024 at 4:23 PM BST, Jan Beulich wrote:
> On 08.08.2024 15:41, Alejandro Vallejo wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -1164,10 +1164,25 @@ static int cf_check hvm_load_cpu_ctxt(struct domain
> >
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
---
v3:
* Reverse memcpy() and BUILD_BUG_ON()
* Use sizeof(a
the vcpu_setup_fpu() into 2 separate
functions. One to override x87/SSE state, and another to set a reset state.
=======
Alejandro Vallejo (2):
x86/fpu: Combine fpu_ctxt and xsave_area in arch_vcpu
x86/fpu: Split fpu_setu
(equivalent to the old function when it took a data
pointer).
While at it, make sure the abridged tag is consistent with the manuals and
start as 0xFF.
Signed-off-by: Alejandro Vallejo
---
v3:
* Adjust commit message, as the split is now in 3.
* Remove bulky comment, as the rationale for it
On Tue Aug 13, 2024 at 3:32 PM BST, Jan Beulich wrote:
> On 13.08.2024 16:21, 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 three.
> >
> >
s on support code for AMD and Intel CPUs respectively.
>
> Signed-off-by: Sergiy Kibrik
> CC: Alejandro Vallejo
> CC: Jan Beulich
> ---
> xen/arch/x86/Kconfig.cpu | 29 +
> xen/arch/x86/cpu/Makefile | 6 +++---
> xen/arch/x86/cpu/common.c |
On Fri Jul 26, 2024 at 4:21 PM BST, Roger Pau Monne wrote:
> Instead of allocating a monitor table for each vCPU when running in HVM HAP
> mode, use a per-pCPU monitor table, which gets the per-domain slot updated on
> guest context switch.
>
> This limits the amount of memory used for HVM HAP moni
On Fri Jul 26, 2024 at 4:22 PM BST, Roger Pau Monne wrote:
> So far L4 slot 260 has always been per-domain, in other words: all vCPUs of a
> domain share the same L3 entry. Currently only 3 slots are used in that L3
> table, which leaves plenty of room.
>
> Introduce a per-CPU L3 that's used the t
On Fri Aug 16, 2024 at 7:02 PM BST, Alejandro Vallejo wrote:
> On Fri Jul 26, 2024 at 4:21 PM BST, Roger Pau Monne wrote:
> > Instead of allocating a monitor table for each vCPU when running in HVM HAP
> > mode, use a per-pCPU monitor table, which gets the per-domain slot updated
&
On Fri Jul 26, 2024 at 4:21 PM BST, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 9cfcf0dc63f3..b62c4311da6c 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -555,6 +555,7 @@ void arch_vcpu_regs_init(struct vcpu *v)
> int arch_vc
On Wed Aug 21, 2024 at 5:07 PM BST, Jan Beulich wrote:
> On 21.08.2024 17:34, Matthew Barnes wrote:
> > Upon running `xen-cpuid -v` on a host machine with Sapphire Rapids
> > within Dom0, there exist unrecognised features.
> >
> > This patch adds these features as macros to the CPU featureset,
> >
On Fri Aug 23, 2024 at 6:05 PM BST, Javi Merino wrote:
> Despite its name, libxl_xen_console_read_line() does not read a line,
> it fills the buffer with as many characters as fit. Update the
> documentation to reflect the real behaviour of the function. Rename
> line_r to avoid confusion since i
I haven't read the entire series yet, but here's my .02 so far
On Fri Aug 30, 2024 at 10:46 PM BST, Daniel P. Smith wrote:
> From: Christopher Clark
>
> An initial step towards a non-multiboot internal representation of boot
> modules for common code, starting with x86 setup and converting the fi
Hi,
Ack and sure to everything on types, constness and variable names.
On 20/03/2024 10:15, Roger Pau Monné wrote:
>> +const char *name;
>> +uint32_t vcpu_id;
>> +uint32_t x2apic_id;
>> +struct cpu_policy policy;
>> +} tests[] = {
>> +{
>> +
Hi,
On 26/03/2024 16:41, Jan Beulich wrote:
> On 09.01.2024 16:38, Alejandro Vallejo wrote:
>> --- a/xen/lib/x86/policy.c
>> +++ b/xen/lib/x86/policy.c
>> @@ -2,15 +2,78 @@
>>
>> #include
>>
>> -uint32_t x86_x2apic_id_from_vcpu_id(const struct cp
On 26/03/2024 17:02, Jan Beulich wrote:
> On 09.01.2024 16:38, Alejandro Vallejo wrote:
>> --- a/tools/include/xenguest.h
>> +++ b/tools/include/xenguest.h
>> @@ -843,5 +843,20 @@ enum xc_static_cpu_featuremask {
>> XC_FEATUREMASK_HVM_HAP_DEF
On 02/05/2024 07:57, Jan Beulich wrote:
> On 02.05.2024 08:55, Jan Beulich wrote:
>> On 01.05.2024 18:35, Alejandro Vallejo wrote:
>>> Hi,
>>>
>>> On 26/03/2024 16:41, Jan Beulich wrote:
>>>> On 09.01.2024 16:38, Alejandro Vallejo wrote:
>>
policy and vCPU IDs
Patch 6: Includes a simple topology generator for toolstack so new guests
have topologically consistent information in CPUID
Alejandro Vallejo (8):
xen/x86: Add initial x2APIC ID to the per-vLAPIC save area
xen/x86: Simplify header dependencies in x86/hvm
x86/vlapic:
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.
---
xen/arch/x86/hvm/vlapic.c | 41 ---
1 file changed, 30 insertions(+), 11
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: Alejandro Vallejo
---
v2:
* New patch. Replaces adding cpu policy to hvmloader in v1.
---
tools/firmware/hvmloader/smp.c
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.
Signed-off-by: Alejandro Vallejo
---
v2:
* New patch. Extracted from v1/patch6
---
tools/tests/cpu-policy/test-cpu-pol
Expose sensible topologies in leaf 0xb. At the moment it synthesises non-HT
systems, in line with the previous code intent.
Signed-off-by: Alejandro Vallejo
---
v2:
* Zap the topology leaves of (pv/hvm)_(def/max)_policy rather than the host
policy
---
tools/libs/guest/xg_cpuid_x86.c | 62
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
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/x8
aders, 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 ++-
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: Ale
e stack.
>
> 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
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 + ((v)->vcp
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 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
>> ---
>>
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
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
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
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: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
>> +++
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
strict: PULL_POLICIES, 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
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
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,
>> +
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 = A
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 v
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 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.
Subject: [PATCH v3 0/2] *** SUBJECT HERE ***
*** BLURB HERE ***
Alejandro Vallejo (2):
tools/xg: Streamline cpu policy seriali
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() take
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
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 xc_x
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
>> f
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 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:
>> * New
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
201 - 300 of 707 matches
Mail list logo
