flight 185731 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185731/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185712
test-amd64-amd64-xl-qemut-win7-amd64
On 18.04.2024 18:07, Jason Andryuk wrote:
> 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
Acked-by: Jan Beulich
18.04.24 14:36, Jan Beulich:
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
Hi Jan,
On 4/19/2024 2:18 PM, Jan Beulich wrote:
On 19.04.2024 04:31, Henry Wang wrote:
On 4/18/2024 8:54 PM, Jan Beulich wrote:
On 09.04.2024 06:53, Henry Wang wrote:
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -21,6 +21,7 @@
#define XENMEM_increase_reservation
On 18.04.2024 20:33, Andrew Cooper wrote:
> 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.
On 18.04.2024 17:52, Roger Pau Monne wrote:
> 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
On 19.04.2024 04:31, Henry Wang wrote:
> On 4/18/2024 8:54 PM, Jan Beulich wrote:
>> On 09.04.2024 06:53, Henry Wang wrote:
>>> --- a/xen/include/public/memory.h
>>> +++ b/xen/include/public/memory.h
>>> @@ -21,6 +21,7 @@
>>> #define XENMEM_increase_reservation 0
>>> #define XENMEM_decrease_res
On 19.04.2024 04:27, Henry Wang wrote:
> On 4/18/2024 8:37 PM, Jan Beulich wrote:
>> On 09.04.2024 06:53, Henry Wang wrote:
>>> --- a/xen/include/public/arch-arm.h
>>> +++ b/xen/include/public/arch-arm.h
>>> @@ -223,6 +223,13 @@ typedef uint64_t xen_pfn_t;
>>>*/
>>> #define XEN_LEGACY_MAX_VCP
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:
> On
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 Stefano
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 t
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.
Signed-off-b
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 purp
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 i
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 regar
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 Stefa
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 the
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 i
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 intro
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, &domctl);
}
+int xc_get_domain_mem_map(xc_
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
```
Th
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 1
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.
nxp.com%2Fwebapp%2FDownload%3FcolCode%3DIMX8MMR
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: And
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 m
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
> Reviewed-by
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 Asynchro
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,
>>> c
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 dele
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 i
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 poi
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 use
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.
Instead
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 no
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
> +++ b/xen/arch/x86/hvm/dom0_bui
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
>>>
>>> -doc_be
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 a
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 xen/common/devic
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
"GCC_MANUAL
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;
> +in
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
>>> +++ b/xen/arch/x86/cpu/M
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 = (a
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 1
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
>> QEM
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 violating
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.
>>>
>>> Signed-of
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
expre
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
>>> +++ b/xen/arch/x86/cpu/Mak
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 += intel_ca
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:
> > variable
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 tec
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 o
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, &domctl);
> }
>
> +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. Remo
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
test-amd64-amd64-xl-qemut-win7-a
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 ++
xen/drivers/passthrough/vtd/intrema
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 i
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 insertions(+)
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
xen/drivers/passthrough
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,
w
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) && cpu_
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 p
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, so
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: Ste
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 t
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
> --- a/docs/misra/deviations.rs
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 bo
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 1bcb007395ba..9b
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 us
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 (S
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)
> wrmsrl(MSR_AMD64_BP_
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 @@ stat
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 tree
1 - 100 of 123 matches
Mail list logo
