On Thu, Apr 18, 2024 at 09:09:51AM +0200, Jan Beulich wrote:
> On 18.04.2024 08:45, Elliott Mitchell wrote:
> > On Wed, Apr 17, 2024 at 02:40:09PM +0200, Jan Beulich wrote:
> >> On 11.04.2024 04:41, Elliott Mitchell wrote:
> >>> On Thu, Mar 28, 2024 at 07:25:02AM +0100, Jan Beulich wrote:
>
Hi All,
This is v6 series to support passthrough on Xen when dom0 is PVH.
v5->v6 changes:
* Due to changes in the implementation of obtaining gsi in the kernel and Xen.
Change to use xc_physdev_gsi_from_irq, instead of gsi sysfs.
Best regards,
Jiqian Chen
v4->v5 changes:
* Add review by
In PVH dom0, it uses the linux local interrupt mechanism,
when it allocs irq for a gsi, it is dynamic, and follow
the principle of applying first, distributing first. And
the irq number is alloced from small to large, but the
applying gsi number is not, may gsi 38 comes before gsi
28, that causes
Some type of domain don't have PIRQ, like PVH, when
passthrough a device to guest on PVH dom0, callstack
pci_add_dm_done->XEN_DOMCTL_irq_permission will failed
at domain_pirq_to_irq.
So, add a new hypercall to grant/revoke gsi permission
when dom0 is not PV or dom0 has not PIRQ flag.
On PVH dom0, the gsis don't get registered, but
the gsi of a passthrough device must be configured for it to
be able to be mapped into a hvm domU.
On Linux kernel side, it calles PHYSDEVOP_setup_gsi for
passthrough devices to register gsi when dom0 is PVH.
So, add PHYSDEVOP_setup_gsi for above
When a device has been reset on dom0 side, the vpci on Xen
side won't get notification, so the cached state in vpci is
all out of date compare with the real device state.
To solve that problem, add a new hypercall to clear all vpci
device state. When the state of device is reset on dom0 side,
dom0
In PVH dom0, it uses the linux local interrupt mechanism,
when it allocs irq for a gsi, it is dynamic, and follow
the principle of applying first, distributing first. And
irq number is alloced from small to large, but the applying
gsi number is not, may gsi 38 comes before gsi 28, that
causes the
Hi All,
This is v7 series to support passthrough when dom0 is PVH
v6->v7 changes:
* patch#4: Due to changes in the implementation of obtaining gsi in the kernel.
Change to add a new function to get gsi from irq, instead of gsi sysfs.
* patch#5: Fix the issue with variable usage, rc->r.
Best
If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
a passthrough device by using gsi, see
xen_pt_realize->xc_physdev_map_pirq and
pci_add_dm_done->xc_physdev_map_pirq. Then xc_physdev_map_pirq
will call into Xen, but in hvm_physdev_op, PHYSDEVOP_map_pirq
is not allowed because currd is
Hi All,
This is v6 series to support passthrough on Xen when dom0 is PVH.
v5->v6 change:
* patch#3: change to add a new syscall to translate irq to gsi, instead adding
a new gsi sysfs.
Best regards,
Jiqian Chen
v4->v5 changes:
* patch#1: Add Reviewed-by Stefano
* patch#2: Add Reviewed-by
In PVH dom0, the gsis don't get registered, but the gsi of
a passthrough device must be configured for it to be able to be
mapped into a domU.
When assign a device to passthrough, proactively setup the gsi
of the device during that process.
Co-developed-by: Huang Rui
Signed-off-by: Jiqian Chen
In PVH dom0, it uses the linux local interrupt mechanism,
when it allocs irq for a gsi, it is dynamic, and follow
the principle of applying first, distributing first. And
the irq number is alloced from small to large, but the
applying gsi number is not, may gsi 38 comes before gsi 28,
it causes
When device on dom0 side has been reset, the vpci on Xen side
won't get notification, so that the cached state in vpci is
all out of date with the real device state.
To solve that problem, add a new function to clear all vpci
device state when device is reset on dom0 side.
And call that function
Hi Jan,
On 4/18/2024 8:54 PM, Jan Beulich wrote:
On 09.04.2024 06:53, Henry Wang wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -155,6 +155,14 @@ static void increase_reservation(struct memop_args *a)
a->nr_done = i;
}
+/*
+ * Alias of _MEMF_no_refcount to avoid
Hi Jan,
On 4/18/2024 8:37 PM, Jan Beulich wrote:
On 09.04.2024 06:53, Henry Wang wrote:
--- a/tools/libs/ctrl/xc_domain.c
+++ b/tools/libs/ctrl/xc_domain.c
@@ -697,6 +697,43 @@ int xc_domain_setmaxmem(xc_interface *xch,
return do_domctl(xch, );
}
+int
Hi Daniel,
On 4/18/2024 10:16 PM, Daniel P. Smith wrote:
On 4/9/24 00:53, Henry Wang wrote:
An error message can seen from the init-dom0less application on
direct-mapped 1:1 domains:
```
Allocating magic pages
memory.c:238:d0v0 mfn 0x39000 doesn't belong to d1
Error on alloc magic pages
```
flight 185729 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185729/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 185712
build-amd64-prev
flight 185730 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185730/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 2024-04-18 17:15, Jan Beulich wrote:
On 18.04.2024 17:00, Nicola Vetrini wrote:
On 2024-04-18 09:22, Jan Beulich wrote:
On 17.04.2024 16:51, Nicola Vetrini wrote:
--- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
+++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
@@ -44,8 +44,8 @@
On 07.04.24 05:43, Peng Fan wrote:
Hi Oleksandr,
Hello Peng
Subject: [PATCH 2/2] xen/arm: Add i.MX UART driver
From: Oleksandr Tyshchenko
The i.MX UART Documentation:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
On 18/04/2024 8:39 am, Jan Beulich wrote:
> On 15.04.2024 17:44, Andrew Cooper wrote:
>> On 15/04/2024 10:56 am, Federico Serafini wrote:
>>> Mark the whole gzip folder as adopted code and remove the redundant
>>> deviation of file inflate.
>>>
>>> Signed-off-by: Federico Serafini
>> Acked-by:
On 17/04/2024 8:14 am, Roger Pau Monné wrote:
> On Tue, Apr 16, 2024 at 04:52:51PM +0100, Andrew Cooper wrote:
>> Misra Rule 21.16 doesn't like the use of memcmp() between a string literal
>> and
>> a UINT8 array. Rewrite using plain compares.
> The commit message makes it look like it's a type
On 18/04/2024 12:09 pm, Jan Beulich wrote:
> On 16.04.2024 17:52, Andrew Cooper wrote:
>> Misra Rule 21.16 doesn't like the use of memcmp() between a string literal
>> and
>> a UINT8 array. Rewrite using plain compares.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper
>
On 04.04.24 09:54, Michal Orzel wrote:
Hi Oleksandr,
Hello Michal
sorry for the late response
On 02/04/2024 14:05, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The i.MX UART Documentation:
https://www.nxp.com/webapp/Download?colCode=IMX8MMRM
Chapter 16.2 Universal
On 18/04/2024 12:06 pm, Jan Beulich wrote:
> On 17.04.2024 09:14, Roger Pau Monné wrote:
>> On Tue, Apr 16, 2024 at 04:52:51PM +0100, Andrew Cooper wrote:
>>> --- a/xen/common/efi/pe.c
>>> +++ b/xen/common/efi/pe.c
>>> @@ -111,7 +111,8 @@ const void *__init pe_find_section(const void *image,
>>>
Switch to unsigned int for the dom0 e820 index. This eliminates the
potential for array underflows, and the compiler might be able to
generate better code.
Requested-by: Jan Beulich
Signed-off-by: Jason Andryuk
---
xen/arch/x86/hvm/dom0_build.c | 4 ++--
1 file changed, 2 insertions(+), 2
On 18.04.2024 17:52, Roger Pau Monne wrote:
> Reporting whether the BHB clearing on entry is done for the different domains
> types based on cpu_has_bhb_seq is incorrect, as that variable signals whether
> there's a BHB clearing sequence selected, but that alone doesn't imply that
> such sequence
On 2024-04-18 17:10, Jan Beulich wrote:
On 17.04.2024 21:37, Nicola Vetrini wrote:
Refactor the first clauses so that a violation of
MISRA C Rule 16.2 is resolved (a switch label should be immediately
enclosed in the compound statement of the switch).
Note that the switch clause ending with the
Hello,
Fix patch fixing the printing of whether BHB-entry is used for PV or
HVM, second patch refines a bit the logic to decide whether the lfence
on entry can be elided for the entry points.
Thanks, Roger.
Roger Pau Monne (2):
x86/spec: fix reporting of BHB clearing usage from guest entry
It's currently too restrictive by just checking whether there's a BHB clearing
sequence selected. It should instead check whether BHB clearing is used on
entry from PV or HVM specifically.
Switch to use opt_bhb_entry_{pv,hvm} instead, and then remove cpu_has_bhb_seq
since it no longer has any
Reporting whether the BHB clearing on entry is done for the different domains
types based on cpu_has_bhb_seq is incorrect, as that variable signals whether
there's a BHB clearing sequence selected, but that alone doesn't imply that
such sequence is used from the PV and/or HVM entry points.
On 03.04.24 13:11, Michal Orzel wrote:
Hi Oleksandr,
Hello Michal
sorry for the late response
On 02/04/2024 14:05, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Tested on i.MX 8M Mini only, but I guess, it should be
suitable for other i.MX8M* SoCs (those UART device tree
On Thu, Apr 18, 2024 at 12:44:26PM +0200, Jan Beulich wrote:
> On 15.04.2024 16:17, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/spec_ctrl.c
> > +++ b/xen/arch/x86/spec_ctrl.c
> > @@ -643,7 +643,7 @@ static void __init print_details(enum ind_thunk thunk)
> > opt_eager_fpu
On 18.04.2024 16:34, Jason Andryuk wrote:
> On 2024-04-17 09:24, Jan Beulich wrote:
>> On 08.04.2024 18:56, Jason Andryuk wrote:
>>> On 2024-04-08 03:00, Jan Beulich wrote:
On 04.04.2024 23:25, Jason Andryuk wrote:
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++
On 18.04.2024 17:00, Nicola Vetrini wrote:
> On 2024-04-18 09:22, Jan Beulich wrote:
>> On 17.04.2024 16:51, Nicola Vetrini wrote:
>>> --- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
>>> +++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
>>> @@ -44,8 +44,8 @@
>>> -doc_end
>>>
>>>
On 17.04.2024 21:37, Nicola Vetrini wrote:
> Refactor the first clauses so that a violation of
> MISRA C Rule 16.2 is resolved (a switch label should be immediately
> enclosed in the compound statement of the switch).
> Note that the switch clause ending with the pseudo
> keyword "fallthrough" is
On 12.04.2024 05:55, Shawn Anastasio wrote:
> Arm's setup.c contains a collection of functions for parsing memory map
> and other boot information from a device tree. Since these routines are
> generally useful on any architecture that supports device tree booting,
> move them into
On 2024-04-18 09:22, Jan Beulich wrote:
On 17.04.2024 16:51, Nicola Vetrini wrote:
--- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
+++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
@@ -44,8 +44,8 @@
-doc_end
-doc_begin="See Section \"6.19 Structures with No Members\" of
On 11.04.2024 17:24, Matthew Barnes wrote:
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -73,6 +73,7 @@ void getdomaininfo(struct domain *d, struct
> xen_domctl_getdomaininfo *info)
>
> info->domain = d->domain_id;
> info->max_vcpu_id = XEN_INVALID_MAX_VCPU_ID;
> +
On 18/04/2024 2:25 pm, Sergiy Kibrik wrote:
> 16.04.24 14:05, Andrew Cooper:
>> On 16/04/2024 7:35 am, Sergiy Kibrik wrote:
>>> diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile
>>> index 35561fe51d..d3d7b8fb2e 100644
>>> --- a/xen/arch/x86/cpu/Makefile
>>> +++
On 11.04.2024 17:24, Matthew Barnes wrote:
> --- a/tools/xcutils/lsevtchn.c
> +++ b/tools/xcutils/lsevtchn.c
> @@ -11,6 +11,7 @@ int main(int argc, char **argv)
> xc_interface *xch;
> int domid, port, rc;
> xc_evtchn_status_t status;
> +xc_domaininfo_t info;
>
> domid =
On 2024-04-17 09:24, Jan Beulich wrote:
On 08.04.2024 18:56, Jason Andryuk wrote:
On 2024-04-08 03:00, Jan Beulich wrote:
On 04.04.2024 23:25, Jason Andryuk wrote:
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -537,6 +537,111 @@ static paddr_t __init find_memory(
flight 185727 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185727/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 18.04.2024 16:18, Marek Marczykowski-Górecki wrote:
> On Wed, Mar 13, 2024 at 04:16:05PM +0100, Marek Marczykowski-Górecki wrote:
>> This series includes changes to make MSI-X working with Linux stubdomain and
>> especially Intel Wifi 6 AX210 card. This takes care of remaining reasons for
>>
On Wed, Mar 13, 2024 at 04:16:05PM +0100, Marek Marczykowski-Górecki wrote:
> This series includes changes to make MSI-X working with Linux stubdomain and
> especially Intel Wifi 6 AX210 card. This takes care of remaining reasons for
> QEMU to access /dev/mem, but also the Intel Wifi card
On 4/9/24 00:53, Henry Wang wrote:
An error message can seen from the init-dom0less application on
direct-mapped 1:1 domains:
```
Allocating magic pages
memory.c:238:d0v0 mfn 0x39000 doesn't belong to d1
Error on alloc magic pages
```
This is because populate_physmap() automatically assumes gfn
On 18.04.2024 15:09, Oleksii wrote:
> On Thu, 2024-04-18 at 12:00 +0200, Jan Beulich wrote:
>> On 09.04.2024 10:00, Oleksii Kurochko wrote:
>>> Update the argument of the as-insn for the Zbb case to verify that
>>> Zbb is supported not only by a compiler, but also by an assembler.
>>>
>>>
16.04.24 16:26, Andrew Cooper:
I'm afraid this is going in an unhelpful direction. We want to move
both of these files to be local to arch/x86/hvm/{vmx,svm}/.
cpu_has_svm_* isn't actually used outside of svm/; only the plain
SVM_FEATURE_* constants are, and that's only because they're not
On 18.04.2024 15:25, Sergiy Kibrik wrote:
> 16.04.24 14:05, Andrew Cooper:
>> On 16/04/2024 7:35 am, Sergiy Kibrik wrote:
>>> diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile
>>> index 35561fe51d..d3d7b8fb2e 100644
>>> --- a/xen/arch/x86/cpu/Makefile
>>> +++
Thank you Jan for your feedback.
From what I understood, Andrew is planning some "ground" changes
on CPUID leaf discovery, so it probably will move here. I'll wait for his
changes to apply your and Andrew's remarks and to re-post the patches.
Andrei.
On 4/18/24 10:13, Jan Beulich wrote:
On
16.04.24 14:05, Andrew Cooper:
On 16/04/2024 7:35 am, Sergiy Kibrik wrote:
diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile
index 35561fe51d..d3d7b8fb2e 100644
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -10,4 +10,6 @@ obj-y += intel.o
obj-y +=
On 08.04.2024 18:26, Ross Lagerwall wrote:
> In a test, OVMF reported an error initializing the RTC without
> indicating the precise nature of the error. The only plausible
> explanation I can find is as follows:
>
> As part of the initialization, OVMF reads register C and then reads
> register A
On Thu, 2024-04-18 at 09:14 +0200, Jan Beulich wrote:
> On 17.04.2024 12:04, Oleksii Kurochko wrote:
> > --- a/automation/gitlab-ci/build.yaml
> > +++ b/automation/gitlab-ci/build.yaml
> > @@ -515,10 +515,14 @@ alpine-3.18-gcc-debug-arm64-boot-cpupools:
> > .riscv-fixed-randconfig:
> >
17.04.24 17:46, Jan Beulich:
Going forward, can you please make sure you send patch series as threads
(i.e. individual patches with Reply-to: referencing the cover letter)?
oh, yes.. sorry about that, I myself noticed a broken threading only
after git send-email started firing..
-Sergiy
On Thu, 2024-04-18 at 12:00 +0200, Jan Beulich wrote:
> On 09.04.2024 10:00, Oleksii Kurochko wrote:
> > Update the argument of the as-insn for the Zbb case to verify that
> > Zbb is supported not only by a compiler, but also by an assembler.
> >
> > Signed-off-by: Oleksii Kurochko
>
> While
On 09.04.2024 06:53, Henry Wang wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -155,6 +155,14 @@ static void increase_reservation(struct memop_args *a)
> a->nr_done = i;
> }
>
> +/*
> + * Alias of _MEMF_no_refcount to avoid introduction of a new, single-use
> flag.
>
On 18/04/2024 09:36, Luca Fancellu wrote:
>
>
> From: Penny Zheng
>
> Static shared memory acts as reserved memory in guest, so it shall be
> excluded from extended regions.
>
> Extended regions are taken care of under three different scenarios:
> normal DomU, direct-map domain with iommu
On 09.04.2024 06:53, Henry Wang wrote:
> --- a/tools/libs/ctrl/xc_domain.c
> +++ b/tools/libs/ctrl/xc_domain.c
> @@ -697,6 +697,43 @@ int xc_domain_setmaxmem(xc_interface *xch,
> return do_domctl(xch, );
> }
>
> +int xc_get_domain_mem_map(xc_interface *xch, uint32_t domid,
> +
On 09.04.2024 14:06, Sergiy Kibrik wrote:
> Separate Intel nonfatal MCE initialization code from generic MCE code, the
> same
> way it is done for AMD code. This is to be able to later make intel/amd MCE
> code optional in the build.
>
> Convert to Xen coding style. Clean up unused includes.
flight 185724 xen-4.18-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185724/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-check fail blocked in 185285
All hardware with VT-d/AMD-Vi has CMPXCHG16B support. Check this at
initialisation time, and remove the effectively-dead logic for the non-cx16
case.
Suggested-by: Andrew Cooper
Signed-off-by: Teddy Astie
---
xen/drivers/passthrough/amd/iommu_intr.c | 6 ++
All hardware that supports VT-d/AMD-Vi that exists also supports cx16 (aside
specifically crafted virtual machines).
Some IOMMU code paths in Xen consider cases where VT-d/AMD-Vi is supported
while cx16 isn't, those paths may be bugged and are barely tested, dead code
in practice.
Disable IOMMU
This flag was only used in case cx16 is not available, as those code paths no
longer exist, this flag now does basically nothing.
Signed-off-by: Teddy Astie
---
xen/drivers/passthrough/vtd/iommu.c | 12 +++-
xen/drivers/passthrough/vtd/vtd.h | 5 ++---
2 files changed, 5
All hardware with VT-d/AMD-Vi has CMPXCHG16B support. Check this at
initialisation time, and remove the effectively-dead logic for the
non-cx16 case.
Suggested-by: Andrew Cooper
Signed-off-by: Teddy Astie
---
xen/drivers/passthrough/amd/iommu_map.c | 42
On 16.04.2024 08:46, Sergiy Kibrik wrote:
> --- a/xen/arch/x86/include/asm/hvm/svm/svm.h
> +++ b/xen/arch/x86/include/asm/hvm/svm/svm.h
> @@ -38,10 +38,18 @@ extern u32 svm_feature_flags;
> #define SVM_FEATURE_SSS 19 /* NPT Supervisor Shadow Stacks */
> #define SVM_FEATURE_SPEC_CTRL
On 16.04.2024 08:29, Sergiy Kibrik wrote:
> Move altp2m code from generic p2m.c file to altp2m.c, so that VMX-specific
> code is kept separately and can possibly be disabled in the build.
The code movement is desirable, but the reasoning isn't quite right (see
replies on other sub-threads).
>
On 16.04.2024 08:25, Sergiy Kibrik wrote:
> Use altp2m index only when it is supported by the platform, i.e. VMX.
> The puspose of that is the possiblity to disable VMX support and
> exclude its code from the build completely.
I'm afraid this description doesn't make clear what problem there is,
On 16.04.2024 08:22, Sergiy Kibrik wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -156,9 +156,9 @@ static int __init cf_check hvm_enable(void)
> {
> const struct hvm_function_table *fns = NULL;
>
> -if ( cpu_has_vmx )
> +if ( IS_ENABLED(CONFIG_VMX) &&
On 16.04.2024 08:20, Sergiy Kibrik wrote:
> From: Xenia Ragiadakou
>
> Introduce two new Kconfig options, SVM and VMX, to allow code
> specific to each virtualization technology to be separated and, when not
> required, stripped.
> CONFIG_SVM will be used to enable virtual machine extensions on
On 16.04.2024 17:52, Andrew Cooper wrote:
> Misra Rule 21.16 doesn't like the use of memcmp() between a string literal and
> a UINT8 array. Rewrite using plain compares.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
after having realized that sadly gcc13
On 17.04.2024 09:14, Roger Pau Monné wrote:
> On Tue, Apr 16, 2024 at 04:52:51PM +0100, Andrew Cooper wrote:
>> --- a/xen/common/efi/pe.c
>> +++ b/xen/common/efi/pe.c
>> @@ -111,7 +111,8 @@ const void *__init pe_find_section(const void *image,
>> const UINTN image_size,
>> UINTN offset, i;
16.04.24 20:03, Tamas K Lengyel:
On Tue, Apr 16, 2024 at 3:29 AM Andrew Cooper wrote:
On 16/04/2024 7:31 am, Sergiy Kibrik wrote:
Instead of using generic CONFIG_HVM option switch to a bit more specific
CONFIG_VMX option for altp2m support, as it depends on VMX. Also guard
altp2m routines,
On 15.04.2024 16:17, Roger Pau Monne wrote:
> --- a/xen/arch/x86/spec_ctrl.c
> +++ b/xen/arch/x86/spec_ctrl.c
> @@ -643,7 +643,7 @@ static void __init print_details(enum ind_thunk thunk)
> opt_eager_fpu ? " EAGER_FPU" : "",
> opt_verw_hvm
On 11.04.2024 17:23, Andrew Cooper wrote:
> x86_seg_* uses architectural encodings. Therefore, we can fold the prefix
> handling cases together and derive the segment from the prefix byte itself.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
I notice we
On 15/04/2024 10:49 pm, Stefano Stabellini wrote:
> On Mon, 15 Apr 2024, Andrew Cooper wrote:
>> * Fix tabs/spaces mismatch for certain rows
>> * Insert lines between header files to improve legibility
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: George Dunlap
>> CC: Jan Beulich
>> CC:
On 16/04/2024 10:15 am, Fouad Hilly wrote:
> Update microcode version check at Intel and AMD Level by:
> Preventing the low level code from sending errors if the microcode
> version provided is not a newer version. Other errors will be sent like
> before.
> When the provided microcode version is
On 09.04.2024 10:00, Oleksii Kurochko wrote:
> Update the argument of the as-insn for the Zbb case to verify that
> Zbb is supported not only by a compiler, but also by an assembler.
>
> Signed-off-by: Oleksii Kurochko
While technically all if fine here, I'm afraid I have a couple of nits:
>
On 16.04.2024 21:27, Stefano Stabellini wrote:
> Also add two specific project-wide deviations for R21.6 and R21.15.
>
> Signed-off-by: Stefano Stabellini
>
> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> index 32b02905d1..9123c8edb5 100644
> ---
On 15.04.2024 17:41, Andrew Cooper wrote:
> RFC. In theory this is a great way to avoid some of the spiketraps involved
> with C being the official representation.
>
> However, this doesn't build. gnttab_transfer has a layout that requires a
> CONFIG_COMPAT if we want to satisfy -Wpadding for
On 4/18/24 05:17, Jan Beulich wrote:
On 18.04.2024 11:13, Daniel P. Smith wrote:
On 4/18/24 03:36, Jan Beulich wrote:
On 11.04.2024 21:24, Andrew Cooper wrote:
On 11/04/2024 4:25 pm, Daniel P. Smith wrote:
diff --git a/xen/common/gzip/gunzip.c b/xen/common/gzip/gunzip.c
index
On 16.04.2024 00:15, Stefano Stabellini wrote:
> On Mon, 15 Apr 2024, Andrew Cooper wrote:
>> RFC. In theory this is a great way to avoid some of the spiketraps involved
>> with C being the official representation.
>>
>> However, this doesn't build. gnttab_transfer has a layout that requires a
On 18.04.2024 11:13, Daniel P. Smith wrote:
> On 4/18/24 03:36, Jan Beulich wrote:
>> On 11.04.2024 21:24, Andrew Cooper wrote:
>>> On 11/04/2024 4:25 pm, Daniel P. Smith wrote:
diff --git a/xen/common/gzip/gunzip.c b/xen/common/gzip/gunzip.c
index 1bcb007395ba..9b4891731b8b 100644
On 15.04.2024 17:41, Andrew Cooper wrote:
> This subop appears to have been missed from the compat checks.
Fixes: 5ce8fafa947c ("Dynamic grant-table sizing")
> Signed-off-by: Andrew Cooper
With the addition that I'm now sure Stefano meant (see the reply to him):
Reviewed-by: Jan Beulich
Jan
On 4/18/24 03:36, Jan Beulich wrote:
On 11.04.2024 21:24, Andrew Cooper wrote:
On 11/04/2024 4:25 pm, Daniel P. Smith wrote:
diff --git a/xen/common/gzip/gunzip.c b/xen/common/gzip/gunzip.c
index 1bcb007395ba..9b4891731b8b 100644
--- a/xen/common/gzip/gunzip.c
+++ b/xen/common/gzip/gunzip.c
@@
On 15.04.2024 23:54, Stefano Stabellini wrote:
> On Mon, 15 Apr 2024, Andrew Cooper wrote:
>> This subop appears to have been missed from the compat checks.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: George Dunlap
>> CC: Jan Beulich
>> CC: Stefano Stabellini
>> CC: Julien Grall
>> ---
On 15.04.2024 17:41, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
While I don't mind the change as is, "sort" is ambiguous here in one regard.
Personally I'd prefer if those parts of the change were dropped, but I can
live with the sorting criteria being spelled out in the description:
>
On 12.04.2024 12:59, Andrew Cooper wrote:
> On 12/04/2024 9:07 am, Roger Pau Monne wrote:
>> @@ -310,6 +313,20 @@ int livepatch_elf_resolve_symbols(struct livepatch_elf
>> *elf)
>> break;
>> }
>> }
>> +/*
>> + * Ensure not
Hi Luca,
On 18/04/2024 09:36, Luca Fancellu wrote:
>
>
> The function find_unallocated_memory is using the same code to
> loop through 2 structure of the same type, in order to avoid
> code duplication, rework the code to have only one loop that
> goes through all the structures, this will be
On 10.04.2024 17:36, Andrei Semenov wrote:
> Signed-off-by: Andrei Semenov
Again a few nits on top of Andrew's remarks:
> --- /dev/null
> +++ b/xen/arch/x86/include/asm/psp-sev.h
> @@ -0,0 +1,655 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * AMD Secure Encrypted Virtualization
On 10.04.2024 17:36, Andrei Semenov wrote:
> Signed-off-by: Andrei Semenov
A couple more nits on top of what Andrew said. First: Please no patches
(which aren't blindingly trivial) without description.
> @@ -1030,6 +1031,54 @@ static void amd_check_erratum_1485(void)
>
On 17.04.2024 16:37, Daniel P. Smith wrote:
> Dropping the define checks for PKZIP_BUG_WORKAROUND and NOMEMCPY define as
> they
> never are set.
You don't mention or otherwise touch DEBUG uses, yet ...
> --- a/xen/common/gzip/inflate.c
> +++ b/xen/common/gzip/inflate.c
> @@ -661,7 +661,6 @@
From: Penny Zheng
In case there is a /reserved-memory node already present in the host
dtb, current Xen codes would create yet another /reserved-memory node
when the static shared memory feature is enabled and static shared
memory regions are present.
This would result in an incorrect device
> On 18 Apr 2024, at 07:28, Jan Beulich wrote:
>
> On 09.04.2024 13:45, Luca Fancellu wrote:
>> --- a/xen/arch/x86/extable.c
>> +++ b/xen/arch/x86/extable.c
>> @@ -23,7 +23,8 @@ static inline unsigned long ex_cont(const struct
>> exception_table_entry *x)
>> return EX_FIELD(x, cont);
>> }
>>
Currently Xen is not exporting the static shared memory regions
to the device tree as /memory node, this commit is fixing this
issue.
Given that now make_memory_node needs a parameter 'struct kernel_info'
in order to call the new function shm_mem_node_fill_reg_range,
take the occasion to remove
On 17.04.2024 16:37, Daniel P. Smith wrote:
> An issue ran into by hyperlaunch was the need to use the gzip decompressor
> multiple times. The current implementation fails when reused due to tainting
> of
> decompressor state from a previous usage. This series seeks to colocate the
> gzip unit
On 15.04.2024 17:44, Andrew Cooper wrote:
> On 15/04/2024 10:56 am, Federico Serafini wrote:
>> Mark the whole gzip folder as adopted code and remove the redundant
>> deviation of file inflate.
>>
>> Signed-off-by: Federico Serafini
>
> Acked-by: Andrew Cooper
>
> I hadn't realised that we had
Currently the memory footprint of the static shared memory feature
is impacting all the struct meminfo instances with memory space
that is not going to be used.
To solve this issue, rework the static shared memory extra
information linked to the memory bank to another structure,
struct
From: Penny Zheng
Static shared memory acts as reserved memory in guest, so it shall be
excluded from extended regions.
Extended regions are taken care of under three different scenarios:
normal DomU, direct-map domain with iommu on, and direct-map domain
with iommu off.
For normal DomU, we
The function check_reserved_regions_overlap is calling
'meminfo_overlap_check' on the same type of structure, this code
can be written in a way to avoid code duplication, so rework the
function to do that.
Signed-off-by: Luca Fancellu
Reviewed-by: Michal Orzel
---
v3:
- add Michal R-by
v2:
-
Introduce a new helper function in the static-memory module
that can be called to manage static memory banks, this is
done to reuse the code when other modules would like to
manage static memory banks that are not part of the
reserved_mem structure, this is done because the static
shared memory
1 - 100 of 124 matches
Mail list logo
