Provide support for this insn, which is a prereq to FRED. CPUID-wise
introduce both its, FRED's, and the NMI_SRC bit at this occasion, thus
allowing to also express the dependency right away.
While adding a testcase, also add a SWAPGS one. In order to not affect
the behavior of pre-existing tests,
Move the PKS check into an "else" for the corresponding "if()", such
that further adjustments (like for USER_MSR) can easily be put there as
well.
Signed-off-by: Jan Beulich
---
v5: Re-base.
v4: New.
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -777,19 +777,20 @@ static voi
As we ignore cachability aspects of insns, they're treated like simple
MOVs.
Signed-off-by: Jan Beulich
---
SDE: -dmr
---
v7: New.
--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -843,6 +843,9 @@ static const struct {
{ { 0x80 }, { 2, 2 }, T, R, pf
Hook up the new VM exit codes and handle guest accesses, context switch,
and save/restore. At least for now don't allow the guest direct access
to the control MSR; this may need changing if guests were to frequently
access it (e.g. on their own context switch path).
While there also correct a one-
1: x86emul: support LKGS
2: x86emul+VMX: support {RD,WR}MSRLIST
3: x86emul: support USER_MSR instructions
4: x86/cpu-policy: re-arrange no-VMX logic
5: VMX: support USER_MSR
6: x86emul: support MSR_IMM instructions
7: x86emul: support non-SIMD MOVRS
Due to lack of specification the VMX counterpart
On 17/06/2025 19:13, Alejandro Vallejo wrote:
> The DT spec declares only two number types for a property: u32 and u64,
> as per Table 2.3 in Section 2.2.4. Remove unbounded loop and replace
> with a switch statement. Default to a size of 1 cell in the nonsensical
> size case, with a warning pri
On 10.06.2025 15:05, Oleksii Kurochko wrote:
> Instruct the remote harts to execute one or more HFENCE.GVMA instructions,
> covering the range of guest physical addresses between start_addr and
> start_addr + size for all the guests.
Here and in the code comment: Why "for all the guests"? Under wh
On Fri, Jun 06, 2025 at 02:27:09PM -0700, victorm.l...@amd.com wrote:
> From: Nicola Vetrini
>
> The marked functions never return to their caller, but lack the
> `noreturn' attribute.
>
> Functions that never return should be declared with a `noreturn'
> attribute.
>
> The lack of `noreturn' c
On 10.06.2025 15:05, Oleksii Kurochko wrote:
> It instructs the remote harts to execute one or more HFENCE.GVMA instructions
> by making an SBI call, covering the range of guest physical addresses between
> start_addr and start_addr + size only for the given VMID.
>
> This function call is only va
On 11.06.2025 19:16, Roger Pau Monne wrote:
> With the appearance of Intel Sierra Forest and Granite Rapids it's not
> possible to get a production x86 host wit the following memory map:
>
> SRAT: Node 0 PXM 0 [, 7fff]
> SRAT: Node 0 PXM 0 [0001, 00407ff
On 10.06.2025 15:05, Oleksii Kurochko wrote:
> Introduce the following things:
> - Update p2m_domain structure, which describe per p2m-table state, with:
> - lock to protect updates to p2m.
> - pool with pages used to construct p2m.
> - clean_pte which indicate if it is requires to clean the
On 2025-06-18 17:18, Roger Pau Monné wrote:
On Fri, Jun 06, 2025 at 02:27:09PM -0700, victorm.l...@amd.com wrote:
From: Nicola Vetrini
The marked functions never return to their caller, but lack the
`noreturn' attribute.
Functions that never return should be declared with a `noreturn'
attribu
Hi Oleksii,
On 19/05/2025 16:50, Oleksii Moisieiev wrote:
This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A
(TF-A) which provides SCMI interface with multi-agnet support, as shown
s/multi-agnet/multi-agent/
below.
+-+
|
Hi,
On 18/06/2025 00:38, Stefano Stabellini wrote:
On Thu, 12 Jun 2025, Grygorii Strashko wrote:
On 02.06.25 10:17, Bertrand Marquis wrote:
On the other hand, if we also want to handle the case where the SCMI
server could be on a separate co-processor, then what this code is doing
is not suffi
Hi Michal,
On 18/06/2025 08:06, Orzel, Michal wrote:
On 17/06/2025 19:13, Alejandro Vallejo wrote:
The DT spec declares only two number types for a property: u32 and u64,
as per Table 2.3 in Section 2.2.4. Remove unbounded loop and replace
with a switch statement. Default to a size of 1 cell
These are "compound" instructions to issue a series of RDMSR / WRMSR
respectively. In the emulator we can therefore implement them by using
the existing msr_{read,write}() hooks. The memory accesses utilize that
the HVM ->read() / ->write() hooks are already linear-address
(x86_seg_none) aware (by
Hi,
At 2025-06-13 17:00:21, "Thomas Zimmermann" wrote:
>Add drm_modes_size_dumb(), a helper to calculate the dumb-buffer
>scanline pitch and allocation size. Implementations of struct
>drm_driver.dumb_create can call the new helper for their size
>computations.
>
>There is currently quite a bit
Encoding-wise these are very similar to URDMSR/UWRMSR, so existing logic
is easy to extend.
Signed-off-by: Jan Beulich
---
RFC only for now, as the VMX part is missing: The existing intercepts
can't be re-used unmodified, as those require the MSR index to be
fetched from guest ECX.
---
v8: Don't
On 28.05.2025 11:16, Penny Zheng wrote:
> We move the following functions into drivers/acpi/pmstat.c, as they
> are all designed for performance statistic:
> - cpufreq_residency_update()
> - cpufreq_statistic_reset()
> - cpufreq_statistic_update()
> - cpufreq_statistic_init()
> - cpufreq_statistic_
On 10.06.2025 15:05, Oleksii Kurochko wrote:
> @@ -18,10 +20,20 @@ struct arch_vcpu_io {
> struct arch_vcpu {
> };
>
> +struct paging_domain {
> +spinlock_t lock;
> +/* Free P2M pages from the pre-allocated P2M pool */
> +struct page_list_head p2m_freelist;
> +/* Number of pages
On 10.06.2025 15:05, Oleksii Kurochko wrote:
> Implementation is based on Arm code with some minor changes:
> - Re-define INVALID_VMID.
> - Re-define MAX_VMID.
> - Add TLB flushing when VMID is re-used.
>
> Also, as a part of this path structure p2m_domain is introduced with
> vmid member insid
Take care of the multiplication(s) involved in determining overall size
in the macros themselves, saturating to ULONG_MAX. This way on 64-bit
systems the subsequent check against UINT_MAX will fail, while on 32-
bit systems allocations of this size simply cannot be fulfilled anyway
(such an allocat
On 12.06.2025 11:29, Jiqian Chen wrote:
> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -83,6 +83,88 @@ static int assign_virtual_sbdf(struct pci_dev *pdev)
>
> #endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
>
> +static struct vpci_register *vpci_get_register(struct vpci *vpci
On 12.06.2025 11:29, Jiqian Chen wrote:
> +static int vpci_ext_capability_hide(struct pci_dev *pdev, unsigned int cap)
> +{
> +const unsigned int offset = pci_find_ext_capability(pdev->sbdf, cap);
> +struct vpci_register *r, *prev_r;
> +struct vpci *vpci = pdev->vpci;
> +uint32_t he
On 12.06.2025 11:29, Jiqian Chen wrote:
> --- a/xen/include/xen/vpci.h
> +++ b/xen/include/xen/vpci.h
> @@ -13,11 +13,12 @@ typedef uint32_t vpci_read_t(const struct pci_dev *pdev,
> unsigned int reg,
> typedef void vpci_write_t(const struct pci_dev *pdev, unsigned int reg,
>
On 12.06.2025 11:29, Jiqian Chen wrote:
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -836,6 +836,42 @@ static int vpci_init_capability_list(struct pci_dev
> *pdev)
>PCI_STATUS_RSVDZ_MASK);
> }
>
> +static int vpci_init_ext_capabili
On 12.06.2025 11:29, Jiqian Chen wrote:
> --- a/xen/drivers/vpci/msi.c
> +++ b/xen/drivers/vpci/msi.c
> @@ -193,6 +193,33 @@ static void cf_check mask_write(
> msi->mask = val;
> }
>
> +static int cf_check cleanup_msi(struct pci_dev *pdev)
> +{
> +int rc;
> +unsigned int end, size;
See the respective bullet point in the Caveats section of
https://gcc.gnu.org/gcc-15/changes.html.
While I'm unaware of us currently relying on the pre-gcc15 behavior,
let's still play safe and retain what unknowingly we may have been
relying upon.
According to my observations, on x86 generated c
On 18/06/2025 11:35 am, Jan Beulich wrote:
> Both c6e0a5539623 ("cpufreq: use existing local var in
> cpufreq_statistic_init()") and a1ce987411f6 ("cpufreq: don't leave stale
> statistics pointer") were lost in the course of "moving" the code,
> presumably due to overly lax re-basing.
>
> Fixes: bf
On 16.06.2025 19:23, Roger Pau Monné wrote:
> On Mon, Jun 16, 2025 at 06:02:07PM +0200, Jan Beulich wrote:
>> On 16.06.2025 17:41, Roger Pau Monné wrote:
>>> On Mon, Jun 16, 2025 at 05:20:45PM +0200, Jan Beulich wrote:
On 16.06.2025 16:46, Roger Pau Monné wrote:
> One question I have thoug
On 12.06.2025 11:29, Jiqian Chen wrote:
> --- a/xen/drivers/vpci/msi.c
> +++ b/xen/drivers/vpci/msi.c
> @@ -193,6 +193,33 @@ static void cf_check mask_write(
> msi->mask = val;
> }
>
> +static int cf_check cleanup_msi(struct pci_dev *pdev)
> +{
> +int rc;
> +unsigned int end, size;
On Wed, Jun 18, 2025 at 02:04:12PM +0200, Jan Beulich wrote:
> On 16.06.2025 19:23, Roger Pau Monné wrote:
> > On Mon, Jun 16, 2025 at 06:02:07PM +0200, Jan Beulich wrote:
> >> On 16.06.2025 17:41, Roger Pau Monné wrote:
> >>> On Mon, Jun 16, 2025 at 05:20:45PM +0200, Jan Beulich wrote:
> On 1
On 18.06.2025 11:13, Oleksii Kurochko wrote:
> Instead of declaring __ro_after_init_{start,end} in each architecture's
> asm/setup.h, move these declarations to the common header xen/sections.h.
>
> This centralizes the declarations and reduces duplication across
> architectures.
>
> No functiona
Both c6e0a5539623 ("cpufreq: use existing local var in
cpufreq_statistic_init()") and a1ce987411f6 ("cpufreq: don't leave stale
statistics pointer") were lost in the course of "moving" the code,
presumably due to overly lax re-basing.
Fixes: bf0cd071db2a ("xen/pmstat: consolidate code into pmstat.
Instead of declaring __ro_after_init_{start,end} in each architecture's
asm/setup.h, move these declarations to the common header xen/sections.h.
This centralizes the declarations and reduces duplication across
architectures.
No functional change intended.
Signed-off-by: Oleksii Kurochko
---
CI
On Wed Jun 18, 2025 at 9:06 AM CEST, Michal Orzel wrote:
>
>
> On 17/06/2025 19:13, Alejandro Vallejo wrote:
>> The DT spec declares only two number types for a property: u32 and u64,
>> as per Table 2.3 in Section 2.2.4. Remove unbounded loop and replace
>> with a switch statement. Default to a si
On 11.06.2025 19:16, Roger Pau Monne wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -2072,6 +2072,28 @@ for all of them (`true`), only for those subject to
> XPTI (`xpti`) or for
> those not subject to XPTI (`no-xpti`). The feature is used only in
On 12.06.2025 11:29, Jiqian Chen wrote:
> --- a/xen/drivers/vpci/msix.c
> +++ b/xen/drivers/vpci/msix.c
> @@ -703,9 +703,13 @@ static int cf_check init_msix(struct pci_dev *pdev)
> pdev->vpci->msix = msix;
> list_add(&msix->next, &d->arch.hvm.msix_tables);
>
> -return 0;
> +spin
On 12.06.2025 11:29, Jiqian Chen wrote:
> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -83,6 +83,88 @@ static int assign_virtual_sbdf(struct pci_dev *pdev)
>
> #endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
>
> +static struct vpci_register *vpci_get_register(struct vpci *vpci
On Wed, Jun 18, 2025 at 03:02:34PM +0200, Jan Beulich wrote:
> On 11.06.2025 19:16, Roger Pau Monne wrote:
> > With the appearance of Intel Sierra Forest and Granite Rapids it's not
> > possible to get a production x86 host wit the following memory map:
> >
> > SRAT: Node 0 PXM 0 [
On Wed, Jun 18, 2025 at 03:36:57PM +0200, Jan Beulich wrote:
> On 11.06.2025 19:16, Roger Pau Monne wrote:
> > --- a/docs/misc/xen-command-line.pandoc
> > +++ b/docs/misc/xen-command-line.pandoc
> > @@ -2072,6 +2072,28 @@ for all of them (`true`), only for those subject to
> > XPTI (`xpti`) or for
While UWRMSR probably isn't of much use as long as we don't support
UINTR, URDMSR may well be useful to guests even without that (depending
on what OSes are willing to permit access to).
Since the two VEX encodings introduce a lonely opcode point in map 7,
for now don't bother introducing a full 2
Using UKI it's possible to embed Linux kernel into xen.efi file.
In this case the signature for Secure Boot is applied to the
whole xen.efi, including the kernel.
So checking for specific signature for the kernel is not
needed.
In case Secure Boot is not enabled there's no reason to check
kernel si
On Wed, Jun 18, 2025 at 06:16:30PM +0200, Nicola Vetrini wrote:
> On 2025-06-18 17:18, Roger Pau Monné wrote:
> > On Fri, Jun 06, 2025 at 02:27:09PM -0700, victorm.l...@amd.com wrote:
> > > From: Nicola Vetrini
> > >
> > > The marked functions never return to their caller, but lack the
> > > `nor
On Tue, 17 Jun 2025, Jan Beulich wrote:
> On 17.06.2025 02:10, Stefano Stabellini wrote:
> > On Mon, 16 Jun 2025, Jan Beulich wrote:
> >> On 14.06.2025 00:51, Stefano Stabellini wrote:
> >>> On Wed, 11 Jun 2025, Jason Andryuk wrote:
> On 2025-06-11 09:27, Jan Beulich wrote:
> > On 11.06.20
On Wed, 18 Jun 2025, Jan Beulich wrote:
> On 18.06.2025 02:39, Stefano Stabellini wrote:
> > On Thu, 12 Jun 2025, Jan Beulich wrote:
> >> On 11.06.2025 21:07, Stefano Stabellini wrote:
> >>> On Wed, 11 Jun 2025, Jan Beulich wrote:
> On 11.06.2025 02:07, dm...@proton.me wrote:
> > On Tue, J
Hi Alexander,
kernel test robot noticed the following build warnings:
url:
https://github.com/intel-lab-lkp/linux/commits/Alexander-Gordeev/mm-Cleanup-apply_to_pte_range-routine/20250613-013835
base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git
mm-everything
patch link:
On 2025/6/18 22:33, Jan Beulich wrote:
> On 12.06.2025 11:29, Jiqian Chen wrote:
>> --- a/xen/include/xen/vpci.h
>> +++ b/xen/include/xen/vpci.h
>> @@ -13,11 +13,12 @@ typedef uint32_t vpci_read_t(const struct pci_dev *pdev,
>> unsigned int reg,
>> typedef void vpci_write_t(const struct pci_dev *
On 2025/6/18 21:52, Jan Beulich wrote:
> On 12.06.2025 11:29, Jiqian Chen wrote:
>> --- a/xen/drivers/vpci/header.c
>> +++ b/xen/drivers/vpci/header.c
>> @@ -836,6 +836,42 @@ static int vpci_init_capability_list(struct pci_dev
>> *pdev)
>>PCI_STATUS_RSVDZ_MASK);
On 2025/6/18 22:05, Jan Beulich wrote:
> On 12.06.2025 11:29, Jiqian Chen wrote:
>> --- a/xen/drivers/vpci/msix.c
>> +++ b/xen/drivers/vpci/msix.c
>> @@ -703,9 +703,13 @@ static int cf_check init_msix(struct pci_dev *pdev)
>> pdev->vpci->msix = msix;
>> list_add(&msix->next, &d->arch.hvm.
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Thursday, June 12, 2025 12:10 AM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andrew Cooper
> ; Roger Pau Monné ;
> Anthony PERARD ; Orzel, Michal
> ; Julien Grall ; Stefano Stabellini
> ; xen-devel@lists.xenproject.org
> Subject: Re: [P
51 matches
Mail list logo
