gt; x86/xen: remove unneeded dummy push from xen_hypercall_hvm()
>
> arch/x86/xen/xen-head.S | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
Reviewed-by: Andrew Cooper
On 05/02/2025 9:17 am, Jürgen Groß wrote:
> On 05.02.25 10:16, Andrew Cooper wrote:
>> On 05/02/2025 9:10 am, Juergen Gross wrote:
>>> xen_hypercall_hvm(), which is used when running as a Xen PVH guest at
>>> most only once during early boot, is clobbering %rbx. Dependin
On 05/02/2025 9:10 am, Juergen Gross wrote:
> xen_hypercall_hvm(), which is used when running as a Xen PVH guest at
> most only once during early boot, is clobbering %rbx. Depending on
> whether the caller relies on %rbx to be preserved across the call or
> not, this clobbering might result in an e
On 03/02/2025 8:58 am, Guillaume wrote:
> Oh cool, thanks a lot for the explanation.
> I added the "vzeroupper" and Xen crashes so it looks like the CPUID
> emulation is buggy. Also I was able to try it using a VM (same debian
> testing) running on virt-manager+kvm and it works fine (Xen in debug
>
On 22/01/2025 10:14 am, Frediano Ziglio wrote:
> Although code is compiled with -fpic option data is not position
> independent.
This doesn't parse. ITYM "Although the code is compiled with -fpic,
pointers in data are not position independent."
> This causes data pointer to become invalid if
>
On 04/02/2025 1:19 pm, Jan Beulich wrote:
> On 04.02.2025 14:10, Andrew Cooper wrote:
>> On 04/02/2025 1:03 pm, Jan Beulich wrote:
>>> --- a/xen/include/xen/radix-tree.h
>>> +++ b/xen/include/xen/radix-tree.h
>>> @@ -72,6 +72,9 @@ struct radix_tree_root {
nit()
> will zap the possible earlier introduction of segment 0 by
> amd_iommu_detect_one_acpi()'s call to pci_ro_device(), and thus the
> write-protection of the PCI devices representing AMD IOMMUs.
>
> Fixes: 3950f2485bbc ("x86/x2APIC: defer probe until after IOMMU ACPI tab
On 04/02/2025 8:36 am, Jan Beulich wrote:
> On 03.02.2025 17:58, Jan Beulich wrote:
>> On 03.02.2025 17:48, Andrew Cooper wrote:
>>> On 03/02/2025 4:26 pm, Jan Beulich wrote:
>>>> ... now that static initialization is possible. Use RADIX_TREE() for
&
On 03/02/2025 4:27 pm, Jan Beulich wrote:
> Have callers invoke pci_add_segment() directly instead. On x86 move the
> invocation back to acpi_mmcfg_init(), where it was prior to
> ("x86/PCI: init segments earlier").
> ---
Need a SoB.
I definitely prefer this version of the fix, but I
On 03/02/2025 4:38 pm, Oleksii Kurochko wrote:
> On 2/3/25 5:22 PM, Jan Beulich wrote:
>> The first two patches are functionally independent, and they're presented
>> here merely in the order I came to notice the respective issues. At least
>> patch 2 wants seriously considering for 4.20.
>>
>> Whi
On 03/02/2025 4:26 pm, Jan Beulich wrote:
> ... now that static initialization is possible. Use RADIX_TREE() for
> pci_segments and ivrs_maps.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
I'd not considered having RADIX_TREE() but it's nicer than my at
On 03/02/2025 4:25 pm, Jan Beulich wrote:
> They aren't used anymore.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Linux
> to gain RCU awareness").
>
> Positive side effect: Two cf_check go away.
Not only that, they can now be inlined, although you've merged them
directly.
>
> While there also convert xmalloc()+memset() to xzalloc(). (Don't convert
> to xvzalloc(), as that would require to
On 03/02/2025 3:53 pm, Jan Beulich wrote:
> On 03.02.2025 15:19, Andrew Cooper wrote:
>> On 03/02/2025 8:41 am, Jan Beulich wrote:
>>> On 02.02.2025 14:50, Andrew Cooper wrote:
>>>> On 30/01/2025 11:11 am, Jan Beulich wrote:
>>>>> While the 2nd of the c
On 03/02/2025 9:09 am, Jan Beulich wrote:
> On 02.02.2025 15:46, Andrew Cooper wrote:
>> On 30/01/2025 11:12 am, Jan Beulich wrote:
>>> In order for amd_iommu_detect_one_acpi()'s call to pci_ro_device() to
>>> have permanent effect, pci_segments_init() needs to
On 03/02/2025 1:03 pm, Jan Beulich wrote:
> On 03.02.2025 14:00, Jan Beulich wrote:
>> On 03.02.2025 13:45, Roger Pau Monné wrote:
>>> On Thu, Jan 30, 2025 at 12:12:31PM +0100, Jan Beulich wrote:
--- a/xen/arch/x86/x86_64/mmconfig-shared.c
+++ b/xen/arch/x86/x86_64/mmconfig-shared.c
On 03/02/2025 8:41 am, Jan Beulich wrote:
> On 02.02.2025 14:50, Andrew Cooper wrote:
>> On 30/01/2025 11:11 am, Jan Beulich wrote:
>>> While the 2nd of the commits referenced below should have moved the call
>>> to amd_iommu_msi_enable() instead of adding another on
On 03/02/2025 8:42 am, Jan Beulich wrote:
> On 02.02.2025 14:48, Andrew Cooper wrote:
>> This removes the unnecessary work of splitting a 32-bit number across
>> 4 registers, and recombining later. Bloat-o-meter reports:
>>
>> add/remove: 0/0 grow/shrink
On 02/02/2025 4:58 pm, Guillaume wrote:
> I attached the output of the `xl dmesg`. This is the 4.19.1 kernel I
> rebuild but I have the same issue with master (just for info).
Thanks. This is a TigerLake CPU, and:
> (XEN) Mitigating GDS by disabling AVX while virtualised - protections
> are best
-> 0003::0240:
> 8000: -> 8008:::
> 8001: -> ::0121:28100800
> 8002: -> 68743131:6e654720:746e4920:52286c65
> 8003: -> 6f432029:54286572:6920294d
This is a sanity check that an algorithm in Xen matches hardware. It is
only compiled into debug builds by default.
Given that you're running under virtualbox, i have a suspicion as to what's
wrong.
Can you collect the full `xen-cpuid -p` output from within your
environment? I don't believe you
On 30/01/2025 11:12 am, Jan Beulich wrote:
> In order for amd_iommu_detect_one_acpi()'s call to pci_ro_device() to
> have permanent effect, pci_segments_init() needs to be called ahead of
> making it there. Without this we're losing segment 0's r/o map, and thus
> we're losing write-protection of t
On 30/01/2025 11:13 am, Jan Beulich wrote:
> Despite all the verbosity with "iommu=debug", information on the IOMMUs
> themselves was missing.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 30/01/2025 11:11 am, Jan Beulich wrote:
> While the 2nd of the commits referenced below should have moved the call
> to amd_iommu_msi_enable() instead of adding another one, the situation
> wasn't quite right even before: It can't have done any good to enable
> MSI when no IRQ was allocated for
__pci_disable_msi178 146 -32
pci_cleanup_msi 268 229 -39
pci_enable_msi 10631019 -44
pci_restore_msi_state 11161034 -82
Signed-off-by: Andrew Cooper
---
CC
On 21/01/2025 4:57 pm, Oleksii Kurochko wrote:
>
> On 1/21/25 3:25 PM, Andrew Cooper wrote:
>> Logic using performance counters needs to look at
>> MSR_MISC_ENABLE.PERF_AVAILABLE before touching any other resources.
>>
>> When virtualised under ESX, Xen dies w
n-CX16 logic from interrupt remapping
> x86/iommu: remove non-CX16 logic from DMA remapping
> iommu/vtd: cleanup MAP_SINGLE_DEVICE and related code
Reviewed-by: Andrew Cooper
CC Oleksii. Patch 5 is a real bugfix that needs backporting, and the
prior patches have been in an almost-ready state for more than a release
now.
~Andrew
On 21/01/2025 5:04 pm, Jan Beulich wrote:
> On 21.01.2025 17:56, Andrew Cooper wrote:
>> --- a/xen/arch/x86/cpu/intel.c
>> +++ b/xen/arch/x86/cpu/intel.c
>> @@ -535,39 +535,49 @@ static void intel_log_freq(const struct cpuinfo_x86 *c)
>> printk("%u MHz\n&q
ce Counter Control is
setup correctly")
Reported-by: Jonathan Katz
Link: https://xcp-ng.org/forum/topic/10286/nesting-xcp-ng-on-esx-8
Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Oleksii Kurochko
v2:
* Drop _safe() on MSR_IA32_M
On 21/01/2025 4:44 pm, Jan Beulich wrote:
> Along the lines of 0e3642514719 ("x86: drop REX64_PREFIX"), move to well
> formed FXSAVEQ / FXRSTORQ here as well.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 21/01/2025 3:58 pm, Jan Beulich wrote:
> On 21.01.2025 16:23, Andrew Cooper wrote:
>> On 21/01/2025 3:03 pm, Jan Beulich wrote:
>>> On 21.01.2025 15:25, Andrew Cooper wrote:
>>>> + !(val & MSR_IA32_MISC_ENABLE_PERF_AVAIL) )
>>>> +
On 21/01/2025 3:03 pm, Jan Beulich wrote:
> On 21.01.2025 15:25, Andrew Cooper wrote:
>> Logic using performance counters needs to look at
>> MSR_MISC_ENABLE.PERF_AVAILABLE before touching any other resources.
>>
>> When virtualised under ESX, Xen dies with
o
the RHS), and insert a check of MSR_MISC_ENABLE.PERF_AVAILABLE.
This also limits setting X86_FEATURE_ARCH_PERFMON, although oprofile (the only
consumer of this flag) cross-checks too.
Reported-by: Jonathan Katz
Link: https://xcp-ng.org/forum/topic/10286/nesting-xcp-ng-on-esx-8
Signed-off-by: A
On 21/01/2025 9:57 am, Roger Pau Monne wrote:
> If using a 32bit Interrupt Remapping Entry or a 128bit one and the CPU
> supports 128bit cmpxchg don't disable the entry by setting RemapEn = 0
> ahead of updating it. As a consequence of not toggling RemapEn ahead of
> the update the Interrupt Remap
On 21/01/2025 9:57 am, Roger Pau Monne wrote:
> diff --git a/xen/drivers/passthrough/amd/iommu_intr.c
> b/xen/drivers/passthrough/amd/iommu_intr.c
> index 7fc796dec25b..efa9ddc62458 100644
> --- a/xen/drivers/passthrough/amd/iommu_intr.c
> +++ b/xen/drivers/passthrough/amd/iommu_intr.c
> @@ -223,1
ption such that first of all
>>>>>> C code using it can remain as is. This isn't just for less code churn,
>>>>>> but also because I think that symbol is more logical to use in many
>>>>>> (all?) places.
>>>>>>
>>>
leaner, and likely to have better longevity. Thanks.
Reviewed-by: Andrew Cooper
On 15/01/2025 3:09 pm, Bernhard Kaindl wrote:
> While skimming through the misc docs, I spotted a few typos.
>
> Signed-off-by: Bernhard Kaindl
> ---
> docs/misc/livepatch.pandoc| 8
specifc -> specific
perfomed -> performed
randezvous -> rendezvous
seperate -> separate (mul
nown-unused functionality which may
> be harmful, rather than disabling all functionality except that known
> to be safe and needed. This is unfortunately necessary since qemu
> doesn't know what system calls libraries might end up making. (See
Also assymetry -> asymmetry and constrants -> constraints.
I've folded these in.
Acked-by: Andrew Cooper
On 16/01/2025 8:58 am, Roger Pau Monne wrote:
> Add a new randconfig job for each FreeBSD version. This requires some
> rework of the template so common parts can be shared between the full and
> the randconfig builds. Such randconfig builds are relevant because FreeBSD
> is the only tested syste
On 16/01/2025 8:58 am, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
On 15/01/2025 1:57 pm, Bernhard Kaindl wrote:
> While skimming through the manual pages, I spotted a few typos.
>
> Signed-off-by: Bernhard Kaindl
Reviewed-by: Andrew Cooper
On 15/01/2025 4:27 pm, David Woodhouse wrote:
> diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
> index adfc4efad0..85b92cded4 100644
> --- a/hw/xen/xen-bus.c
> +++ b/hw/xen/xen-bus.c
> @@ -650,6 +650,16 @@ int xen_device_frontend_scanf(XenDevice *xendev, const
> char *key,
> return rc;
> }
public/memory.h:63: multiple definitions of Typedef xen_ulong_t:
include/public/arch-ppc.h:55
Drop the second typedef. Finally, annotate the #endif so it's clear
what it refers to.
Fixes: 08c192cc1127 ("xen/ppc: Add public/arch-ppc.h")
Signed-off-by: Andrew Cooper
---
CC: Shawn
On 15/01/2025 12:27 pm, Yann Dirson wrote:
> diff --git a/docs/.gitignore b/docs/.gitignore
> new file mode 100644
> index 00..0727c6d7cf
> --- /dev/null
> +++ b/docs/.gitignore
> @@ -0,0 +1,14 @@
> +/figs/*.png
> +/html/
> +/man/xl.cfg.5.pod
> +/man/xl-disk-configuration.5.pod
> +/man/xl-n
tignore
> docs/sphinx: gitignore generated files
Acked-by: Andrew Cooper
On 15/01/2025 12:07 pm, Yann Dirson wrote:
> ---
>
> Notes:
> This is a very preliminar first draft for comments:
>
> - would this structuration be adequate?
>
> - Is my basic understanding correct, are those first enumerations
> correct? (some of it come solely from conso
On 15/01/2025 12:47 pm, Bernhard Kaindl wrote:
> Skimming the docs, I came across a few places for spelling improvements.
>
> Signed-off-by: Bernhard Kaindl
Reviewed-by: Andrew Cooper
On 15/01/2025 12:01 pm, Yann Dirson wrote:
> Signed-off-by: Yann Dirson
> ---
> .gitignore | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/.gitignore b/.gitignore
> index 25484a8fd8..404590c36a 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -62,6 +62,7 @@ docs/man5/
> docs/man7/
> d
On 15/01/2025 12:01 pm, Yann Dirson wrote:
> Signed-off-by: Yann Dirson
> ---
> docs/conf.py | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/docs/conf.py b/docs/conf.py
> index 5d2e979449..84bec024e7 100644
> --- a/docs/conf.py
> +++ b/docs/conf.py
> @@ -21,6 +21,7 @@
> #
> https://www
On 15/01/2025 11:27 am, Jan Beulich wrote:
> On 15.01.2025 11:42, Bernhard Kaindl wrote:
>> --- a/docs/admin-guide/microcode-loading.rst
>> +++ b/docs/admin-guide/microcode-loading.rst
>> @@ -20,7 +20,7 @@ distro guidance for microcode loading.
>> Microcode can make almost arbitrary changes to the
On 15/01/2025 8:19 am, Jan Beulich wrote:
> On 14.01.2025 18:43, Roger Pau Monne wrote:
>> If randconfig enables coverage support the build times out due to GNU LD
>> taking too long. For the time being prevent coverage from being enabled in
>> clang randconfig job.
> Just curious: How long is "to
On 14/01/2025 7:50 pm, Ayan Kumar Halder wrote:
> diff --git a/docs/fusa/reqs/product-reqs/version_hypercall.rst
> b/docs/fusa/reqs/product-reqs/version_hypercall.rst
> new file mode 100644
> index 00..fdb8da04e1
> --- /dev/null
> +++ b/docs/fusa/reqs/product-reqs/version_hypercall.rst
> @
On 14/01/2025 5:43 pm, Roger Pau Monne wrote:
> If randconfig enables coverage support the build times out due to GNU LD
> taking too long. For the time being prevent coverage from being enabled in
> clang randconfig job.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Andrew Coop
On 14/01/2025 1:47 pm, Jan Beulich wrote:
> On 14.01.2025 14:28, Andrew Cooper wrote:
>> On 14/01/2025 1:22 pm, Jan Beulich wrote:
>>> On 12.12.2024 02:17, Andrew Cooper wrote:
>>>> On 12/12/2024 12:13 am, Volodymyr Babchuk wrote:
>>>>> Hello Jan,
>
ksii Kurochko
> ---
> v2: Add call to libxl_dominfo_init() to vcpuset().
Reviewed-by: Andrew Cooper
On 14/01/2025 1:22 pm, Jan Beulich wrote:
> On 12.12.2024 02:17, Andrew Cooper wrote:
>> On 12/12/2024 12:13 am, Volodymyr Babchuk wrote:
>>> Hello Jan,
>>>
>>> Jan Beulich writes:
>>>
>>>> On 11.12.2024 03:04, Volodymyr Babchuk wrote:
&
On 13/01/2025 6:42 pm, Teddy Astie wrote:
> Solaris 11.4 tries
Is it only Solaris 11.4, or is the simply the one repro you had?
Have you reported a bug?
> to access this MSR on some Intel platforms without properly
> setting up a proper #GP handler, which leads to a immediate crash.
Minor gram
otector feature
Reviewed-by: Andrew Cooper
There's one minor formatting error which can be fixed on commit.
~Andrew
On 14/01/2025 4:25 am, Volodymyr Babchuk wrote:
> diff --git a/xen/common/stack-protector.c b/xen/common/stack-protector.c
> new file mode 100644
> index 00..8fa9f6147f
> --- /dev/null
> +++ b/xen/common/stack-protector.c
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
y: Jan Beulich
Reviewed-by: Andrew Cooper
trace: Implement cpu mask range parsing of human
> values (-c)")
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 14/01/2025 8:12 am, Jan Beulich wrote:
> The ssid_label field requires separate freeing; make sure to call
> libxl_dominfo_dispose(). And then, for good measure, also
> libxl_dominfo_init().
>
> Coverity-ID: 1638727
> Coverity-ID: 1638728
> Fixes: c458c404da16 ("xl: use libxl_domain_info to get
On 01/01/2025 7:03 pm, Maximilian Engelhardt wrote:
> On Montag, 30. Dezember 2024 23:28:42 CET Maximilian Engelhardt wrote:
>> On Montag, 30. Dezember 2024 22:38:24 CET Andrew Cooper wrote:
>>> On 30/12/2024 9:00 pm, Maximilian Engelhardt wrote:
>>>> Use the soluti
e. This is additionally a problem as it can
> randomly make the documentation build non-reproducible.
>
> Signed-off-by: Maximilian Engelhardt
Acked-by: Andrew Cooper
On 10/01/2025 9:19 pm, Maximilian Engelhardt wrote:
> As suggested by Andrew Cooper in [1], I formally submit this patch for
> fixing that documentation hyperlinks may point to the wrong
> architecture. This fix also makes building the documentation
> reproducible in Debian.
>
&g
On 09/01/2025 3:53 pm, Jan Beulich wrote:
> On 09.01.2025 16:46, Andrew Cooper wrote:
>> On 09/01/2025 3:44 pm, Jan Beulich wrote:
>>> On 09.01.2025 16:39, Andrew Cooper wrote:
>>>> --- a/README
>>
This was recently identified as a hole in testing.
Signed-off-by: Andrew Cooper
---
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Anthony PERARD
CC: Oleksii Kurochko
https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/8820980201
---
automation/gitlab-ci/build.yaml | 6 ++
1 file
On 09/01/2025 3:30 pm, Frediano Ziglio wrote:
> On Thu, Jan 9, 2025 at 1:44 PM Andrew Cooper
> wrote:
>> On 09/01/2025 1:23 pm, Jan Beulich wrote:
>>> On 09.01.2025 14:15, Marek Marczykowski-Górecki wrote:
>>>> Xen compiled with -mtune=generic has .text align
On 09/01/2025 3:44 pm, Jan Beulich wrote:
> On 09.01.2025 16:39, Andrew Cooper wrote:
>> --- a/README
>> +++ b/README
&g
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Oleksii Kurochko
---
README | 16
SUPPORT.md | 2 +-
xen/Makefile | 2 +-
3 files changed, 10 insertions(+), 10
RC1 is scheduled for tomorrow (Jan 10th).
Andrew Cooper (2):
Config.mk: Pin QEMU_UPSTREAM_REVISION
Update Xen version to 4.20-rc
Config.mk| 2 +-
README | 16
SUPPORT.md | 2 +-
xen/Makefile | 2 +-
4 files changed, 11 insertions(+), 11 deletions(-)
base
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Oleksii Kurochko
---
Config.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Config.mk b/Config.mk
index fa0414055b93
On 09/01/2025 1:23 pm, Jan Beulich wrote:
> On 09.01.2025 14:15, Marek Marczykowski-Górecki wrote:
>> Xen compiled with -mtune=generic has .text alignment set to 64-bytes.
>> Having text_diff non-64-bytes-aligned breaks stuff:
>>
>> Traceback (most recent call last):
>> File
>> "/builddi
ge table entry flags. This assumption
>> does not work on PPC/radix where some flags go past 32-bits, so
>> introduce the pte_attr_t type to allow architectures to opt in to larger
>> types to store PTE flags.
>>
>> Suggested-by: Andrew Cooper
>> Signed-off-by: Shawn
On 08/01/2025 3:45 pm, Alejandro Vallejo wrote:
> Hi,
>
> On Wed Jan 8, 2025 at 3:23 PM GMT, Stewart Hildebrand wrote:
>> It appears the variable ffa_fw_version is only used in ffa.c. Was there
>> any rationale for exporting the symbol in 2f9f240a5e87 ("xen/arm: ffa:
>> Fine granular call support")
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Stefano Stabellini
CC: Michal Orzel
CC: Doug Goldstein
CC: Oleksii Kurochko
CC: Marek Marczykowski-Górecki
https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1616092048
---
.../fedora/{40-x86_64.dockerfile => 41-x86
On 30/12/2024 8:56 pm, Maximilian Engelhardt wrote:
> Hello,
>
> during working on packaging Xen in Debian I noticed the documentation becomes
> non-reproducible as hyperlinks may point to the wrong architecture.
>
> Here an example as diff showing the problem:
>
> /usr/share/doc/xen/html/hypercal
On 08/01/2025 7:16 am, Jan Beulich wrote:
> On 07.01.2025 18:18, Petr Beneš wrote:
>> On Tue, Jan 7, 2025 at 5:46 PM Jan Beulich wrote:
>>> Hmm ... Instead of you touching the bit in every one of the case blocks,
>>> I was expecting you to clear the bit ahead of the switch(), accepting a
>>> doubl
On 08/01/2025 9:15 am, Oleksii Kurochko wrote:
>
>
> On 12/31/24 8:20 PM, Andrew Cooper wrote:
>> AMD have always used the architectural MSRs for LER. As the first processor
>> to support LER was the K7 (which was 32bit), we can assume it's presence
>> unconditio
On 07/01/2025 3:41 pm, Jan Beulich wrote:
> On 07.01.2025 16:37, Andrew Cooper wrote:
>> On 07/01/2025 2:33 pm, Jan Beulich wrote:
>>> All selector fields under ctxt->regs are (normally) poisoned in the HVM
>>> case, and the four ones besides CS and SS are potentially
86emul: correct FPU code/data pointers and opcode
> handling")
> Reported-by: Andrew Cooper
> Signed-off-by: Jan Beulich
> ---
> The code comment may want adjusting in the course of FRED work.
It compiles when displacing my temporary patch in the FRED branch. I've
not
ns")
> Fixes: baf4a376f550 ("x86emul: support AVX512F legacy-equivalent scalar
> int/FP conversion insns")
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Fam1Ah is similar to Fam19h in these regards.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
v2:
* Update microcode size, based on the largest value I can find in the PPRs.
Defer updating amd_log_freq() for now. The MSR layout is different and rather
more complicated
On 06/01/2025 2:41 pm, Jan Beulich wrote:
> On 06.01.2025 15:19, Andrew Cooper wrote:
>> Fam1Ah is similar to Fam19h in these regards.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Roger Pau Monné
>>
>> With this patch, I
On 06/01/2025 2:28 pm, Jan Beulich wrote:
> On 03.01.2025 21:47, Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Roger Pau Monné
>>
>> An initial RFC discussion and plan. Open TODOs are at the end.
>>
&g
On 06/01/2025 3:17 pm, Jan Beulich wrote:
> On 06.01.2025 16:12, Andrew Cooper wrote:
>> On 06/01/2025 2:41 pm, Jan Beulich wrote:
>>> On 06.01.2025 15:19, Andrew Cooper wrote:
>>>> --- a/xen/arch/x86/cpu/microcode/amd.c
>>>> +++ b/xen/arch/x86/cpu/micro
On 06/01/2025 2:41 pm, Jan Beulich wrote:
> On 06.01.2025 15:19, Andrew Cooper wrote:
>> Fam1Ah is similar to Fam19h in these regards.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Roger Pau Monné
>>
>> With this patch, I
Fam1Ah is similar to Fam19h in these regards.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
With this patch, I think we're in an ok position to declare support on Zen5
CPUs. I'm very disappointed that AMD don't have any documetation about ERAPS,
but to
On 06/01/2025 10:29 am, Jan Beulich wrote:
> On 02.01.2025 20:25, Andrew Cooper wrote:
>> ... and hook it up for RISC-V and PPC.
>>
>> On RISC-V at least, no combination of headers pulls in errno.h, so include it
>> explicitly.
>>
>> Guard the hypercalls a
) is 2, causing more than
expected of the trampoline to be mapped. Cut it down just the single page it
ought to be.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
There's not an obvious candidate for a Fixes tag.
---
xen/arch/x86/x86_64/mm.c | 10 ++
1
On 06/01/2025 11:04 am, Jan Beulich wrote:
> These interfaces were - afaict - originally introduced this way on the
> firm assumption that the used array sizes would be good virtually
> forever. While this assumption turned out to not be true for at least
> some of them, this still doesn't really
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
An initial RFC discussion and plan. Open TODOs are at the end.
This can be viewed online at:
https://andrewcoop-xen.readthedocs.io/en/docs-devel/hypervisor-guide/x86/fred.html
I've got an 8-patch series doin
On 03/01/2025 2:25 pm, Fonyuy-Asheri Caleb wrote:
> Hello,
>
> I am interested in finding understanding how xen handles CPUID
> faulting and
> VM exits in general. Please can someone indicate to me the concerned
> files?
>
> I want to know how xen detects the execution of the CPUID instruction an
On 03/01/2025 12:42 am, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 03, 2025 at 01:18:31AM +0100, Marek Marczykowski-Górecki wrote:
>> On Thu, Jan 02, 2025 at 08:39:16PM +0100, Marek Marczykowski-Górecki wrote:
>>> On Thu, Jan 02, 2025 at 08:17:00PM +0100, Jürgen Groß wrote:
On 02.01.25 19
ns not to be, then perfc_incra() will fail it's bounds check
and do nothing.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
xen/arch/x86/pv/hypercall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/pv/hypercall.c b/xen/arch/x8
---
xen/Kconfig.debug | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index c4a8d86912e0..9bc4eb2df353 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -60,18 +60,12 @@ config DEBUG_LOCKS
checks will be pe
* Strip trailing whitspace.
* Remove PRIperfc. It has never been used and isn't useful.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
CC: Oleksii Kurochk
randconfig override.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
CC: Oleksii Kurochko
CC: Shawn Anastasio
---
automation/gitlab-ci/build.yaml | 1 -
xen/arch/ppc
re.
https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1609450793
Andrew Cooper (5):
xen/perfc: Drop arch_perfc_{gather,reset}()
xen/perfc: Add perfc_defn.h to asm-generic
xen/perfc: Trim includes
xen/perfc: Cleanup
xen/perfc: COMPILE TEST
automation/gitlab-ci/build.yaml |
1 - 100 of 6642 matches
Mail list logo
