flight 181657 xen-unstable real [real]
flight 181664 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181657/
http://logs.test-lab.xenproject.org/osstest/logs/181664/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Hi Julien,
Thank you for your answer. Do you have any advice on how to debug the
issue?
I have very little experience with xen so I think I still need
debugging even if I can
get MBI-gen's tech doc...
Best regards,
Jiatong Shen
On Fri, Jun 30, 2023 at 5:42 AM Julien Grall wrote:
> On
Previous commits added a transition point from multiboot v1 structures
to the new boot info structures at the earliest common point for all the
x86 entrypoints. The result is that each of the entrypoints would
construct a multiboot v1 structure from the structures used by each
entrypoint. This
This change enables and begins introducion of into
Arm builds: it replace the enum definition of bootmodule_kind with
bootmod_type_t which is a fixed size type as needed for packed structs,
to be used in the boot structures in subsequent changes.
Signed-off-by: Christopher Clark
Signed-off-by:
Change the XSM implementation to use the boot info structure instead of
the multiboot module_map.
Drops a dependency on CONFIG_MULTIBOOT, so boot module logic is now
used whenever the DEVICE_TREE specific logic (for Arm) is not, with the
bootinfo header conditionally included to ensure no change
Pointer fields within structs need to be defined as fixed size types in
the x86 boot build environment. Using a typedef for the field type
enables the definition to be changed in the 32-bit boot build and
the main hypervisor build, allowing for a single common structure
definition and a common
The header contains structures that will be used in efi
logic prior to the main start of Xen, so will soon be included in Arm
builds. This same header will also used in early x86 boot, where asm/*
headers are not reachable and yet it contains a needed include of
, so...
Add initial per-arch
Pointer fields within structs need to be defined as fixed size types in
the x86 boot build environment. Using a typedef for the field type
rather than a struct pointer type enables the type definition to
be changed in the 32-bit boot build and the main hypervisor build,
allowing for a single
This is a v2 series of work for Hyperlaunch for the Xen hypervisor,
implementing a subset of the v1 series and functionality, with changes
made to address the community feedback provided on the patches in v1.
The patches in this series are primarily derived from patches 2-4 of the
v1 full series,
Adjust the PV and PVH dom0 construction entry points to take boot module
structures as parameters, and add further fields to the boot module
structures to plumb the data needed to support this use. Populate these
from the multiboot module data.
This change removes multiboot from the PV and PVH
An initial step towards a non-multiboot internal representation of boot
modules for common code, starting with x86 setup and converting the
fields that are accessed for the startup calculations.
Introduce a new header, , and populate it with a new
boot_info structure initially containing a count
Next step in incremental work towards adding a non-multiboot internal
representation of boot modules, converting the fields being accessed for
the startup calculations.
Move the per-module scan logic into a dedicated function from the
iteration loop and set the BOOTMOD_UCODE module type when
Next step in incremental work towards adding a non-multiboot internal
representation of boot modules, converting the fields being accessed for
the startup calculations.
Add a new array of structs for per-boot-module state, though only
allocate space for a single array entry in this change since
To convert the x86 boot logic from multiboot to boot module structures,
change the bootstrap map function to accept a boot module parameter.
To allow incremental change from multiboot to boot modules across all
x86 setup logic, provide a temporary inline wrapper that still accepts a
multiboot
On Fri, 29 Jun 2023, Luca Fancellu wrote:
> The "dom0less" feature was intended to be the feature where a domU
> domain could be launched without the control domain (Dom0)
> intervention, however the name seems to suggest that Dom0 cannot
> be part of the configuration, while instead it's a
On Tue, May 30, 2023 at 02:04:26PM +0200, Jan Beulich wrote:
> On 05.05.2023 23:25, Marek Marczykowski-Górecki wrote:
> > Not the whole page, which may contain other registers too. In fact
> > on Tiger Lake and newer (at least), this page do contain other registers
> > that Linux tries to use.
>
On Tue, May 30, 2023 at 01:56:34PM +0200, Jan Beulich wrote:
> On 05.05.2023 23:25, Marek Marczykowski-Górecki wrote:
> > In some cases, only few registers on a page needs to be write-protected.
> > Examples include USB3 console (64 bytes worth of registers) or MSI-X's
> > PBA table (which doesn't
Am 30. Juni 2023 11:32:42 UTC schrieb Olaf Hering :
>Fri, 30 Jun 2023 08:05:29 + Bernhard Beschow :
>
>> Yes. Have a look for piix3/piix4 here:
>> https://www.intel.com/design/archives/chipsets/440/index.htm
>
>This is hidden behind a login or whatever.
None of the links ask annoying
On Fri, Jun 30, 2023 at 10:12:10AM +0100, Luca Fancellu wrote:
> This is an RFC to get the feeling of the community about the name
> change, for now it's everything in one patch just to see how it
> will look like, if there is interest on proceeding into it, I can
> split in more commit.
I seem
flight 181653 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181653/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict broken
flight 181661 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181661/
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
flight 181659 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181659/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5a13f5c2fa5ada2eb2fcb961aa3745fd236620bd
baseline version:
ovmf
Hi,
The subject stay "1/2" but I don't see any "2/2" nor cover letter. Where
can I find the rest of the series?
Cheers,
--
Julien Grall
Hi George,
On 30/06/2023 12:37, George Dunlap wrote:
The credit scheduler tries as hard as it can to ensure that it always
runs scheduling units with positive credit (PRI_TS_UNDER) before
running those with negative credit (PRI_TS_OVER). If the next
runnable scheduling unit is of priority
flight 181656 xen-unstable-smoke real [real]
flight 181658 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181656/
http://logs.test-lab.xenproject.org/osstest/logs/181658/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
On 30/06/2023 2:18 pm, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
> index 0eaef82e5145..bdf45f8387e8 100644
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -51,6 +51,8 @@ bool __read_mostly amd_acpi_c1e_quirk;
> bool __ro_after_init
On Fri, 30 Jun 2023 at 12:38, George Dunlap wrote:
> ...
> Add a parameter, load_balance_ratelimit, to limit the frequency of
> load balance operations on a given pcpu. Default this to 1
> millisecond.
> ...
> Without this patch, on a system with a vcpu:pcpu ratio of 2:1, running
> Windows
Hi,
On 6/30/2023 12:14 AM, Chen, Jiqian wrote:
Hi Dongwon,
On 2023/6/30 00:53, Kim, Dongwon wrote:
This method - letting QEMU not remove resources would work on S3 case but with
S4, the QEMU would lose all the resources anyway as the process will be
terminated. So objects restoring was only
On 26/06/2023 04:34, Penny Zheng wrote:
CAUTION: This message has originated from an External Source. Please use proper
judgment and caution when opening attachments, clicking links, or responding to
this email.
This commit expands xen_mpumap_update/xen_mpumap_update_entry to include
On 30/06/23 16:21, Andrew Cooper wrote:
On 30/06/2023 8:36 am, Federico Serafini wrote:
Hello Stefano,
On 29/06/23 21:47, Stefano Stabellini wrote:
On Thu, 29 Jun 2023, Federico Serafini wrote:
Change the parameter names of function declarations to be consistent
with the names used in the
flight 181649 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181649/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw broken
It was previously noted that CALL/BUG is a weird combination, but there is
good reason to use this pattern.
Introduce an explicit tailcall macro make it clearer in context.
No functional change.
Reported-by: Jan Beulich
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
Hi Penny,
On 26/06/2023 04:34, Penny Zheng wrote:
CAUTION: This message has originated from an External Source. Please use proper
judgment and caution when opening attachments, clicking links, or responding to
this email.
Xen is using page as the smallest granularity for memory managment.
Hi,
On 30/06/2023 15:42, Ayan Kumar Halder wrote:
Hi Julien,
On 30/06/2023 12:22, Julien Grall wrote:
On 30/06/2023 11:49, Ayan Kumar Halder wrote:
On 30/06/2023 05:07, Penny Zheng wrote:
Hi,
Hi Penny,
On 2023/6/30 01:22, Ayan Kumar Halder wrote:
On 26/06/2023 04:34, Penny Zheng
Hi Julien,
On 30/06/2023 12:22, Julien Grall wrote:
On 30/06/2023 11:49, Ayan Kumar Halder wrote:
On 30/06/2023 05:07, Penny Zheng wrote:
Hi,
Hi Penny,
On 2023/6/30 01:22, Ayan Kumar Halder wrote:
On 26/06/2023 04:34, Penny Zheng wrote:
CAUTION: This message has originated from an
flight 181646 xen-unstable real [real]
flight 181655 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181646/
http://logs.test-lab.xenproject.org/osstest/logs/181655/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 30/06/2023 8:36 am, Federico Serafini wrote:
> Hello Stefano,
>
> On 29/06/23 21:47, Stefano Stabellini wrote:
>> On Thu, 29 Jun 2023, Federico Serafini wrote:
>>> Change the parameter names of function declarations to be consistent
>>> with the names used in the corresponding function
On 29/06/2023 4:55 pm, Federico Serafini wrote:
> Federico Serafini (5):
> x86: swap parameter names of hvm_copy_context_and_params() declaration
> x86: change parameter names of nestedhvm_vcpu_iomap_get() definition
> x86/vlapic: change parameter names in function definitions
I've
flight 181654 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181654/
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
As specified on Errata 1474:
"A core will fail to exit CC6 after about 1044 days after the last
system reset. The time of failure may vary depending on the spread
spectrum and REFCLK frequency."
Detect when running on AMD Zen2 (family 17h models 30-3fh, 60-6fh or
70-7fh) and setup a timer to
Hi,
On 30/06/2023 13:57, Andrew Cooper wrote:
On 30/06/2023 1:45 pm, George Dunlap wrote:
From: George Dunlap
It's only called from another __init function.
Signed-off-by: George Dunlap
---
This is a random patch I found in a branch named "xsa345-post".
I have far too many branches like
Hi Oleksandr,
Thanks for reviewing the code.
> On 29 Jun 2023, at 7:06 pm, Oleksandr Tyshchenko
> wrote:
>
>
>
> On 29.06.23 18:46, Rahul Singh wrote:
>
> Hello Rahul
>
>
>> Xen 4.17 supports the creation of static evtchns. To allow user space
>> application to bind static evtchns
On 30/06/2023 1:45 pm, George Dunlap wrote:
> From: George Dunlap
>
> It's only called from another __init function.
>
> Signed-off-by: George Dunlap
> ---
> This is a random patch I found in a branch named "xsa345-post".
I have far too many branches like that...
Acked-by: Andrew Cooper
From: George Dunlap
It's only called from another __init function.
Signed-off-by: George Dunlap
---
This is a random patch I found in a branch named "xsa345-post".
CC: Andrew Cooper
CC: Jan Beulich
CC: Roger Pau Monne
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/arm/mm.c | 2 +-
On 29/06/2023 1:17 pm, Alejandro Vallejo wrote:
> diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
> index 168cd58f36..b2443b6831 100644
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -304,24 +304,20 @@ static void cf_check early_init_intel(struct
>
The credit scheduler tries as hard as it can to ensure that it always
runs scheduling units with positive credit (PRI_TS_UNDER) before
running those with negative credit (PRI_TS_OVER). If the next
runnable scheduling unit is of priority OVER, it will always run the
load balancer, which will scour
On large systems with many vcpus yielding due to spinlock priority
inversion, it's not uncommon for a vcpu to yield its timeslice, only
to be immediately stolen by another pcpu looking for higher-priority
work.
To prevent this:
* Keep the YIELD flag until a vcpu is removed from a runqueue
*
Fri, 30 Jun 2023 08:05:29 + Bernhard Beschow :
> Yes. Have a look for piix3/piix4 here:
> https://www.intel.com/design/archives/chipsets/440/index.htm
This is hidden behind a login or whatever.
I should be able to come up with a commit message without hardware specs being
available.
On 30/06/2023 11:49, Ayan Kumar Halder wrote:
On 30/06/2023 05:07, Penny Zheng wrote:
Hi,
Hi Penny,
On 2023/6/30 01:22, Ayan Kumar Halder wrote:
On 26/06/2023 04:34, Penny Zheng wrote:
CAUTION: This message has originated from an External Source. Please
use proper judgment and
On 29/06/2023 1:17 pm, Alejandro Vallejo wrote:
> Intel CPUs have a bit in MSR_IA32_MISC_ENABLE that may prevent the NX bit
> from being advertised. Clear it unconditionally if we can't find the NX
> feature right away on boot.
>
> The conditions for the MSR being read on early boot are (in this
On 29/06/2023 1:17 pm, Alejandro Vallejo wrote:
> Currently libxl and the x86-emulator tests carry their own versions. Factor
> those out into the common macros header so every library can make use of
> it. This is required so the following patch can add this macro to a header
> used both in Xen
On 30/06/2023 05:07, Penny Zheng wrote:
Hi,
Hi Penny,
On 2023/6/30 01:22, Ayan Kumar Halder wrote:
On 26/06/2023 04:34, Penny Zheng wrote:
CAUTION: This message has originated from an External Source. Please
use proper judgment and caution when opening attachments, clicking
links, or
On 30/06/2023 10:43 am, Julien Grall wrote:
> On 30/06/2023 10:26, Ayan Kumar Halder wrote:
>> On 29/06/2023 12:55, Julien Grall wrote:
> Furthermore, from my understanding, at least on Armv8-A, there are
> caching problem because you will need to save some registers (for
> the call to
On 30/06/2023 10:26, Ayan Kumar Halder wrote:
On 29/06/2023 12:55, Julien Grall wrote:
Furthermore, from my understanding, at least on Armv8-A, there are
caching problem because you will need to save some registers (for
the call to set_boot_mpumap()) on the stack with cache disabled.
This
On 29/06/2023 12:55, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 29/06/2023 12:21, Ayan Kumar Halder wrote:
On 28/06/2023 14:42, Julien Grall wrote:
What's the guarantee that the compiler will not generate any
instructions that could generate an alignment fault?
I thought by writing in
(+ Christopher and Daniel)
On 30/06/2023 10:12, Luca Fancellu wrote:
The "dom0less" feature was intended to be the feature where a domU
domain could be launched without the control domain (Dom0)
intervention, however the name seems to suggest that Dom0 cannot
be part of the configuration, while
The "dom0less" feature was intended to be the feature where a domU
domain could be launched without the control domain (Dom0)
intervention, however the name seems to suggest that Dom0 cannot
be part of the configuration, while instead it's a possible use case.
To avoid that, rename the "dom0less"
Il mer 28 giu 2023, 13:28 Bernhard Beschow ha scritto:
>
>
> Am 27. Juni 2023 12:07:40 UTC schrieb Olaf Hering :
> >Tue, 27 Jun 2023 10:12:50 + Bernhard Beschow :
> >
> >> The BAR is a 32 bit register whose default value is 0x0001. I think
> what's supposed to happen here is a
On 30-06-23, 09:40, Julien Grall wrote:
> The patch is missing an ack from the golang maintainers. I noticed you
> didn't CC them (done now).
Ahh, thanks.
> In the future, I would suggest to use one of the scripts in the repo to find
> the appropriate maintainers:
> *
(correcting the e-mail from Nick)
On 30/06/2023 09:40, Julien Grall wrote:
Hi,
On 30/06/2023 05:40, Viresh Kumar wrote:
On 13-06-23, 11:48, Anthony PERARD wrote:
On Tue, Jun 13, 2023 at 11:32:16AM +0530, Viresh Kumar wrote:
Currently, the grant mapping related device tree properties are
Hi,
On 30/06/2023 05:40, Viresh Kumar wrote:
On 13-06-23, 11:48, Anthony PERARD wrote:
On Tue, Jun 13, 2023 at 11:32:16AM +0530, Viresh Kumar wrote:
Currently, the grant mapping related device tree properties are added if
the backend domain is not Dom0. While Dom0 is privileged and can do
flight 181644 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181644/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim broken
test-amd64-amd64-xl-pvshim5
Am 30. Juni 2023 07:29:21 UTC schrieb Olaf Hering :
>Wed, 28 Jun 2023 09:27:16 + Bernhard Beschow :
>
>> Would you mind sending a patch fixing the BMIBA register to be reset as 32
>> bit?
>
>Will do so next week.
Great! Perhaps it could then be picked up by maintainers together with my
Chen, Jiqian would like to recall the message, "[LINUX KERNEL PATCH v2 0/1] add
S3 support for virtgpu".
Hi all,
V2 patch of kernel is
https://lore.kernel.org/lkml/20230630073448.842767-1-jiqian.c...@amd.com/T/#t.
On 2023/6/30 15:00, Jiqian Chen wrote:
> v2:
>
> Hi all,
>
> Thanks to Marc-André Lureau, Robert Beckett and Gerd Hoffmann for
> their advice and guidance. V2 makes below changes:
>
>
Hi all,
V2 patch of kernel is
https://lore.kernel.org/lkml/20230630073448.842767-1-jiqian.c...@amd.com/T/#t.
On 2023/6/30 15:34, Jiqian Chen wrote:
> v2:
>
> Hi all,
>
> Thanks to Marc-André Lureau, Robert Beckett and Gerd Hoffmann for
> their advice and guidance. V2 makes below changes:
>
>
Hello Stefano,
On 29/06/23 21:47, Stefano Stabellini wrote:
On Thu, 29 Jun 2023, Federico Serafini wrote:
Change the parameter names of function declarations to be consistent
with the names used in the corresponding function definitions
so as to fix violations of MISRA C:2012 Rule 8.3.
On 29.06.23 13:30, Juergen Gross wrote:
On 20.06.23 15:09, Julien Grall wrote:
Hi Juergen,
On 30/05/2023 10:13, Juergen Gross wrote:
Today all Xenstore nodes are stored in a TDB data base. This data base
has several disadvantages:
- it is using a fixed sized hash table, resulting in high
flight 181652 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181652/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f5c987fcac567b1f84a418826f30d8ef2b46860e
baseline version:
ovmf
This patch solves two problem:
First, when we suspended guest VM, it called into Qemu to call
virtio_reset->__virtio_queue_reset, this cleared all virtuqueue
information of virtgpu on Qemu end. As a result, after guest
resumed, guest sended ctrl/cursor requests to Qemu through
virtqueue, but Qemu
v2:
Hi all,
Thanks to Marc-André Lureau, Robert Beckett and Gerd Hoffmann for
their advice and guidance. V2 makes below changes:
* Change VIRTIO_CPU_CMD_STATUS_FREEZING to 0x0400 (<0x1000)
* Add a new feature flag VIRTIO_GPU_F_FREEZING, so that guest and
host can negotiate whenever freezing
Wed, 28 Jun 2023 09:27:16 + Bernhard Beschow :
> Would you mind sending a patch fixing the BMIBA register to be reset as 32
> bit?
Will do so next week.
Are the specs for this chipset available, does this address really need
to be accessed in quantities of u32, or is perhaps u16 required?
On 2023/6/30 07:03, Stefano Stabellini wrote:
On Fri, 30 Jun 2023, Henry Wang wrote:
With UBSAN on some arm64 platforms, e.g. FVP_Base_RevC-2xAEMvA, the
following splat will be printed while Dom0 is booting:
```
(XEN) ==
(XEN)
Hi Dongwon,
On 2023/6/30 00:53, Kim, Dongwon wrote:
> This method - letting QEMU not remove resources would work on S3 case but
> with S4, the QEMU would lose all the resources anyway as the process will be
> terminated. So objects restoring was only option for us as
My patch is for S3 function
v2:
Hi all,
Thanks to Marc-André Lureau, Robert Beckett and Gerd Hoffmann for
their advice and guidance. V2 makes below changes:
* Change VIRTIO_CPU_CMD_STATUS_FREEZING to 0x0400 (<0x1000)
* Add virtio_gpu_device_unrealize to destroy resources to solve
potential memory leak problem. This also
After suspending and resuming guest VM, you will get
a black screen, and the display can't come back.
This is because when guest did suspending, it called
into qemu to call virtio_gpu_gl_reset. In function
virtio_gpu_gl_reset, it destroyed resources and reset
renderer, which were used for
On 29/06/2023 22:11, Julien Grall wrote:
>
>
> From: Julien Grall
>
> UBSAN has been enabled a few years ago on x86 but was never
> enabled on Arm because the final binary is bigger than 2MB (
> the maximum we can currently handled).
>
> With the recent rework, it is now possible to grow
On 29/06/2023 22:11, Julien Grall wrote:
>
>
> From: Julien Grall
>
> At the moment, the maximum size of Xen binary we can support is 2MB.
> This is what we reserved in the virtual address but also what all
> the code in Xen relies on as we only allocate one L3 page-table.
>
> When feature
On 29/06/2023 22:11, Julien Grall wrote:
>
>
> From: Julien Grall
>
> At the moment, we are mapping the size of the reserved area for Xen
> (i.e. 2MB) even if the binary is smaller. We don't exactly know what's
> after Xen, so it is not a good idea to map more than necessary for a
> couple
79 matches
Mail list logo
