flight 187748 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187748/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 20 debian-hvm-install/l1/l2 fail REGR. vs.
187720
Tests whi
The pull request you sent on Thu, 19 Sep 2024 08:06:41 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-6.12-rc1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/19a519ca87b59a0031e1295674b1af0d6da83f70
Thank you!
--
Deet-doot-dot, I
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-6.12-rc1-tag
xen: branch for v6.12-rc1
It contains the following patches:
- A 7 patch series fixing a boot problem as a Xen dom0 on some AMD systems
- A 3 patch series fixing Xen PVH
flight 187747 xen-unstable real [real]
flight 187752 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187747/
http://logs.test-lab.xenproject.org/osstest/logs/187752/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
flight 187750 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187750/
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 Thu, 12 Sep 2024, Jiqian Chen wrote:
> On PVH dom0, when passthrough a device to domU, QEMU and xl tools
> want to use gsi number to do pirq mapping, see QEMU code
> xen_pt_realize->xc_physdev_map_pirq, and xl code
> pci_add_dm_done->xc_physdev_map_pirq, but in current codes, the gsi
> number is
On Thu, 12 Sep 2024, Jiqian Chen wrote:
> 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 assigning a device to passthrough, proactively setup the gsi
> of the device during that process.
>
On Thu, 12 Sep 2024, Jiqian Chen wrote:
> 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 devic
flight 187743 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187743/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187734
test-amd64-amd64-xl-qemut-win7-amd64
The Xen community is already informally following both rules. Let's make
it explicit. Both rules have zero violations, only cautions. While we
want to go down to zero cautions in time, adding both rules to rules.rst
enables us to immediately make both rules gating in the ECLAIR job part
of gitlab-c
On Tue, 17 Sep 2024, Nicola Vetrini wrote:
> On 2024-09-17 08:13, Bertrand Marquis wrote:
> > Hi Stefano,
> >
> > > On 17 Sep 2024, at 01:02, Stefano Stabellini
> > > wrote:
> > >
> > > The Xen community is already informally following both rules. Let's make
> > > it explicit. Both rules have ze
Secondary cpus initialization is not yet supported. Thus, we print an
appropriate message and put the secondary cpus in WFE state.
Signed-off-by: Ayan Kumar Halder
---
Changes from :-
v1 - 1. NR_CPUS is defined as 1 for MPU
2. Added a message in enable_secondary_cpu_mm()
xen/arch/Kconfig
Define enable_boot_cpu_mm() for the AArch64-V8R system.
Like boot-time page table in MMU system, we need a boot-time MPU
protection region configuration in MPU system so Xen can fetch code and
data from normal memory.
To do this, Xen maps the following sections of the binary as separate
regions (
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 address to
this virtual start address. So, on Armv8-A platforms, the Xen start address does
not need to be configurable. But on Armv8-R pla
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.
Thus, this patch introduces a choice between MMU and MPU for the type
of memory management system. By d
We have enabled early booting of R82.
Ayan Kumar Halder (4):
xen/arm: mpu: Introduce choice between MMU and MPU
xen/arm: mpu: Define Xen start address for MPU systems
xen/arm: mpu: Create boot-time MPU protection regions
xen/arm: mpu: Implement a dummy enable_secondary_cpu_mm
SUPPORT.md
flight 187739 qemu-mainline real [real]
flight 187746 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187739/
http://logs.test-lab.xenproject.org/osstest/logs/187746/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 187741 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187741/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187728
test-amd64-amd64-libvirt-xsm 15 migrate-s
flight 187745 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187745/
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 8/28/24 06:36, Jan Beulich wrote:
> On 27.08.2024 05:59, Stewart Hildebrand wrote:
>> +list_for_each_entry_safe(vf_pdev, tmp,
>> &pdev->physfn.vf_list,
>> + virtfn.entry)
>> +ret = pci_remove_device(vf_pdev->sbdf.seg,
>
On Wed, Sep 18, 2024 at 04:35:21PM +0300, Sergiy Kibrik wrote:
> 18.09.24 12:41, Roger Pau Monné:
> > On Wed, Sep 18, 2024 at 12:29:39PM +0300, Sergiy Kibrik wrote:
> > > 16.09.24 22:57, Stefano Stabellini:
> > > > On Mon, 16 Sep 2024, Roger Pau Monné wrote:
> > > > > On Mon, Sep 16, 2024 at 09:37:
18.09.24 12:41, Roger Pau Monné:
On Wed, Sep 18, 2024 at 12:29:39PM +0300, Sergiy Kibrik wrote:
16.09.24 22:57, Stefano Stabellini:
On Mon, 16 Sep 2024, Roger Pau Monné wrote:
On Mon, Sep 16, 2024 at 09:37:57AM +0300, Sergiy Kibrik wrote:
Introduce config option X86_PMTIMER so that pmtimer dr
Moves sti directly after the cr2 read and immediately after the #PF
handler.
While in the area, remove redundant q suffix to a movq in entry.S
Signed-off-by: Alejandro Vallejo
---
Got lost alongside other patches. Here's the promised v2.
pipeline:
https://gitlab.com/xen-project/people/agvallej
Hi,
On 12/09/2024 17:59, Rahul Singh wrote:
On 4 Sep 2024, at 1:43 PM, Michal Orzel wrote:
SMR masking support allows deriving a mask either using a 2-cell iommu
specifier (per master) or stream-match-mask SMMU dt property (global
config). Even though the mask is stored in the fwid when addin
flight 187744 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187744/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5901f19a877c87de73f6b28265ad5db60b2239e1
baseline version:
ovmf 21e8a85653e104385bfb8
flight 187737 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187737/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 187730
test-amd64-amd64-xl-qemuu-ws16-amd64
On Wed, Sep 18, 2024 at 12:29:39PM +0300, Sergiy Kibrik wrote:
> 16.09.24 22:57, Stefano Stabellini:
> > On Mon, 16 Sep 2024, Roger Pau Monné wrote:
> > > On Mon, Sep 16, 2024 at 09:37:57AM +0300, Sergiy Kibrik wrote:
> > > > Introduce config option X86_PMTIMER so that pmtimer driver can be
> > >
16.09.24 22:57, Stefano Stabellini:
On Mon, 16 Sep 2024, Roger Pau Monné wrote:
On Mon, Sep 16, 2024 at 09:37:57AM +0300, Sergiy Kibrik wrote:
Introduce config option X86_PMTIMER so that pmtimer driver can be disabled on
systems that don't need it.
Same comment as in the VGA patch, you need t
Allows to call C code earlier.
In order to safely call C code we need to setup stack, selectors and BSS.
Signed-off-by: Frediano Ziglio
---
Changes since v1:
- improve commit message;
- improve some comments;
- fix some code style (spacing);
- set trampoline_phys as 32 bit value;
- use PAGE_SIZE
No need to have it coded in assembly.
Signed-off-by: Frediano Ziglio
---
Changes since v1:
- update some comments;
- explain why %ebx is saved before calling efi_parse_mbi2;
- move lea before test instruction;
- removed asmlinkage from efi_multiboot2 and add to efi_parse_mbi2;
- fix line length;
Tag structure should contain at least the tag header.
Entire tag structure must be contained inside MBI2 data.
Signed-off-by: Frediano Ziglio
---
xen/arch/x86/efi/parse-mbi2.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/efi/parse-mbi2.c b/xen/arch/x86/efi
The 2 code paths were sharing quite some common code, reuse it instead
of having duplications.
Use %dl register to store boot type before running common code.
Using a 8 bit register reduces code size.
Signed-off-by: Frediano Ziglio
---
Changes since v1:
- use %dl instead of %ebp to reduce code si
This series came from part of the work of removing duplications between
boot code and rewriting part of code from assembly to C.
First 2 patches rework BIOS/PVH paths to reuse some code.
Third patch rewrites EFI code in pure C.
Changes since v1, more details in specific commits:
- style updates;
-
Currently mwait_idle driver in Xen only implements support for Intel CPUs.
Thus in order to reduce dead code in non-Intel build configurations it can
be made explicitly dependant on CONFIG_INTEL option.
Signed-off-by: Sergiy Kibrik
CC: Jan Beulich
---
v1 patch here:
https://lore.kernel.org/xen-d
Xen's implementation of PSR only supports Intel CPUs right now, hence it can be
made dependant on CONFIG_INTEL build option.
Since platform implementation is not limited to single vendor, intermediate
option CONFIG_PSR introduced, which selected by CONFIG_INTEL.
When !PSR then PSR-related sysctls
35 matches
Mail list logo
