-> uint64_t
* Remove extern keyword from function prototypes
No functional change.
Signed-off-by: Alejandro Vallejo
---
xen/common/pdx.c | 66 --
xen/include/xen/mm.h | 16 ++
xen/include/xen/pdx.h | 128 --
3 files chan
On Mon, Jun 19, 2023 at 05:30:20PM +0200, Jan Beulich wrote:
> > + * ma_{top,bottom}_mask is simply a shifted pfn_{top,pdx_bottom}_mask
> > where the
> > + * bottom one shifts in 1s rather than 0s.
> > + */
>
> Nit: That 2nd bottom variable is ma_va_bottom_mask.
Sure
>
> > @@ -57,9 +99,25 @@ ui
Sure, to everything before this
> > diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
> > index 168cd58f36..46b0cd8dbb 100644
> > --- a/xen/arch/x86/cpu/intel.c
> > +++ b/xen/arch/x86/cpu/intel.c
> > @@ -305,23 +305,23 @@ static void cf_check early_init_intel(struct
> > cpuinfo_x86
On Thu, Jun 22, 2023 at 11:15:17AM +0200, Jan Beulich wrote:
> >>> --- a/xen/include/xen/mm.h
> >>> +++ b/xen/include/xen/mm.h
> >>> @@ -31,6 +31,22 @@
> >>> * (i.e. all devices assigned to) a guest share a single DMA address
> >>> space
> >>> * and, by default, Xen will ensure dfn == pfn.
On Thu, Jun 22, 2023 at 03:28:14PM +0200, Jan Beulich wrote:
> > Unless I'm missing some non-obvious piece of the puzzle, I'd say that for a
> > truly general compressor we'd need some kind of loop over the hole mask.
>
> Well, further compression might be possible that way, yes, but that's
> enti
-> uint64_t
* Remove extern keyword from function prototypes
No functional change.
Signed-off-by: Alejandro Vallejo
---
v2:
* [pdx.h] Moved pdx_init_mask() after pdx_region_mask() so comments are
more self-documenting
(Jan feedback)
* [pdx.c] Rewrote ma_bottom_mask
On Mon, Jun 19, 2023 at 05:45:14PM +0200, Jan Beulich wrote:
> On 15.06.2023 17:48, Alejandro Vallejo wrote:
> > --- a/xen/arch/x86/cpu/microcode/amd.c
> > +++ b/xen/arch/x86/cpu/microcode/amd.c
> > @@ -432,9 +432,13 @@ static struct microcode_patch *cf_check
>
On Mon, Jun 19, 2023 at 05:57:14PM +0200, Jan Beulich wrote:
> > + * We might have exposed MSR_ARCH_CAPS after the microcode update.
>
> I'm struggling a little with this sentence, but not being a native speaker
> it may be me, not the sentence. I would perhaps have said "MSR_ARCH_CAPS
> may h
On Tue, Jun 20, 2023 at 11:51:00AM +0200, Jan Beulich wrote:
> On 15.06.2023 17:48, Alejandro Vallejo wrote:
> > --- a/xen/arch/x86/cpu/common.c
> > +++ b/xen/arch/x86/cpu/common.c
> > @@ -352,6 +352,11 @@ void __init early_cpu_init(void)
> >
On Thu, Jun 22, 2023 at 09:54:01AM +0200, Jan Beulich wrote:
> On 21.06.2023 18:43, Alejandro Vallejo wrote:
> > Sure, to everything before this
> >
> >>> diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
> >>> index 168cd58f36..46b0cd8
ff-by: Alejandro Vallejo
Reviewed-by: Jan Beulich
---
v4:
* Only remove the assumptions on handler contents from
microcode_update_one() and leave early_microcode_init() alone (Andrew)
---
xen/arch/x86/cpu/microcode/core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen
g
set then simply disable the "apply_microcode" handler so we can't even try
to perform update (as it's known to be silently dropped).
While at it, remove the Intel family check, as microcode loading is
supported on every Intel 64 CPU.
Signed-off-by: Alejandro Vallejo
---
v4:
Move MSR_ARCH_CAPS read code from tsx_init() to early_cpu_init(). Because
microcode updates might make them that MSR to appear/have different values
we also must reload it after a microcode update in early_microcode_init().
Signed-off-by: Alejandro Vallejo
---
v4:
* Read MSR_ARCH_CAPS in
Some hypervisors report ~0 as the microcode revision to mean "don't issue
microcode updates". Ignore the microcode loading interface in that case.
Signed-off-by: Alejandro Vallejo
Reviewed-by: Jan Beulich
---
v4:
* Stop piggybacking on the existing early exit
---
xen/arch/x8
3 Moves the MSR_ARCH_CAPS read in tsx_init() to early_cpu_init() and
early_microcode_init()
Patch 4 Adds the logic to detect microcode updates being disabled on Intel.
Alejandro Vallejo (4):
x86/microcode: Allow reading microcode revision even if it can't be
updated
x86/
it in boot_cpu_data. This prevents an
attacker with partial write support from affecting Xen's PTE generation
logic by overriding the NX feature flag. The patch asserts support for the
NX bit in PTEs at boot time and if so short-circuits the cpu_has_nx macro
to 1.
Alejandro Vallejo (3):
tools
o OFF for compatibility with previous
behaviour.
Signed-off-by: Alejandro Vallejo
Reviewed-by: Andrew Cooper
---
xen/arch/x86/Kconfig | 16
xen/arch/x86/boot/head.S | 15 ++-
xen/arch/x86/boot/trampoline.S| 3 ++-
xen/arch/x86/ef
: Alejandro Vallejo
---
tools/include/xen-tools/common-macros.h | 3 +++
tools/libs/light/libxl_internal.h | 2 --
tools/tests/x86_emulator/x86-emulate.h | 3 ---
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/tools/include/xen-tools/common-macros.h
b/tools/include/xen-tools
ecific
init path (as they are already done in early assembly). Keep a printk to
highlight the fact that NX was forcefully enabled.
Signed-off-by: Alejandro Vallejo
---
v3:
* In head.S: s/has_nx/got_nx and s/nx_bit/nx
* Style changes in assembly instructions (spaces + width modifiers)
* B
On Fri, Jun 23, 2023 at 09:33:56AM +0200, Jan Beulich wrote:
> On 22.06.2023 19:42, Alejandro Vallejo wrote:
> > --- a/xen/arch/x86/cpu/microcode/core.c
> > +++ b/xen/arch/x86/cpu/microcode/core.c
> > @@ -885,5 +885,18 @@ int __init early_microcode_init(unsigned long
> &g
Move MSR_ARCH_CAPS read code from tsx_init() to early_cpu_init(). Because
microcode updates might make them that MSR to appear/have different values
we also must reload it after a microcode update in early_microcode_init().
Signed-off-by: Alejandro Vallejo
---
v5:
* Re-run early_cpu_init
ff-by: Alejandro Vallejo
Reviewed-by: Jan Beulich
---
xen/arch/x86/cpu/microcode/core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/cpu/microcode/core.c
b/xen/arch/x86/cpu/microcode/core.c
index c3fee62906..bec8b55db2 100644
--- a/xen/arch/x86/cpu/microcode/c
g
set then simply disable the "apply_microcode" handler so we can't even try
to perform update (as it's known to be silently dropped).
While at it, remove the Intel family check, as microcode loading is
supported on every Intel 64 CPU.
Signed-off-by: Alejandro Vallejo
---
the logic to detect microcode updates being disabled on Intel.
Alejandro Vallejo (4):
x86/microcode: Allow reading microcode revision even if it can't be
updated
x86/microcode: Ignore microcode loading interface for revision = -1
x86: Read MSR_ARCH_CAPS immediately after early
Some hypervisors report ~0 as the microcode revision to mean "don't issue
microcode updates". Ignore the microcode loading interface in that case.
Signed-off-by: Alejandro Vallejo
Reviewed-by: Jan Beulich
---
v5:
* Style fix. Brace position.
---
xen/arch/x86/cpu/microc
On Thu, Jun 29, 2023 at 1:17 PM Alejandro Vallejo <
alejandro.vall...@cloud.com> wrote:
> v3:
> * Fixed a Gitlab CI breakage on older toolchains (patch 1)
> * Removed XD_DISABLE override logic from cpu/intel.c
> * Various style fixes to patch 2 (from Andrew's fe
On Thu, Jun 29, 2023 at 1:17 PM Alejandro Vallejo <
alejandro.vall...@cloud.com> wrote:
> Currently libxl and the x86-emulator tests carry their own versions. Factor
> those out into the common macros header so every library can make use of
> it. This is required so the followin
On Thu, Jun 29, 2023 at 1:17 PM Alejandro Vallejo <
alejandro.vall...@cloud.com> wrote:
> Intel CPUs have a bit in MSR_IA32_MISC_ENABLE that may prevent the NX bit
> from being advertised. Clear it unconditionally if we can't find the NX
> feature right away on boot.
>
&
On Thu, Jun 29, 2023 at 1:17 PM Alejandro Vallejo <
alejandro.vall...@cloud.com> wrote:
> This option hardens Xen by forcing it to write secure (NX-enhanced) PTEs
> regardless of the runtime NX feature bit in boot_cpu_data. This prevents an
> attacker with partial write support
On Wed, Jul 05, 2023 at 12:43:27PM +0200, Jan Beulich wrote:
> On 29.06.2023 17:26, Alejandro Vallejo wrote:
> > @@ -324,9 +324,10 @@ void __init early_cpu_init(void)
> > case X86_VENDOR_SHANGHAI: this_cpu = &shanghai_cpu_dev; break;
> > case X86_VENDOR_HYGON:
On Wed, Jul 05, 2023 at 02:12:58PM +0100, Alejandro Vallejo wrote:
> Something along this lines would be better?
> ```
> * Microcode updates may change CPUID or MSRs. We need to reload
> * the early subset boot_cpu_data before continuing. Notably
On Wed, Jul 05, 2023 at 12:51:47PM +0200, Jan Beulich wrote:
> > --- a/xen/arch/x86/cpu/microcode/intel.c
> > +++ b/xen/arch/x86/cpu/microcode/intel.c
> > @@ -385,6 +385,19 @@ static struct microcode_patch *cf_check
> > cpu_request_microcode(
> > return patch;
> > }
> >
> > +bool __init in
On Wed, Jul 05, 2023 at 04:30:02PM +0200, Jan Beulich wrote:
> (maybe with an adjustment to the comment, as mentioned in the
> earlier reply)
>
> Jan
Yes, that sounds good to me. Thanks.
Alejandro
On Thu, Jul 06, 2023 at 11:50:58AM +0200, Jan Beulich wrote:
> On 22.06.2023 16:02, Alejandro Vallejo wrote:
> > @@ -57,9 +100,25 @@ uint64_t __init pdx_init_mask(uint64_t base_addr)
> > (uint64_t)1 << (MAX_ORDER + PAGE_SHIFT)) - 1);
> &g
-> uint64_t
* Remove extern keyword from function prototypes
No functional change.
Signed-off-by: Alejandro Vallejo
---
v3:
* Exended the pdx=frametableindex definition also cover the directmap (to
the extent that it still applies to every port)
* [pdx.c] Removed auxiliary variable
On Mon, Jul 10, 2023 at 09:43:34AM +0200, Jan Beulich wrote:
> This is ...
> >>> [snip]
> >>> + * This is where compression becomes useful. The idea is to note that if
> >>> + * you have several big chunks of memory sufficiently far apart you can
> >>> + * ignore the middle part of the address beca
string.atoi() has been deprecated since Python 2.0, has a big scary warning
in the python2.7 docs and is absent from python3 altogether. int() does the
same thing and is compatible with both.
See https://docs.python.org/2/library/string.html#string.atoi:
Signed-off-by: Alejandro Vallejo
ID bits, rather than relying on models.
Alejandro Vallejo (2):
xen/x86: Add family guards to the is_zen[12]_uarch() macros
x86/amd: Prevent potentially fetching wrong instruction bytes on Zen4
xen/arch/x86/cpu/amd.c | 16 +---
xen/arch/x86/include/asm/amd.h | 17 ++
If Zen4 runs with SMT and without STIBP, then it may corrupt its own code
stream. This is erratum #1485 in the AMD specs.
Fix adapted off Linux's mailing list:
https://lore.kernel.org/lkml/d99589f4-bc5d-430b-87b2-72c20370c...@exactcode.com/T/#u
Signed-off-by: Alejandro Vallejo
---
xen
It slightly simplifies the code that uses them at no real cost because the
code is very rarely executed. This makes it harder to confuse zen uarches
due to missing or mistaken family checks.
No functional change intended.
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/cpu/amd.c | 5
Hi,
I'll just remove this patch (and amend the next) in the interest of having
it committed early. That said...
On Fri, Oct 13, 2023 at 10:14:45AM +0800, Andrew Cooper wrote:
> On 13/10/2023 1:26 am, Alejandro Vallejo wrote:
> > It slightly simplifies the code that uses them a
Fix adapted off Linux's mailing list:
https://lore.kernel.org/lkml/d99589f4-bc5d-430b-87b2-72c20370c...@exactcode.com/T/#u
Signed-off-by: Alejandro Vallejo
Release-acked-by: Henry Wang
---
v2:
* Removed v1/patch1, as it proved to be contentious
* Also changed is_zen[34]_uarch() i
On Fri, Oct 13, 2023 at 09:40:52PM +0800, Andrew Cooper wrote:
> On 13/10/2023 9:18 pm, Alejandro Vallejo wrote:
> > diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
> > index 4f27187f92..085c4772d7 100644
> > --- a/xen/arch/x86/cpu/amd.c
> > +++ b/xen/arch/x
Hi,
On Fri, Oct 13, 2023 at 03:41:49PM +0100, Julien Grall wrote:
> Hi Alejandro,
>
> The original e-mail didn't yet reach my inbox. So answering here as there
> are enough context.
>
> On 13/10/2023 15:33, Alejandro Vallejo wrote:
> > On Fri, Oct 13, 2023 at 09
Fix adapted off Linux's mailing list:
https://lore.kernel.org/lkml/d99589f4-bc5d-430b-87b2-72c20370c...@exactcode.com/T/#u
Signed-off-by: Alejandro Vallejo
Release-acked-by: Henry Wang
---
v3:
* Factored MSR shuffling into a separate function and moved the call to
the end of ini
The page is pretty nice overall and I quite liked it. Just a few extra
questions below, as I'm not familiar with this side of things,
On Mon, Oct 16, 2023 at 05:24:50PM +0100, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
> ---
> CC: George Dunlap
> CC: Jan Beulich
> CC: Stefano Stabellin
macro.
Signed-off-by: Alejandro Vallejo
---
@Daniel: I CC'd you due to the DECLARE_FLASK_OP removal, though it
shouldn't functionally affect anything at all.
The patch looks big, but all changes are reproducible via this snippet in
the "tools/libs" folder, followed by m
Hi,
On Mon, Nov 06, 2023 at 11:58:52AM +0100, Olaf Hering wrote:
> Mon, 6 Nov 2023 08:19:46 +0000 Alejandro Vallejo
> :
>
> > +struct xen_sysctl sysctl = {0};
>
> What is that zero doing here?
Some context:
https://gcc.gnu.org/legacy-ml/gcc/2019-07/msg0
On Mon, Nov 06, 2023 at 11:29:57AM +, Andrew Cooper wrote:
> On 06/11/2023 10:58 am, Olaf Hering wrote:
> > Mon, 6 Nov 2023 08:19:46 + Alejandro Vallejo
> > :
> >
> >> +struct xen_sysctl sysctl = {0};
> > What is that zero doing here? I
macro.
Signed-off-by: Alejandro Vallejo
---
@Daniel: I CC'd you due to the DECLARE_FLASK_OP removal, though it
shouldn't functionally affect anything at all.
The patch looks big, but all changes are reproducible via this snippet in
the "tools/libs" folder, followed by m
onion be vulnerable.
Signed-off-by: Alejandro Vallejo
---
tools/pygrub/src/pygrub | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
index 541e562327..08540ad288 100755
--- a/tools/pygrub/src/pygrub
+++ b/tools
ystem.
A convenient usability side-effect is that it's no longer required for the
restricted user to have access to the disk, because the depriv thread
already has the file descriptor open by its parent.
Signed-off-by: Alejandro Vallejo
---
docs/man/xl.cfg.5.pod.in | 6 +-
tools/
Create a wrapper for the new fdopen() function of libfsimage.
Signed-off-by: Alejandro Vallejo
---
tools/pygrub/src/fsimage/fsimage.c | 33 ++
1 file changed, 33 insertions(+)
diff --git a/tools/pygrub/src/fsimage/fsimage.c
b/tools/pygrub/src/fsimage/fsimage.c
: Modifies the python bindings to grant access to the new interface
Patch 6: Modifies pygrub to open every required file before depriv.
Alejandro Vallejo (6):
tools/pygrub: Set mount propagation to private recursively
tools/pygrub: Fix bug in LIMIT_FSIZE env variable override
tools/pygrub
Prevents the depriv pygrub from consuming more than a fixed amount of
memory.
Signed-off-by: Alejandro Vallejo
---
tools/pygrub/src/pygrub | 10 ++
1 file changed, 10 insertions(+)
diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
index 327cf51774..b96bdfd849 100755
--- a
The env variable must be interpreted as an integer. As it is, the override
logic simply causes an exception.
Signed-off-by: Alejandro Vallejo
---
tools/pygrub/src/pygrub | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
index
file descriptor they want to
preserve past the lifetime of the fsi_t* objects that use them.
Signed-off-by: Alejandro Vallejo
---
tools/libfsimage/common/fsimage.c | 42 +++--
tools/libfsimage/common/fsimage_grub.c | 2 +-
tools/libfsimage/common/fsimage_plugin
t this, make a minor change to MSR_MAX_SERIALISED_ENTRIES so it's
unsigned in order to please the max() macro.
Signed-off-by: Alejandro Vallejo
---
tools/include/xenguest.h | 2 +-
tools/libs/guest/xg_cpuid_x86.c | 86 +---
tools/libs/guest/xg_private.h| 17 +-
patch where modifications are done in the
serialized form and we don't want to do a serialization round-trip to
send it to Xen.
Signed-off-by: Alejandro Vallejo
---
tools/include/xenguest.h| 8 ++--
tools/libs/guest/xg_cpuid_x86.c | 24 ++--
tools/tests/tsx
With the policy automatically getting appropriate serialised buffer sizes,
we can remove boilerplate from this function. Furthermore, the extra
dynamic allocations aren't needed anymore as the serialised buffers inside
the policy can be used instead.
Signed-off-by: Alejandro Vallejo
---
them.
Furthermore, the ultimate reapplication of the policy to the domain in Xen
is done only once after both CPUID and MSRs have been fixed up.
BUG!!! apply_policy is sending the policy after deserialise when it poked
at it in its serialised form.
Signed-off-by: Alejandro Vallejo
---
tools/libs
ation routine.
Patch 6: Remove code duplication in the xend-style override setters
Patch 7: Final cleanup so the get_cpu_policy wrappers can operate on policy
objects directly
Alejandro Vallejo (7):
tools/xenguest: Dynamically allocate xc_cpu_policy_t contents
tools
Instantiates host, default and domain policies in order to clean up a lot
of boilerplate hypercalls. This is partial work in order to deduplicate
the same hypercalls being used when updating CPUID and MSR parts of the
policy.
Signed-off-by: Alejandro Vallejo
---
tools/include/xenguest.h
These allow a policy to internally (de)serialize itself, so that we don't
have to carry around serialization buffers when perfectly good ones are
present inside.
Both moved on top of the xend overrides as they are needed there in future
patches
Signed-off-by: Alejandro Vallejo
---
tools
: Alejandro Vallejo
---
tools/libs/guest/xg_cpuid_x86.c | 59 -
1 file changed, 22 insertions(+), 37 deletions(-)
diff --git a/tools/libs/guest/xg_cpuid_x86.c b/tools/libs/guest/xg_cpuid_x86.c
index e2a2659953..cf07a69764 100644
--- a/tools/libs/guest/xg_cpuid_x86.c
+++ b
Hi,
On Tue, Nov 07, 2023 at 08:15:32PM +, Andrew Cooper wrote:
> On 07/11/2023 7:53 pm, Elliott Mitchell wrote:
> > I ran into the nestedhvm via the following path. I was considering the
> > feasibility of shedding tasks from a desktop onto a server running Xen.
> > I was looking at `man xl.c
On Thu, Nov 09, 2023 at 10:36:21AM +, Andrew Cooper wrote:
> On 09/11/2023 9:50 am, Alejandro Vallejo wrote:
> > Hi,
> >
> > On Tue, Nov 07, 2023 at 08:15:32PM +, Andrew Cooper wrote:
> >> On 07/11/2023 7:53 pm, Elliott Mitchell wrote:
> >>> I ran
On Mon, Nov 13, 2023 at 03:20:53PM +, Luca Fancellu wrote:
>
>
> > On 13 Nov 2023, at 11:31, Jan Beulich wrote:
> >
> > On 08.11.2023 10:53, Luca Fancellu wrote:
> > -
neighborhood, replace the u32 type with the standard uint32_t
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/hvm/vlapic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index c7ce82d064..5a74e84445 100644
--- a
On Mon, Nov 13, 2023 at 06:53:00PM +0100, Roger Pau Monné wrote:
> On Mon, Nov 13, 2023 at 04:50:23PM +0000, Alejandro Vallejo wrote:
> > Both Intel and AMD manuals agree that on x2APIC mode, the APIC LDR and ID
> > registers are derivable from each other through a fixed formula.
&g
On Tue, Nov 14, 2023 at 11:14:22AM +0100, Jan Beulich wrote:
> On 13.11.2023 18:53, Roger Pau Monné wrote:
> > On Mon, Nov 13, 2023 at 04:50:23PM +, Alejandro Vallejo wrote:
> >> Both Intel and AMD manuals agree that on x2APIC mode, the APIC LDR and ID
> >> regist
Hi,
On Tue, Nov 14, 2023 at 03:11:28PM +0100, Roger Pau Monné wrote:
> On Tue, Nov 14, 2023 at 12:55:46PM +, Andrew Cooper wrote:
> > On 14/11/2023 12:32 pm, Jan Beulich wrote:
> > > On 14.11.2023 13:18, Alejandro Vallejo wrote:
> > >> On Tue, Nov 14, 2023 at
Hi,
On Tue, Nov 14, 2023 at 02:59:35PM +, Luca Fancellu wrote:
>
>
> > On 13 Nov 2023, at 16:27, Jan Beulich wrote:
> >
> > On 13.11.2023 16:20, Luca Fancellu wrote:
> >>> On 13 Nov 2023, at 11:31, Jan Beulich wrote:
> >>> On 08.11.2023 10:53, Luca Fancellu wrote:
> >>> --
Hi,
On Wed, Nov 15, 2023 at 11:43:46AM +, Kelly Choi wrote:
> Hi all,
>
> As you may be aware, we are in the process of reviewing our existing
> documentation platform and content. In order to meet the requirements of
> the community and project, I need your input and feedback.
>
> The aim o
also covers migrations from broken hypervisors, so LDRs are
preserved even for hotppluggable CPUs and across APIC resets.
Fixes: f9e0cccf7b35 ("x86/HVM: fix ID handling of x2APIC emulation")
Signed-off-by: Alejandro Vallejo
---
I tested this by creating 3 checkpoints.
1. One with pre-
On Tue, Nov 21, 2023 at 04:26:04PM +, Alejandro Vallejo wrote:
> Both Intel and AMD manuals agree that on x2APIC mode, the APIC LDR and ID
> registers are derivable from each other through a fixed formula.
>
> Xen uses that formula, but applies it to vCPU IDs (which are sequenti
On 11/03/2024 11:01, Andrew Cooper wrote:
> On 11/03/2024 10:54 am, Roger Pau Monne wrote:
>> The current logic to detect when to switch to the next L1 table is
>> incorrectly
>> using l2_table_offset() in order to notice when the last entry on the current
>> L1 table has been reached.
>>
>> It sh
Hi,
On 14/03/2024 13:50, Jan Beulich wrote:
> On 13.03.2024 16:35, Matthew Barnes wrote:
>> libacpi is a tool that is used by libxl (for PVH guests) and hvmloader
>> (for HVM guests) to construct ACPI tables for guests.
>>
>> Currently, libacpi only uses APIC entries to enumerate processors for
>>
Hi,
I'll answer the policy-related feedback in the next email, as you
corrected yourself for that.
On 19/03/2024 16:20, Roger Pau Monné wrote:
> On Tue, Jan 09, 2024 at 03:38:29PM +, Alejandro Vallejo wrote:
>> This allows the initial x2APIC ID to be sent on the migrati
On 20/03/2024 09:33, Roger Pau Monné wrote:
>>
>> Why not just return the x2apic_id field from the cpu_policy object?
>> (topo.subleaf[X].x2apic_id)
>
> Scratch that, the cpu policy is per-domain, not per-vcpu, and hence
> cannot hold the x{,2}apic IDs.
Yes, that :)
Originally I tried to make the
Hi,
On 25/03/2024 16:45, Jan Beulich wrote:
> On 09.01.2024 16:38, Alejandro Vallejo wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -288,7 +288,10 @@ void update_guest_memory_policy(struct vcpu *v,
>> static void cpu_policy_updated(struc
On 19/03/2024 17:55, Roger Pau Monné wrote:
> On Tue, Jan 09, 2024 at 03:38:30PM +0000, Alejandro Vallejo wrote:
>> Move struct xc_cpu_policy data structure out of xg_private.h and into
>> the public xenguest.h so it can be used by libxl.
>
> I will let Andrew comment
On Wed, Nov 22, 2023 at 02:40:02PM +0100, Roger Pau Monné wrote:
> On Tue, Nov 21, 2023 at 04:26:04PM +0000, Alejandro Vallejo wrote:
> > Both Intel and AMD manuals agree that on x2APIC mode, the APIC LDR and ID
> > registers are derivable from each other through a fixed formula.
&g
e) and put another printk as an else
branch so we get warnings trying to load nonsensical LDR values we don't
know about.
Fixes: f9e0cccf7b35 ("x86/HVM: fix ID handling of x2APIC emulation")
Signed-off-by: Alejandro Vallejo
---
v3:
* Removed underscores from (x2)APIC_ID in commit mes
On Wed, Nov 22, 2023 at 04:08:17PM +, Alejandro Vallejo wrote:
> Both Intel and AMD manuals agree that on x2APIC mode, the APIC LDR and ID
> registers are derivable from each other through a fixed formula.
>
> Xen uses that formula, but applies it to vCPU IDs (which are sequenti
Hi, while rebasing with something else I noticed that...
On Tue, Nov 07, 2023 at 03:49:20PM +, Alejandro Vallejo wrote:
> Remove all duplication in CPUID and MSR xend-style overrides. They had an
> incredible amount of overhead for no good reason.
>
> After this patch, CPU policy
On Thu, Nov 23, 2023 at 10:03:12AM +0100, Roger Pau Monné wrote:
> On Wed, Nov 22, 2023 at 04:08:17PM +0000, Alejandro Vallejo wrote:
> > Both Intel and AMD manuals agree that on x2APIC mode, the APIC LDR and ID
> > registers are derivable from each other through a fixed formula.
&g
On 22/11/2023 19:48, Andrew Cooper wrote:
On 22/11/2023 7:46 pm, Andrew Cooper wrote:
On 06/11/2023 3:05 pm, Alejandro Vallejo wrote:
This is important in order for every mount done inside a mount namespace to
go away after the namespace itself goes away. The comment referring to
unreliability
On 22/11/2023 20:07, Andrew Cooper wrote:
This has an identical meaning, and is the more pythonic way of writing it.
Signed-off-by: Andrew Cooper
---
CC: Wei Liu
CC: Anthony PERARD
CC: Alejandro Vallejo
---
tools/pygrub/src/pygrub | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On 22/11/2023 22:29, Andrew Cooper wrote:
On 06/11/2023 3:05 pm, Alejandro Vallejo wrote:
diff --git a/tools/libfsimage/common/fsimage_priv.h
b/tools/libfsimage/common/fsimage_priv.h
index 2274403557..779e433b37 100644
--- a/tools/libfsimage/common/fsimage_priv.h
+++ b/tools/libfsimage/common
On 23/11/2023 16:50, Alejandro Vallejo wrote:
On 22/11/2023 20:07, Andrew Cooper wrote:
This has an identical meaning, and is the more pythonic way of writing
it.
Signed-off-by: Andrew Cooper
---
CC: Wei Liu
CC: Anthony PERARD
CC: Alejandro Vallejo
---
tools/pygrub/src/pygrub | 2 +-
1
On 22/11/2023 20:16, Andrew Cooper wrote:
On 06/11/2023 3:05 pm, Alejandro Vallejo wrote:
diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
index 327cf51774..b96bdfd849 100755
--- a/tools/pygrub/src/pygrub
+++ b/tools/pygrub/src/pygrub
@@ -75,6 +80,11 @@ def downgrade_rlimits
On 22/11/2023 22:35, Andrew Cooper wrote:
On 06/11/2023 3:05 pm, Alejandro Vallejo wrote:
Create a wrapper for the new fdopen() function of libfsimage.
Signed-off-by: Alejandro Vallejo
I'd appreciate it if Marek would cast his eye (as python maintainer)
over it.
That said, ...
diff
e) and put another printk as an else
branch so we get warnings trying to load nonsensical LDR values we don't
know about.
Fixes: f9e0cccf7b35 ("x86/HVM: fix ID handling of x2APIC emulation")
Signed-off-by: Alejandro Vallejo
Reviewed-by: Roger Pau Monné
---
v4:
* Removed &q
On 24/11/2023 11:43, Ross Lagerwall wrote:
> On Thu, Nov 23, 2023 at 4:08 PM Roger Pau Monne
wrote:
>>
>> And instead use plain awk.
>>
>> There's no need to use the --non-decimal-data option for gawk, since the
>> numbers that we want to print are already prefixed with '0x', and so
plain awk
( lock->profile )
-{
-lock->profile->time_block += NOW() - block;
-lock->profile->block_cnt++;
-}
-#endif
+LOCK_PROFILE_BLKACC(lock->profile, block);
}
smp_mb();
}
Besides the first nit, the others were already present and
the usage of the
On 24/11/2023 17:59, Alejandro Vallejo wrote:
Hi,
On 20/11/2023 11:38, Juergen Gross wrote:> With some small adjustments
to the LOCK_PROFILE_* macros some #ifdefs
can be dropped from spinlock.c.
Signed-off-by: Juergen Gross
---
V2:
- new patch
V3:
- add variable name to macros parame
On 20/11/2023 11:38, Juergen Gross wrote:
Introduce a new type "rspinlock_t" to be used for recursive spinlocks.
For now it is only an alias of spinlock_t, so both types can still be
used for recursive spinlocks. This will be changed later, though.
Switch all recursive spinlocks to the new type
On 20/11/2023 11:38, Juergen Gross wrote:
Instead of special casing rspin_lock_irqsave() and
rspin_unlock_irqrestore() for the console lock, add those functions
to spinlock handling and use them where needed.
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
xen/arch/x86/traps.c | 14
block_cnt; /* # of complete wait for lock */
+uint64_tblock_cnt:63; /* # of complete wait for lock */
+uint64_tis_rlock:1; /* use rlock pointer */
s_time_ttime_hold; /* cumulated lock time */
s_time_ttime_block; /* cumulated wait time */
s_time_ttime_locked; /* system time of last locking */
LGTM.
Acked-by: Alejandro Vallejo
Cheers,
Alejandro
401 - 500 of 707 matches
Mail list logo
