flight 180673 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180673/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 180659
Am Mon, 15 May 2023 16:03:01 -0700 (PDT)
schrieb Stefano Stabellini :
> Given that opensuse-tumbleweed is still broken (doesn't complete the
> Xen build successfully) even after these patches, I suggest we use a
> different example?
For some reason it succeeded for me locally.
Does it fail for
flight 180678 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180678/
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 2023/5/13 10:12, Marek Marczykowski-Górecki wrote:
This makes the test script easier reusable for different runners, where
console may be connected differently. Include both console= option and
configuration for specific chosen console too (like com1= here) in the
'CONSOLE_OPTS' variable.
On Mon, 15 May 2023, Stefano Stabellini wrote:
> On Mon, 15 May 2023, Roger Pau Monné wrote:
> > On Fri, May 12, 2023 at 06:17:20PM -0700, Stefano Stabellini wrote:
> > > From: Stefano Stabellini
> > >
> > > Mapping the ACPI tables to Dom0 PVH 1:1 leads to memory corruptions of
> > > the tables
flight 180676 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180676/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 5
On Mon, 15 May 2023, Jan Beulich wrote:
> On 15.05.2023 10:48, Roger Pau Monné wrote:
> > On Fri, May 12, 2023 at 06:17:19PM -0700, Stefano Stabellini wrote:
> >> From: Stefano Stabellini
> >>
> >> Xen always generates a XSDT table even if the firmware provided a RSDT
> >> table. Instead of
On Mon, 15 May 2023, Jan Beulich wrote:
> On 13.05.2023 03:17, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > Mapping the ACPI tables to Dom0 PVH 1:1 leads to memory corruptions of
> > the tables in the guest. Instead, copy the tables to Dom0.
>
> Do you really mean "in the
On Mon, 15 May 2023, Roger Pau Monné wrote:
> On Fri, May 12, 2023 at 06:17:20PM -0700, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > Mapping the ACPI tables to Dom0 PVH 1:1 leads to memory corruptions of
> > the tables in the guest. Instead, copy the tables to Dom0.
> >
> >
flight 180675 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180675/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf cafb4f3f36e2101cab2ed6db3ea246a5a3e4708e
baseline version:
ovmf
On Tue, 2 May 2023, Olaf Hering wrote:
> Signed-off-by: Olaf Hering
Given that opensuse-tumbleweed is still broken (doesn't complete the Xen
build successfully) even after these patches, I suggest we use a
different example?
> ---
> automation/build/README.md | 6 ++
> 1 file changed, 6
On Tue, 2 May 2023, Olaf Hering wrote:
> The upcoming Leap 15.5 will come without a binary named 'python'.
> Prepare the suse images for that change.
>
> Starting with Xen 4.14 python3 can be used for build.
>
> Signed-off-by: Olaf Hering
Acked-by: Stefano Stabellini
> ---
>
On Tue, 2 May 2023, Olaf Hering wrote:
> The diffutils package is a hard requirement for building xen.
> It was dropped from the Tumbleweed base image in the past 12 months.
>
> Building with --enable-docs does now require the gs tool.
>
> Add both packages to the suse dockerfiles.
>
>
flight 180671 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180671/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 180660
On Sat, 13 May 2023, Marek Marczykowski-Górecki wrote:
> The PV passthrough test currently fails on this system
> with:
> (d1) Can't find new memory area for initrd needed due to E820 map conflict
>
> Setting e820_host=1 does not help. So, add this test with
> "allow_failure: true" until the
On Sat, 13 May 2023, Marek Marczykowski-Górecki wrote:
> This adds another physical runner to Gitlab-CI, running similar set of
> jobs that the Adler Lake one.
>
> The machine specifically is
> MinisForum UM773 Lite with AMD Ryzen 7 7735HS
>
> The PV passthrough test is skipped as currently it
On Sat, 13 May 2023, Marek Marczykowski-Górecki wrote:
> Make debugging early boot failures easier based on just CI logs.
>
> Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Stefano Stabellini
> ---
> automation/scripts/qubes-x86-64.sh | 4 ++--
> 1 file changed, 2 insertions(+), 2
On Sat, 13 May 2023, Marek Marczykowski-Górecki wrote:
> This makes the test script easier reusable for different runners, where
> console may be connected differently. Include both console= option and
> configuration for specific chosen console too (like com1= here) in the
> 'CONSOLE_OPTS'
On Mon, May 15, 2023 at 01:49:19PM -0700, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> Straightforward Dom0 PVH test based on the existing basic Smoke test for
> the Qubes runner.
>
> Signed-off-by: Stefano Stabellini
Acked-by: Marek Marczykowski-Górecki
> ---
> Changes in v2:
>
On Sat, 13 May 2023, Bernhard Beschow wrote:
> Am 21. April 2023 07:38:10 UTC schrieb "Michael S. Tsirkin" :
> >On Mon, Apr 03, 2023 at 09:41:17AM +0200, Bernhard Beschow wrote:
> >> There is currently a dedicated PIIX3 device model for use under Xen. By
> >> reusing
> >> existing PCI API during
From: Stefano Stabellini
Straightforward Dom0 PVH test based on the existing basic Smoke test for
the Qubes runner.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- rename dom0pvh to extra_xen_opts
---
automation/gitlab-ci/test.yaml | 8
automation/scripts/qubes-x86-64.sh
flight 180670 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180670/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 180278
build-arm64-pvops
On Sat, May 6, 2023 at 4:35 AM John Paul Adrian Glaubitz
wrote:
>
> Hi Vishal!
>
> On Mon, 2023-05-01 at 12:28 -0700, Vishal Moola (Oracle) wrote:
> > Part of the conversions to replace pgtable constructor/destructors with
> > ptdesc equivalents. Also cleans up some spacing issues.
> >
> >
flight 180672 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180672/
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 Sun, Mar 19, 2023 at 08:05:54PM -0400, Jason Andryuk wrote:
> diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c
> index 8c6e9a1716..51a72b432d 100644
> --- a/hw/xen/xen-host-pci-device.c
> +++ b/hw/xen/xen-host-pci-device.c
> @@ -33,13 +34,101 @@
> #define
Bits through 24 are already defined, meaning that we're not far off needing
the second word. Put both in right away.
The bool bitfield names in the arch_caps union are unused, and somewhat out of
date. They'll shortly be automatically generated.
Signed-off-by: Andrew Cooper
---
CC: Jan
We are about to move MSR_ARCH_CAPS into featureset, but the order of
operations (copy raw policy, then copy x86_capabilitiles[] in) will end up
clobbering the ARCH_CAPS value currently visible in the Host policy.
To avoid this transient breakage, read from raw_cpu_policy rather than
modifying it
Also cleanup of the various special cases we've already got. No practical
change to a system, but this is the trimmed view of the featuresets on a
Cascade Lake CPU with the series in place.
KEY ... 10Al 10Ah
Static sets:
Known ...
Extend x86_cpu_policy_fill_native() with a read of ARCH_CAPS based on the
CPUID information just read, which removes the need handling it specially in
calculate_raw_cpu_policy().
Extend generic_identify() to read ARCH_CAPS into x86_capability[], which is
fed into the Host Policy. This in turn
Right now, dom0's feature configuration is split between between the common
path and a dom0-specific one. This mostly is by accident, and causes some
very subtle bugs.
First, start by clearly defining init_dom0_cpuid_policy() to be the domain
that Xen builds automatically. The late hwdom case
We already have common and default feature adjustment helpers. Introduce one
for max featuresets too.
Offer MSR_ARCH_CAPS unconditionally in the max policy, and stop clobbering the
data inherited from the Host policy. This will be necessary level a VM safely
for migration. Note: ARCH_CAPS is
Seed the default visibility from the dom0 special case, which for the most
part just exposes the *_NO bits. Insert a block dependency from the ARCH_CAPS
CPUID bit to the entire content of the MSR.
The overall CPUID bit is still max-only, so all of MSR_ARCH_CAPS is hidden in
the default policies.
On 13.05.2023 03:17, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> Mapping the ACPI tables to Dom0 PVH 1:1 leads to memory corruptions of
> the tables in the guest. Instead, copy the tables to Dom0.
Do you really mean "in the guest" (i.e. from Xen's perspective, i.e.
ignoring that
On 15.05.2023 10:48, Roger Pau Monné wrote:
> On Fri, May 12, 2023 at 06:17:19PM -0700, Stefano Stabellini wrote:
>> From: Stefano Stabellini
>>
>> Xen always generates a XSDT table even if the firmware provided a RSDT
>> table. Instead of copying the XSDT header from the firmware table (that
>>
flight 180669 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180669/
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 15/05/2023 12:49, Ayan Kumar Halder wrote:
Hi Julien
Hi Ayan,
On 15/05/2023 11:43, Julien Grall wrote:
On 15/05/2023 11:30, Ayan Kumar Halder wrote:
AFAICT, this approach would be incorrect because we wouldn't take
into account any restriction from the SMMU susbystem (it may
On 12-05-23, 11:43, Anthony PERARD wrote:
> On Thu, May 11, 2023 at 01:20:43PM +0530, Viresh Kumar wrote:
> > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> > index 24ac92718288..0405f6efe62a 100644
> > --- a/docs/man/xl.cfg.5.pod.in
> > +++ b/docs/man/xl.cfg.5.pod.in
> > @@
On Fri, May 12, 2023 at 11:07:56PM +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> Implement the validation function which tells the core code whether
> parallel bringup is possible.
>
> The only condition for now is that the kernel does not run in an encrypted
> guest as these will
Hi Julien
On 15/05/2023 11:43, Julien Grall wrote:
On 15/05/2023 11:30, Ayan Kumar Halder wrote:
AFAICT, this approach would be incorrect because we wouldn't take
into account any restriction from the SMMU susbystem (it may support
less than what the processor support).
By the restriction
flight 180668 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180668/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 180278
build-arm64-pvops
v3:
* Move LCAP setters from patch 2 to patch 1
* Comment on rationale for checking CPUID faulting before CpuidUserDis on AMD
Nowadays AMD supports trapping the CPUID instruction from ring>0 to ring0,
(CpuidUserDis) akin to Intel's "CPUID faulting". There is a difference in
that the toggle bit
Because CpuIdUserDis is reported in CPUID itself, the extended leaf
containing that bit must be retrieved before calling c_early_init()
Signed-off-by: Alejandro Vallejo
---
v3:
* Moved LCAP_* setters to the callers in patch1/v3
* Added rationale for checking CPUID faulting before CpuidUserDis
Move vendor-specific checks to the vendor-specific callers. While at it
move the synth cap setters to the callers too, as it's needed for a later
patch and it's not a functional change either.
No functional change.
Signed-off-by: Alejandro Vallejo
Reviewed-by: Jan Beulich
---
v3:
* Moved the
On 15/05/2023 11:30, Ayan Kumar Halder wrote:
AFAICT, this approach would be incorrect because we wouldn't take into
account any restriction from the SMMU susbystem (it may support less
than what the processor support).
By the restriction from SMMU subsystem, I think you mean
On 15/05/2023 10:25, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 11/05/2023 12:45, Ayan Kumar Halder wrote:
On 03/05/2023 13:20, Julien Grall wrote:
Hi,
Hi Julien,
I have some clarification.
On 28/04/2023 18:55, Ayan Kumar Halder wrote:
Restructure the code so that one can use
On 15/05/2023 8:46 am, Jan Beulich wrote:
> On 12.05.2023 14:45, Andrew Cooper wrote:
>> When adding new featureset words, it is convenient to split the work into
>> several patches. However, GCC 12 spotted that the way we prefer to split the
>> work results in a real (transient) breakage whereby
> On 12 May 2023, at 00:22, Stefano Stabellini wrote:
>
> From: Stefano Stabellini
>
> Add the Mandatory rules agreed by the MISRA C working group to
> docs/misra/rules.rst.
>
> Signed-off-by: Stefano Stabellini
> ---
Hi Stefano,
I’ve tried this patch with our integration tool
On Fri, May 12, 2023 at 06:17:20PM -0700, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> Mapping the ACPI tables to Dom0 PVH 1:1 leads to memory corruptions of
> the tables in the guest. Instead, copy the tables to Dom0.
>
> This is a workaround.
>
> Signed-off-by: Stefano Stabellini
Hi Ayan,
On 11/05/2023 12:45, Ayan Kumar Halder wrote:
On 03/05/2023 13:20, Julien Grall wrote:
Hi,
Hi Julien,
I have some clarification.
On 28/04/2023 18:55, Ayan Kumar Halder wrote:
Restructure the code so that one can use pa_range_info[] table for both
ARM_32 as well as ARM_64.
Hi Michal,
On 11/05/2023 14:02, Michal Orzel wrote:
Propagate return code correctly + fix the format specifiers.
Michal Orzel (2):
xen/arm: domain_build: Propagate return code of map_irq_to_domain()
xen/arm: domain_build: Fix format specifiers in
map_{dt_}irq_to_domain()
I have
On 15/05/2023 10:07, Michal Orzel wrote:
Reviewed-by: Julien Grall
Thanks,
Bare in mind that Rahul responded in HTML so there will be a
Thanks for the reminder! The patch is now committed.
Cheers,
--
Julien Grall
flight 180666 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180666/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-qemut-rhel6hvm-amd 14 guest-start/redhat.repeat fail in 180660
pass in 180666
On 15/05/2023 11:06, Julien Grall wrote:
>
>
> On 15/05/2023 10:03, Michal Orzel wrote:
>> Hi Julien,
>
> Hi Michal,
>
>>
>> On 15/05/2023 10:56, Julien Grall wrote:
>>>
>>>
>>> Hi,
>>>
>>> On 12/05/2023 15:35, Michal Orzel wrote:
At the moment, even in case of a SMMU being I/O
On 15/05/2023 10:03, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 15/05/2023 10:56, Julien Grall wrote:
Hi,
On 12/05/2023 15:35, Michal Orzel wrote:
At the moment, even in case of a SMMU being I/O coherent, we clean the
updated PT as a result of not advertising the coherency
Hi Julien,
On 15/05/2023 10:56, Julien Grall wrote:
>
>
> Hi,
>
> On 12/05/2023 15:35, Michal Orzel wrote:
>> At the moment, even in case of a SMMU being I/O coherent, we clean the
>> updated PT as a result of not advertising the coherency feature. SMMUv3
>> coherency feature means that page
Hi Michal,
On 11/05/2023 14:02, Michal Orzel wrote:
IRQ is of unsigned type so %u should be used. When printing domain id,
%pd should be the correct format to maintain the consistency.
Also, wherever possible, reduce the number of splitted lines for printk().
Reviewed-by: Julien Grall
I
Hi Michal,
On 11/05/2023 14:02, Michal Orzel wrote:
From map_dt_irq_to_domain() we are assigning a return code of
map_irq_to_domain() to a variable without checking it for an error.
Fix it by propagating the return code directly since this is the last
call.
Fixes: 467e5cbb2ffc ("xen: arm:
On 15/05/2023 07:46, Michal Orzel wrote:
Hi Ayan,
Hi Michal,
On 12/05/2023 18:59, Ayan Kumar Halder wrote:
Hi Michal,
On 12/05/2023 15:35, Michal Orzel wrote:
At the moment, even in case of a SMMU being I/O coherent, we clean the
updated PT as a result of not advertising the coherency
Hi Oleg,
On 15/05/2023 10:51, Oleg Nikitenko wrote:
>
>
>
> Hello guys,
>
> Thanks a lot.
> After a long problem list I was able to run xen with Dom0 with a cache color.
> One more question from my side.
> I want to run a guest with color mode too.
> I inserted a string into guest
Hi Michal,
On 12/05/2023 15:35, Michal Orzel wrote:
Based on the work done for SMMU v1,v2 by commit:
080dcb781e1bc3bb22f55a9dfdecb830ccbabe88
Michal Orzel (2):
xen/arm: smmuv3: Constify arm_smmu_get_by_dev() parameter
I have committed this patch.
xen/arm: smmuv3: Advertise coherent
Hi,
On 12/05/2023 15:35, Michal Orzel wrote:
At the moment, even in case of a SMMU being I/O coherent, we clean the
updated PT as a result of not advertising the coherency feature. SMMUv3
coherency feature means that page table walks, accesses to memory
structures and queues are I/O coherent
On Fri, May 12, 2023 at 06:17:19PM -0700, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> Xen always generates a XSDT table even if the firmware provided a RSDT
> table. Instead of copying the XSDT header from the firmware table (that
> might be missing), generate the XSDT header from a
Hi Michal,
On 12 May 2023, at 3:35 pm, Michal Orzel wrote:
At the moment, even in case of a SMMU being I/O coherent, we clean the
updated PT as a result of not advertising the coherency feature. SMMUv3
coherency feature means that page table walks, accesses to memory
structures and queues are
Hi Michal,
> On 12 May 2023, at 3:35 pm, Michal Orzel wrote:
>
> At the moment, even in case of a SMMU being I/O coherent, we clean the
> updated PT as a result of not advertising the coherency feature. SMMUv3
> coherency feature means that page table walks, accesses to memory
> structures and
On Fri, May 12, 2023 at 05:52:25PM -0700, Elliott Mitchell wrote:
> From tools/libs/light/libxl_x86.c: libxl__arch_passthrough_mode_setdefault()
>
> "passthrough not yet supported for x86 PVH guests\n"
>
> So PVH is recommended for most situations, but it is /still/ impossible
> to pass hardware
If the vsyscall page is moved out of the fixmap area, then FIXADDR_TOP
would be below the vsyscall page. Therefore, it should be pinned up to
VSYSCALL_ADDR if vsyscall is enabled.
Suggested-by: Lai Jiangshan
Signed-off-by: Hou Wenlong
---
arch/x86/xen/mmu_pv.c | 12 +---
1 file
In order to unify FIXADDR_TOP for x86 and allow the fixmap area to be
movable, the vsyscall page should be mapped individually. However, for
XENPV guests, the vsyscall page needs to be mapped into the user
pagetable as well. Therefore, a new PVMMU operation is introduced to
assist in mapping the
This patchset unifies FIXADDR_TOP as a variable for x86, allowing the
fixmap area to be movable and relocated with the kernel image in the
x86/PIE patchset [0]. This enables the kernel image to be relocated in
the top 512G of the address space.
[0]
Hi Michal,
> On 12 May 2023, at 3:35 pm, Michal Orzel wrote:
>
> This function does not modify its parameter 'dev' and it is not supposed
> to do it. Therefore, constify it.
>
> Signed-off-by: Michal Orzel
Reviewed-by: Rahul Singh
Regards,
Rahul
On 12.05.2023 14:45, Andrew Cooper wrote:
> When adding new featureset words, it is convenient to split the work into
> several patches. However, GCC 12 spotted that the way we prefer to split the
> work results in a real (transient) breakage whereby the policy <-> featureset
> helpers perform
On 13.05.2023 02:52, Elliott Mitchell wrote:
> From tools/libs/light/libxl_x86.c: libxl__arch_passthrough_mode_setdefault()
>
> "passthrough not yet supported for x86 PVH guests\n"
>
> So PVH is recommended for most situations, but it is /still/ impossible
> to pass hardware devices to PVH
On 12.05.2023 23:03, Stewart Hildebrand wrote:
> On 5/12/23 03:25, Jan Beulich wrote:
>> On 11.05.2023 21:16, Stewart Hildebrand wrote:
>>> @@ -762,9 +767,20 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
>>> pdev->domain = NULL;
>>> goto out;
>>> }
>>> +#ifdef
On 12.05.2023 23:03, Stewart Hildebrand wrote:
> On 5/12/23 03:25, Jan Beulich wrote:
>> On 11.05.2023 21:16, Stewart Hildebrand wrote:
>>> @@ -762,9 +767,20 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
>>> pdev->domain = NULL;
>>> goto out;
>>> }
>>> +#ifdef
Hi Ayan,
On 12/05/2023 18:59, Ayan Kumar Halder wrote:
> Hi Michal,
>
> On 12/05/2023 15:35, Michal Orzel wrote:
>> At the moment, even in case of a SMMU being I/O coherent, we clean the
>> updated PT as a result of not advertising the coherency feature. SMMUv3
>> coherency feature means that
74 matches
Mail list logo
