On Mon, Oct 21, 2024 at 12:34:37PM +0100, David Woodhouse wrote:
> On Fri, 2024-10-18 at 10:08 +0200, Roger Pau Monne wrote:
> > When using AMD-VI interrupt remapping the vector field in the IO-APIC RTE is
> > repurposed to contain part of the offset into the remapping table.
> > Previous to
> >
On 21/10/2024 3:06 pm, Roger Pau Monné wrote:
> On Mon, Oct 21, 2024 at 12:34:37PM +0100, David Woodhouse wrote:
>> On Fri, 2024-10-18 at 10:08 +0200, Roger Pau Monne wrote:
>>> When using AMD-VI interrupt remapping the vector field in the IO-APIC RTE is
>>> repurposed to contain part of the offset
The main patch is patch 3. Patches 1 and 2 are cleanup to qubes-x86-64.sh.
https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1505518838
https://cirrus-ci.com/build/4673310460477440
Andrew Cooper (3):
CI: Minor cleanup to qubes-x86-64.sh
CI: Rework domU_config generation in qubes-
GitlabCI has no testing of Xen's PVH entrypoint. Fix this.
Signed-off-by: Andrew Cooper
---
CC: Marek Marczykowski-Górecki
CC: Daniel P. Smith
CC: Anthony PERARD
CC: Stefano Stabellini
CC: Michal Orzel
CC: Doug Goldstein
OSSTest (which is disappearing imminently) found a pvshim bug in the
Right now, various blocks rewrite domU_config= as a whole, even though it is
largely the same.
* dom0pvh-hvm does nothing but change the domain type to hvm
* *-pci sets the domain type, clears vif=[], appends earlyprintk=xen to the
cmdline, and adds some PCI config.
Refactor this to be domU_
* List all the test_variants and summerise what's going on
* Use case rather than an if/else chain for $test_variant
* Fix indentation inside the case block
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Marek Marczykowski-Górecki
CC: Daniel P. Smith
CC: Anthony PERARD
CC: Stef
Hi Ayan,
>>> + */
>>> +FUNC_LOCAL(enable_mpu)
>>> +mrs x0, SCTLR_EL2
>>> +bic x0, x0, #SCTLR_ELx_BR /* Disable Background region */
>>> +orr x0, x0, #SCTLR_Axx_ELx_M/* Enable MPU */
>>> +orr x0, x0, #SCTLR_Axx_ELx_C/* Enable D-cache */
>>> +orr x0, x0, #
On 21/10/2024 17:24, Luca Fancellu wrote:
Hi Ayan,
+ */
+FUNC_LOCAL(enable_mpu)
+mrs x0, SCTLR_EL2
+bic x0, x0, #SCTLR_ELx_BR /* Disable Background region */
+orr x0, x0, #SCTLR_Axx_ELx_M/* Enable MPU */
+orr x0, x0, #SCTLR_Axx_ELx_C/* Enable D-cache */
On Mon, Oct 21, 2024 at 03:54:35PM +0100, David Woodhouse wrote:
> On Mon, 2024-10-21 at 15:51 +0100, Andrew Cooper wrote:
> > On 21/10/2024 3:06 pm, Roger Pau Monné wrote:
> > > On Mon, Oct 21, 2024 at 12:34:37PM +0100, David Woodhouse wrote:
> > > > On Fri, 2024-10-18 at 10:08 +0200, Roger Pau Mo
On Mon Oct 21, 2024 at 3:51 PM BST, Andrew Cooper wrote:
> On 21/10/2024 3:06 pm, Roger Pau Monné wrote:
> > On Mon, Oct 21, 2024 at 12:34:37PM +0100, David Woodhouse wrote:
> >> On Fri, 2024-10-18 at 10:08 +0200, Roger Pau Monne wrote:
> >>> When using AMD-VI interrupt remapping the vector field i
On 18/10/2024 23:13, Julien Grall wrote:
Hi Ayan,
Hi Julien,
Just one clarification.
On 10/10/2024 15:03, Ayan Kumar Halder wrote:
diff --git a/xen/arch/arm/arm64/mpu/Makefile
b/xen/arch/arm/arm64/mpu/Makefile
new file mode 100644
index 00..3340058c08
--- /dev/null
+++ b/xen/arc
On 21/10/2024 4:03 pm, Alejandro Vallejo wrote:
> On Mon Oct 21, 2024 at 3:51 PM BST, Andrew Cooper wrote:
>> On 21/10/2024 3:06 pm, Roger Pau Monné wrote:
>>> On Mon, Oct 21, 2024 at 12:34:37PM +0100, David Woodhouse wrote:
On Fri, 2024-10-18 at 10:08 +0200, Roger Pau Monne wrote:
> When
Hi Ayan,
On 21/10/2024 16:30, Ayan Kumar Halder wrote:
On 18/10/2024 23:25, Julien Grall wrote:
Hi,
Hi Julien,
On 10/10/2024 15:03, Ayan Kumar Halder wrote:
After the regions have been created, now we enable the MPU. For this
we disable
the background region so that the new memory map crea
On 21/10/2024 16:24, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 21/10/2024 12:12, Ayan Kumar Halder wrote:
On 18/10/2024 14:41, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 10/10/2024 15:03, Ayan Kumar Halder wrote:
If the BSS section is empty, then the function can just return.
This
On 21/10/2024 1:45 am, Daniel P. Smith wrote:
> The purpose of struct boot_module is to encapsulate the state of boot module
> as
> it is processed by Xen. Locating boot module state struct boot_module reduces
> the number of global variables as well as the number of state variables that
> must be
On 21/10/2024 6:00 pm, Roger Pau Monné wrote:
> On Mon, Oct 21, 2024 at 12:38:13PM +0100, Andrew Cooper wrote:
>> On 21/10/2024 12:10 pm, Andrew Cooper wrote:
>>> On 18/10/2024 9:08 am, Roger Pau Monne wrote:
When using AMD-VI interrupt remapping the vector field in the IO-APIC RTE
is
>>
On Fri, Oct 18, 2024 at 02:45:59PM +0100, Frediano Ziglio wrote:
> On Fri, Oct 18, 2024 at 1:59 PM Roger Pau Monné wrote:
> >
> > On Fri, Oct 18, 2024 at 01:48:27PM +0100, Frediano Ziglio wrote:
> > > On Fri, Oct 18, 2024 at 12:41 PM Roger Pau Monné
> > > wrote:
> > > >
> > > > On Thu, Oct 17, 2
On Fri Oct 18, 2024 at 2:17 PM BST, oleksii.kurochko wrote:
> On Thu, 2024-10-17 at 16:55 +0200, Jan Beulich wrote:
> > On 16.10.2024 11:15, Oleksii Kurochko wrote:
> > > --- a/xen/arch/riscv/include/asm/mm.h
> > > +++ b/xen/arch/riscv/include/asm/mm.h
> > > @@ -25,8 +25,12 @@
> > >
> > > static
flight 188313 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/188313/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 188310
test-amd64-amd64-xl-qemut-win7-amd64
On Mon, 21 Oct 2024, Andrew Cooper wrote:
> Right now, various blocks rewrite domU_config= as a whole, even though it is
> largely the same.
>
> * dom0pvh-hvm does nothing but change the domain type to hvm
> * *-pci sets the domain type, clears vif=[], appends earlyprintk=xen to the
>cmdline
On Mon, 21 Oct 2024, Andrew Cooper wrote:
> > Bah - serves me right for some last minute refactoring. The domain type
> > should be pvh for pvshim=1 to work.
> >
> > New pipeline:
> > https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1505540810
>
> And from the same bit of refactoring
flight 188314 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/188314/
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 Fri, Oct 18, 2024 at 02:28:05PM +0100, Frediano Ziglio wrote:
> On Fri, Oct 18, 2024 at 12:49 PM Roger Pau Monné wrote:
> >
> > On Fri, Oct 18, 2024 at 09:42:48AM +0100, Frediano Ziglio wrote:
> > > On Thu, Oct 17, 2024 at 6:13 PM Andrew Cooper
> > > wrote:
> > > >
> > > > On 17/10/2024 2:31
On Mon, 2024-10-21 at 08:56 +0100, Alejandro Vallejo wrote:
> On Fri Oct 18, 2024 at 2:17 PM BST, oleksii.kurochko wrote:
> > On Thu, 2024-10-17 at 16:55 +0200, Jan Beulich wrote:
> > > On 16.10.2024 11:15, Oleksii Kurochko wrote:
> > > > --- a/xen/arch/riscv/include/asm/mm.h
> > > > +++ b/xen/arch
From: "Edgar E. Iglesias"
The following changes since commit f1dd640896ee2b50cb34328f2568aad324702954:
Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging
(2024-10-18 10:42:56 +0100)
are available in the Git repository at:
https://gitlab.com/edgar.iglesias/qemu.git
t
From: "Edgar E. Iglesias"
Avoid use of uninitialized bufioreq_evtchn. It should only
be used if buffered IOREQs are enabled.
Resolves: Coverity CID 1563383
Reported-by: Peter Maydell
Acked-by: Stefano Stabellini
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-hvm-common.c | 7 ---
1 file
flight 188310 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/188310/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-arndale 10 host-ping-check-xen fail in 188309 pass in
188310
test-amd64-amd64-xl-qemuu-deb
On 21/10/2024 12:49 pm, David Woodhouse wrote:
> On Mon, 2024-10-21 at 12:38 +0100, Andrew Cooper wrote:
>> On 21/10/2024 12:10 pm, Andrew Cooper wrote:
>>> On 18/10/2024 9:08 am, Roger Pau Monne wrote:
>>>
+/*
+ * Store the EOI handle when using interrupt remapping.
+ *
+ * If
On Mon, Oct 21, 2024 at 12:10:14PM +0100, Andrew Cooper wrote:
> On 18/10/2024 9:08 am, Roger Pau Monne wrote:
> > When using AMD-VI interrupt remapping the vector field in the IO-APIC RTE is
> > repurposed to contain part of the offset into the remapping table.
> > Previous to
> > 2ca9fbd739b8 X
On Mon, 2024-10-21 at 12:38 +0100, Andrew Cooper wrote:
> On 21/10/2024 12:10 pm, Andrew Cooper wrote:
> > On 18/10/2024 9:08 am, Roger Pau Monne wrote:
> >
> > >
> > > +/*
> > > + * Store the EOI handle when using interrupt remapping.
> > > + *
> > > + * If using AMD-Vi interrupt remapping the I
On Mon, 2024-10-21 at 12:53 +0100, Andrew Cooper wrote:
>
> > I don't quite follow how you need a sentinel value. How could you ever
> > *not* know it, given that you have to write it to the RTE?
> >
> > (And you should *also* just use the pin# like Linux does, as I said).
>
> Because Xen is ins
Hello everyone,
As there were no objections to the proposed release schedule
(https://lore.kernel.org/xen-devel/CAMacjJxEi6PThwH2=nwg3he8eqn39aiaxzcw3bqf7i4ycmj...@mail.gmail.com/
), I've updated the wiki with the schedule for Xen 4.20 release
(https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Rel
On 18/10/2024 15:08, Julien Grall wrote:
Hi,
Hi,
On 10/10/2024 15:03, Ayan Kumar Halder wrote:
There are features in the forthcoming patches which are dependent on
MPU. For eg fixed start address.
Also, some of the Xen features (eg STATIC_MEMORY) will be selected
by the MPU configuration.
On Mon, 2024-10-21 at 10:55 +0100, Alejandro Vallejo wrote:
> On Fri Oct 18, 2024 at 9:08 AM BST, Roger Pau Monne wrote:
> > When using AMD-VI interrupt remapping the vector field in the IO-APIC RTE is
> > repurposed to contain part of the offset into the remapping table.
> > Previous to
>
> For
On Fri, 2024-10-18 at 10:08 +0200, Roger Pau Monne wrote:
> When using AMD-VI interrupt remapping the vector field in the IO-APIC RTE is
> repurposed to contain part of the offset into the remapping table. Previous
> to
> 2ca9fbd739b8 Xen had logic so that the offset into the interrupt remapping
On 21/10/2024 12:10 pm, Andrew Cooper wrote:
> On 18/10/2024 9:08 am, Roger Pau Monne wrote:
>> When using AMD-VI interrupt remapping the vector field in the IO-APIC RTE is
>> repurposed to contain part of the offset into the remapping table. Previous
>> to
>> 2ca9fbd739b8 Xen had logic so that t
On 18/10/2024 9:08 am, Roger Pau Monne wrote:
> When using AMD-VI interrupt remapping the vector field in the IO-APIC RTE is
> repurposed to contain part of the offset into the remapping table. Previous
> to
> 2ca9fbd739b8 Xen had logic so that the offset into the interrupt remapping
> table woul
On 18/10/2024 14:41, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 10/10/2024 15:03, Ayan Kumar Halder wrote:
If the BSS section is empty, then the function can just return.
This is more than "can", right? If we don't do it, we will end up to
zero outside of BSS. This could be critical data
On 10/10/2024 16:40, oleksii.kuroc...@gmail.com wrote:
Hello Ayan,
Hi Oleksii,
I think that we have to mention in CHANGELOG.md that experimental
support of Xen with MPU for Arm is added. ( if I understand correctly
what is this patch series about ).
Sure, I will add this. I will send this
A device tree node is named as follows: node-name@unit-address. The
unit-address must match the first address specified in the reg property
or be omitted if there's no reg property.
Fix the following issues:
1) domU modules are named as: node-name0xunit-address. Fix the naming to
follow the dev
On 21/10/2024 1:45 am, Daniel P. Smith wrote:
> To start transitioning consider_modules() over to struct boot_module, begin
> with taking the array of struct boot_modules but use the temporary struct
> element mod.
>
> No functional change intended.
>
> Signed-off-by: Daniel P. Smith
> Reviewed-by
On 21/10/2024 10:55 am, Alejandro Vallejo wrote:
> On Fri Oct 18, 2024 at 9:08 AM BST, Roger Pau Monne wrote:
>> When using AMD-VI interrupt remapping the vector field in the IO-APIC RTE is
>> repurposed to contain part of the offset into the remapping table. Previous
>> to
> For my own education
Add missing break statements to address violations of MISRA C:2012
Rule 16.3 (An unconditional `break' statement shall terminate
every switch-clause).
Make explicit unreachability of a program point with
ASSERT_UNREACHABLE() and add defensive code.
No functional change.
Signed-off-by: Federico S
On Fri Oct 18, 2024 at 9:08 AM BST, Roger Pau Monne wrote:
> When using AMD-VI interrupt remapping the vector field in the IO-APIC RTE is
> repurposed to contain part of the offset into the remapping table. Previous
> to
For my own education. Is that really a repurpose? Isn't the RTE vector fiel
On Mon, Oct 21, 2024 at 10:55:54AM +0100, Alejandro Vallejo wrote:
> On Fri Oct 18, 2024 at 9:08 AM BST, Roger Pau Monne wrote:
> > When using AMD-VI interrupt remapping the vector field in the IO-APIC RTE is
> > repurposed to contain part of the offset into the remapping table.
> > Previous to
>
On Sat, 2024-10-19 at 05:23 +0200, Marek Marczykowski-Górecki wrote:
> On Fri, Oct 18, 2024 at 10:08:13AM +0200, Roger Pau Monne wrote:
> > When using AMD-VI interrupt remapping the vector field in the IO-APIC RTE is
> > repurposed to contain part of the offset into the remapping table.
> > Previ
On Mon Oct 21, 2024 at 12:32 PM BST, David Woodhouse wrote:
> On Mon, 2024-10-21 at 10:55 +0100, Alejandro Vallejo wrote:
> > On Fri Oct 18, 2024 at 9:08 AM BST, Roger Pau Monne wrote:
> > > When using AMD-VI interrupt remapping the vector field in the IO-APIC RTE
> > > is
> > > repurposed to cont
On Mon Oct 21, 2024 at 10:17 AM BST, oleksii.kurochko wrote:
> On Mon, 2024-10-21 at 08:56 +0100, Alejandro Vallejo wrote:
> > On Fri Oct 18, 2024 at 2:17 PM BST, oleksii.kurochko wrote:
> > > On Thu, 2024-10-17 at 16:55 +0200, Jan Beulich wrote:
> > > > On 16.10.2024 11:15, Oleksii Kurochko wrote:
Hi Christopher,
On 19/10/2024 20:06, Christopher Clark wrote:
Recent patches to xen-devel indicate active interest in Argo within the Xen
community, and as the feature has been documented and in use by
OpenXT for multiple years, update the Xen SUPPORT.md statement of status.
Signed-off-by: Chri
On 21/10/2024 12:57 pm, Roger Pau Monné wrote:
> On Mon, Oct 21, 2024 at 12:10:14PM +0100, Andrew Cooper wrote:
>> On 18/10/2024 9:08 am, Roger Pau Monne wrote:
>>> When using AMD-VI interrupt remapping the vector field in the IO-APIC RTE is
>>> repurposed to contain part of the offset into the rem
Hello everyone,
We planned to upgrade a few host of xenproject.org in the coming week.
This will affect access to git repository (on xenbits), download of Xen
release tarballs (on mail), access to the wiki, and email delivery
delayed for some.
The upgrade will start at 09:00 European Time (so 07
On 18/10/2024 22:59, Julien Grall wrote:
Hi,
Hi Julien,
Few clarifications.
On 10/10/2024 15:03, Ayan Kumar Halder wrote:
From: Wei Chen
On Armv8-A, Xen has a fixed virtual start address (link address too)
for all
Armv8-A platforms. In an MMU based system, Xen can map its loaded
addr
On 19/10/2024 8:06 pm, Christopher Clark wrote:
> Recent patches to xen-devel indicate active interest in Argo within the Xen
> community, and as the feature has been documented and in use by
> OpenXT for multiple years, update the Xen SUPPORT.md statement of status.
>
> Signed-off-by: Christopher
On Sat, Oct 19, 2024 at 07:20:54PM +0100, Andrew Cooper wrote:
> pvh_init() sets up the mbi pointer, but leaves mbi_p at 0. This isn't
> compatbile with multiboot_fill_boot_info() starting from the physical address,
> in order to remove the use of the mbi pointer.
>
> Fixes: 038826b61e85 ("x86/bo
On 21/10/2024 2:54 pm, Marek Marczykowski-Górecki wrote:
> On Sat, Oct 19, 2024 at 07:20:54PM +0100, Andrew Cooper wrote:
>> pvh_init() sets up the mbi pointer, but leaves mbi_p at 0. This isn't
>> compatbile with multiboot_fill_boot_info() starting from the physical
>> address,
>> in order to re
On 21/10/2024 1:45 am, Daniel P. Smith wrote:
> To allow a slow conversion of x86 over to struct boot_module, start with
> replacing all references to module_t mod, only in setup.c, to the mod element
> of struct boot_module. These serves twofold, first to allow the incremental
> transition from mo
On 21/10/2024 7:00 pm, Andrew Cooper wrote:
> On 21/10/2024 1:45 am, Daniel P. Smith wrote:
>> To allow a slow conversion of x86 over to struct boot_module, start with
>> replacing all references to module_t mod, only in setup.c, to the mod element
>> of struct boot_module. These serves twofold, fi
On Mon, Oct 21, 2024 at 01:02:31PM +0100, David Woodhouse wrote:
> On Mon, 2024-10-21 at 12:53 +0100, Andrew Cooper wrote:
> >
> > > I don't quite follow how you need a sentinel value. How could you ever
> > > *not* know it, given that you have to write it to the RTE?
> > >
> > > (And you should
On 21/10/2024 3:35 pm, Andrew Cooper wrote:
> GitlabCI has no testing of Xen's PVH entrypoint. Fix this.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Marek Marczykowski-Górecki
> CC: Daniel P. Smith
> CC: Anthony PERARD
> CC: Stefano Stabellini
> CC: Michal Orzel
> CC: Doug Goldstein
>
> OS
On 18/10/2024 23:25, Julien Grall wrote:
Hi,
Hi Julien,
On 10/10/2024 15:03, Ayan Kumar Halder wrote:
After the regions have been created, now we enable the MPU. For this
we disable
the background region so that the new memory map created for the
regions take
effect. Also, we treat all RW
On 21/10/2024 13:40, Ayan Kumar Halder wrote:
On 18/10/2024 22:59, Julien Grall wrote:
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 71ebaa77ca..0203771164 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -295,6 +295,14 @@ void asmlinkage __init start_xen(unsi
Hi Ayan,
On 21/10/2024 12:25, Ayan Kumar Halder wrote:
On 18/10/2024 15:08, Julien Grall wrote:
Hi,
Hi,
On 10/10/2024 15:03, Ayan Kumar Halder wrote:
There are features in the forthcoming patches which are dependent on
MPU. For eg fixed start address.
Also, some of the Xen features (eg STA
Hi Ayan,
On 21/10/2024 12:12, Ayan Kumar Halder wrote:
On 18/10/2024 14:41, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 10/10/2024 15:03, Ayan Kumar Halder wrote:
If the BSS section is empty, then the function can just return.
This is more than "can", right? If we don't do it, we will end
Hi Ayan,
On 21/10/2024 16:07, Ayan Kumar Halder wrote:
On 18/10/2024 23:13, Julien Grall wrote:
Hi Ayan,
+.endm
+
+/*
+ * Maps the various sections of Xen (described in xen.lds.S) as
different MPU
+ * regions.
+ *
+ * Inputs:
+ * lr : Address to return to.
+ *
+ * Clobbers x0 - x5
+ *
+ *
On 21/10/2024 3:41 pm, Andrew Cooper wrote:
> On 21/10/2024 3:35 pm, Andrew Cooper wrote:
>> GitlabCI has no testing of Xen's PVH entrypoint. Fix this.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Marek Marczykowski-Górecki
>> CC: Daniel P. Smith
>> CC: Anthony PERARD
>> CC: Stefano Stabel
On Mon, Oct 21, 2024 at 12:38:13PM +0100, Andrew Cooper wrote:
> On 21/10/2024 12:10 pm, Andrew Cooper wrote:
> > On 18/10/2024 9:08 am, Roger Pau Monne wrote:
> >> When using AMD-VI interrupt remapping the vector field in the IO-APIC RTE
> >> is
> >> repurposed to contain part of the offset into
Hi Bertrand,
On Wed, Oct 16, 2024 at 10:32 AM Bertrand Marquis
wrote:
>
> Rework firmware discovery during probe:
> - move prints into the probe
> - rename ffa_version to ffa_fw_version as the variable identifies the
> version of the firmware and not the one we support
> - add error prints when
On Mon, Oct 21, 2024 at 12:38:13PM +0100, Andrew Cooper wrote:
> On 21/10/2024 12:10 pm, Andrew Cooper wrote:
> > On 18/10/2024 9:08 am, Roger Pau Monne wrote:
> >> When using AMD-VI interrupt remapping the vector field in the IO-APIC RTE
> >> is
> >> repurposed to contain part of the offset into
On Mon, 2024-10-21 at 15:51 +0100, Andrew Cooper wrote:
> On 21/10/2024 3:06 pm, Roger Pau Monné wrote:
> > On Mon, Oct 21, 2024 at 12:34:37PM +0100, David Woodhouse wrote:
> > > On Fri, 2024-10-18 at 10:08 +0200, Roger Pau Monne wrote:
> > > > When using AMD-VI interrupt remapping the vector field
flight 188312 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/188312/
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
This allows the initial x2APIC ID to be sent on the migration stream.
This allows further changes to topology and APIC ID assignment without
breaking existing hosts. Given the vlapic data is zero-extended on
restore, fix up migrations from hosts without the field by setting it to
the old convention
Make it so the APs expose their own APIC IDs in a LUT. We can use that
LUT to populate the MADT, decoupling the algorithm that relates CPU IDs
and APIC IDs from hvmloader.
Moved smp_initialise() ahead of apic_setup() in order to initialise
cpu_to_x2apicid ASAP and avoid using it uninitialised. Not
Implements the helper for mapping vcpu_id to x2apic_id given a valid
topology in a policy. The algo is written with the intention of
extending it to leaves 0x1f and extended 0x26 in the future.
The helper returns the legacy mapping when leaf 0xb is not implemented
(as is the case at the moment).
A later patch will upload LAPIC contexts as part of domain creation. In
order for it not to encounter a problem where the architectural state
does not reflect the APIC ID in the hidden state, this patch ensures
updates to the hidden state trigger an update in the architectural
registers so the APIC
Have toolstack populate the new x2APIC ID in the LAPIC save record with
the proper IDs intended for each vCPU.
Signed-off-by: Alejandro Vallejo
---
v7:
* Unchanged
---
tools/libs/guest/xg_dom_x86.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/tools/li
Refactors libacpi so that a single LUT is the authoritative source of
truth for the CPU to APIC ID mappings. This has a know-on effect in
reducing complexity on future patches, as the same LUT can be used for
configuring the APICs and configuring the ACPI tables for PVH.
Not functional change inte
Expose sensible topologies in leaf 0xb. At the moment it synthesises
non-HT systems, in line with the previous code intent.
Leaf 0xb in the host policy is no longer zapped and the guest {max,def}
policies have their topology leaves zapped instead. The intent is for
toolstack to populate them. Ther
Add a helper to populate topology leaves in the cpu policy from
threads/core and cores/package counts. It's unit-tested in
test-cpu-policy.c, but it's not connected to the rest of the code yet.
Intel's cache leaves (CPUID[4]) have limited width for core counts, so
(in the absence of real world dat
Current topology handling is close to non-existent. As things stand, APIC IDs
are allocated through the apic_id=vcpu_id*2 relation without giving any hints
to the OS on how to parse the x2APIC ID of a given CPU and assuming the guest
will assume 2 threads per core.
This series involves bringing x2
Currently used by PVH to set MTRR, will be used by a later patch to set
APIC state. Unconditionally send the hypercall, and gate overriding the
MTRR so it remains functionally equivalent.
While at it, add a missing "goto out" to what was the error condition
in the loop.
In principle this patch sh
Bump it to ARRAY_SIZE() so toolstack is able to extend a policy past
host limits (i.e: to emulate a feature not present in the host)
Signed-off-by: Alejandro Vallejo
---
v7:
* Replaces v6/patch1("Relax checks about policy compatibility")
* Bumps basic.max_leaf to ARRAY_SIZE(basic.raw) to pass
On 21/10/2024 1:45 am, Daniel P. Smith wrote:
> The purpose of struct boot_module is to encapsulate the state of boot module
> as
> it is processed by Xen. Locating boot module state struct boot_module reduces
> the number of global variables as well as the number of state variables that
> must be
On Mon, 21 Oct 2024, Jason Andryuk wrote:
> On 2024-10-21 07:04, Michal Orzel wrote:
> > A device tree node is named as follows: node-name@unit-address. The
> > unit-address must match the first address specified in the reg property
> > or be omitted if there's no reg property.
> >
> > Fix the fol
On Mon, Oct 21, 2024 at 7:03 PM Jens Wiklander
wrote:
>
> Hi Bertrand,
>
> On Wed, Oct 16, 2024 at 10:32 AM Bertrand Marquis
> wrote:
> >
> > Rework firmware discovery during probe:
> > - move prints into the probe
> > - rename ffa_version to ffa_fw_version as the variable identifies the
> > ve
On 10/16/24 02:28, Jiqian Chen wrote:
> In PVH dom0, when passthrough a device to domU, QEMU code
> xen_pt_realize->xc_physdev_map_pirq wants to use gsi, but in current codes
> the gsi number is got from file /sys/bus/pci/devices//irq, that is
> wrong, because irq is not equal with gsi, they are in
On 2024-10-21 07:04, Michal Orzel wrote:
A device tree node is named as follows: node-name@unit-address. The
unit-address must match the first address specified in the reg property
or be omitted if there's no reg property.
Fix the following issues:
1) domU modules are named as: node-name0xunit-a
On Wed, Oct 16, 2024 at 12:10 PM Jan Beulich wrote:
> While the first two patches did go in, the rest is still pending afaict. If
> the series is still deemed relevant, would you please either chase the
> missing but necessary acks, or re-submit with review comments addressed (if
> any)? If instea
On Mon, 21 Oct 2024, Andrew Cooper wrote:
> * List all the test_variants and summerise what's going on
> * Use case rather than an if/else chain for $test_variant
> * Fix indentation inside the case block
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Stefano Stabell
Hi Bertrand,
On Wed, Oct 16, 2024 at 10:32 AM Bertrand Marquis
wrote:
>
> Store the list of ABI we need in a list and go through the list instead
> of having a list of conditions inside the code.
>
> No functional change.
>
> Signed-off-by: Bertrand Marquis
> ---
> Changes in v2:
> - Store a str
Hi Bertrand,
On Wed, Oct 16, 2024 at 10:32 AM Bertrand Marquis
wrote:
>
> Fix FFA version negotiation with the firmware to follow the
> specification guidance more closely (see FF-A Specification Version 1.1
> in chapter 13.2.1).
> When the firmware returns OK we can have several cases:
> - the v
91 matches
Mail list logo
